Skip to main content

SOA: A look from the reusability point of view

Posted by inder on June 2, 2004 at 5:25 PM PDT

Service Oriented Architecture (SOA) is the new buzzword in the world of enterprise development these days. What does it really mean and why is it important? To me, it is just the evolution of software development trying to find the optimum unit of reusability. What exactly is being reused is what is being refined over the years.

First, the rage was structured programming epitomized by the C language. The focus in structured programming is on resuable functions. That is why we all took extensive care in writing each C function in its own file. The beauty of structured programming is its simplicity and performance. Most of the concepts in structured programming are quite easy to understand. Since the language constructs (automatic variables, function calls, basic types, pointers) map directly to the underlying hardware, a well-written C program can often achieve a very high level of performance.

However, the structured programming has its limitations as far as reusability is concerned. The problem is that the data is defined separately from the functions that operate on it, and the data is open to anyone for modifications. All data items are also in a single public namespace, so you have to ensure that they all have unique names. These limitations are usually not an issue for small projects, but for large projects involving hundreds of thousands lines of code spread over thousands of files, this can become quite a challenge. What happens is that most functions end up not being really reusable.

Then came object-oriented programming (OOP). OOP improved the unit of reusability by focussing on the reusability of objects. The key advantage here is that the data lives with the methods that operate on it. You can also define namespaces, for example, using the package facility in Java. You can also restrict who accesses which data. Other advantages include separation of interface with implementation, polymorphism through subclassing and method overloading. All of these help you define a simple formal interface that promotes reusability.

OOP came with a great promise but people started realizing that objects were probably too fine-grained as a unit of reusability. Thus software components were born. What people realized was that a class Account was not as reusable, but a component Customer (composed of multiple classes Account, Profile, Address, etc.) was. This notion of components was further extended (for example, by the J2EE platform), to include information such as resources, deployment descriptors to make it an even more complete unit of reusability.

Now let us look at the Service-oriented architectures (SOA). The focus here is not on software reusability but on Service reusability. The other approaches discussed above focussed on reusing a piece of code that was then deployed in a new system. SOA does not focus on a piece of code, but on a running service providing the same functionality. For example, instead of reusing the Customer component, I can use a Customer service that provide functionality to create, read, update and delete the customer, provide a service to login the customer, get their preferences and so on. SOA is also benefitting tremendously from Web services since an SOA can be based on Web services. A service in this world is available through SOAP over HTTP, and is published using WSDL. Note that SOA is not specific to Web-services, it can be implemented with any distributed system technology such as CORBA, RMI, etc. However, it is clear that the industry momentum is behind implementing SOA with Web services.

Is SOA really an improvement over the paradigms that precede it? I guess we will know the answer in a couple of years when we have more experience with it to know what works and what does not. However, some benefits are apparent: you need to know very little to use a service. Essentially you just look at its WSDL, which for a well-designed service focusses primarily on what you as a user need to know about the service. The reusability is high since the code is not available and hence everyone is forced to use the service through its interface. If your service is being used by many users, their demands will quickly ensure that you actually have something that is reusable. For that reason, SOA probably provides a very good unit of reusability. Moreover, since the each service is deployed in one place, it can be better controlled, managed, and evolved. Services can also be deployed on a variety of hardware/software platforms. For these reasons, SOA also enables outsourcing of services which adds to the business motivation.

Some of the downsides of an SOA are that you are forced into a distributed computing environment which is quite a challenging environment to operate in. All service invocations are remote calls and, hence have high overheads. If you thought remote EJBs were expensive, wait till you make a SOAP call. A distributed system also comes with enormous security considerations, especially when using a public network. A distributed system also needs to take into account the fact that other nodes in the system can fail or may become overloaded. The versioning of the service may also be a challenge: the remote service may be running a different version of the software or the protocols. As a user of the service, you may not be able to do anything about it but be forced to adapt.

Related Topics >>