Inderjeet Singh's Blog

SOA: A look from the reusability point of view

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.

Comments

• JBoss microkernel
  I went to Mark Hapner's talk at TSS symposium and came away thinking that SOA is VERY close to JBoss's JMX Microkernel.

  Our kernel has service lifecycle, a generic abstract invocaiton bus (synchronous and notifications provided by JMS), pluggable deployers, hot deployment for any component type.

  What I don't like about SOA though is its Web Services centric approach. Personally, I'd rather see a pure java approach with protocols snapped on via adaptors.

  Bill Burke
  JBoss Inc.

  Posted by: patriot1burke on June 03, 2004 at 06:45 AM

• JBoss microkernel
  I don't think SOA is really "Web Services centric." That is just the most common usage of it to date. The JINI architecture for example is definitely a SOA architecture (and arguably the best one out there).

  You can also get SOA benefits from within 1 VM. We are currently refactoring our product to be service oriented by publishing services into a JNDI namespace for consumer modules to use and to monitor those services' states.

  Posted by: ekartzma on June 03, 2004 at 07:47 AM

• Loose coupling enables reuse
  I think the key differentiations of the current SOA push with respect to reuse are the loose coupling aspects. Language neutrality and independ deployment services greatly reduce coupling over previous solutions like CORBA and Jini. Without language neutrality, services won't be "portable enough" to be widely reused by multiple business partners. Without independent deployment, the ability to keep an old service running (for years) will be reduced (think of legacy services running on an old operation system).

  Posted by: johnreynolds on June 03, 2004 at 08:27 AM

• Nice Job!
  Inder,

  Great job in explaining SOA. It really is about modularity and reuse, but its also about usablity which is why Web services tends to be THE way to implement SOA. It can be a pig compared to CORBA or Java RMI, but than again Web services can be implmented on any platform, language, what have you - all you need is support for HTTP and XML parsing. That cannot be said about CORBA or Java RMI, which is why Web services fits and the others do not (or do but to a lesser degree).

  Richard

  Posted by: monsonhaefel on June 03, 2004 at 01:12 PM

• More Clarification needed
  Thanks to this article I think that I am close to undertanding what SOA is all about.The following discusses SOA based on my current understanding.
  Its hard to believe that a distributed environment is required for SOA. I am speculating that SOA doesn't require a distributed environment but solves problems found in distributed environments.SOA seems like the evolution of interface-based design and a de-evolution of OO. For instance, interface inheritance allows for polymorphic types while Objects may consist primarily of methods. This promotes code reuse because a new type can implement the specified interface required by the 'methods-only Object. The 'method only object' provides Services to the architecture.
  This idea is empowering to designers because it keeps the best elements of OO but allows the designers to create domain-specific 'Service objects' that can remain decoupled and reusable.WS takes another step by providing language and platform-indepence via XML but I think the key features of SOA lies in the evolutionary relationship with OO and functional programming.Am I close to understanding SOA? Thanks for the article.

  Posted by: beamsack on June 03, 2004 at 06:18 PM

• Nice Job!
  Thanks for your comments. Based on the current state of the standards, technologies and tools, it is debatable whether Web services is a significantly better option for implementing SOA than other options However, it is clear that industry today thinks SOA almost synonymously with Web services, and there are a lot of good reasons for that (support from all major vendors, benefits of XML and HTTP, etc.)

  Posted by: inder on June 04, 2004 at 01:24 PM

• More Clarification needed
  Thanks for your comments.

  SOA is based on services, and it is natural for services to be distributed. The goal is that everyone in the enterprise uses a "order purchasing" instead of writing their own code for the same functionality. Since enterprises today have a number of systems (even each employee has their own desktop), so SOA has to be a distributed system.

  However, it is also true that SOA is a good way of architecting the enterprise so that the inherent distributed nature of the enterprise is managed well, maximally reused, and centrally administered.

  Regarding Services being "method-only", that does not have to be the case. Most services store a lot of state in the databases. You can also design stateful services (as we discuss in our upcoming "Designing Web Services with the J2EE 1.4 Platform" book) using correlation identifiers and other techniques.

  As you also point out, there are other significant advantages of using Web services, such as multi-vendor support, interoperability, and the use of Web. XML provides another big advantage because of flexible data typing, ability to describe services, natural support for documents, and so on.

  Posted by: inder on June 04, 2004 at 01:35 PM

This work is licensed under a Creative Commons License.