Not that I wish to be apologetic regarding the title of this entry, but I feel it needs some explanation. The title by no means is intended to suggest SOA (Service Oriented Architecture) is simple or without merit. The intent of this entry is to assert the importance of SOA as a means to improve enterprise architectures and their extended maintenance complexity. Given this assertion, I contend that SOA must be a critical part of computer science programs and corporate training strategies for software development. Also, SOA is extremely complimentary to agile methodologies in the delivery of high quality and valuable software assets in small calculated chunks.

The rise of layered architectures, such as those presented in J2EE blueprints and MVC (Model View Controller) based frameworks like Spring and Struts, has been integral to a design which contains a middle layer for business logic. This layer, also known as the “service layer”, provides valuable support and accelerates delivery of business products and services. A problem which has persisted with these architectures is their lack of complete service decoupling. Teams must combat coupled designs through slices of the layered architecture with pre-defined interface documentation, technical requirements documents, coding standards, and code reviews.

In my opinion, the frameworks mentioned above are not at fault. I believe that the problem of service coupling is due to our training techniques for developer application design over the past few years. A shift in software development design must be made such as those made when structured, function prototype, and object-oriented design were introduced. I should mention a friend of mine who has wrote a white paper, “A View-Oriented Approach to SOA” by Scott Came, which attempts to define an appropriate method for SOA design. I agree with many of the points made in his white paper and would like to describe effective programming models which facilitate good SOA design.

The following image depicts the high level systems within an SOA implementation:

Each component within the SOA has a role in the effective design:

  • Service Registry - This is a location where clients may find services they are interested in using. Examples of a service registry are UDDI, Jini's Reggie, and Spring XML configuration descriptors.

  • Service Proxy - This is the interface defined for communicating with your service. This may be a compiled WSDL to Java or C#. The proxy may be as smart or dumb as your service requires. RMI uses downloadable serialized proxy objects to communicate with a remote service. For Spring you use the AOP proxy object created at runtime using an XML configuration file.

  • Deployment Configuration - A deployment configuration allows service to be used dynamically at runtime. In Jini you might configure your service to use the start.jar with net.jini.config.ConfigurationFile instance which defines the communication protocol to use between your service proxy and the service implementation. Another example is the J2EE application descriptors such as those used in EJB configuration and JNDI name binding.

  • Message - The data sent to your service for processing such as XML for SOAP or REST web services, Java objects for RMI, or JMS messages into a queue.

  • Service Grid / Bus - In many distributed systems, containers are used to manage objects across a grid or bus. J2EE defines an EJB container for managing services and entities. Rio is a grid fabric which is built on top of Jini which manages JSB (Jini Service Beans). ESB (Enterprise Service Bus) usually have service containers which have been standardized in the Java community through the JBI (Java Business Integration) specification.

  • Service Interface / Implementation - The service interface defines how clients may communicate messages with a service. This can be defined using WSDL, Java interfaces or POJO (plain old Java objects), or IDL in CORBA. The implementation of this service is the message handler.

In my experience, there is an initial barrier to entry for SOA development which seems obvious at first glance but derails many developers, including myself at one time or another. When creating a desktop or console application, most of the time we are working with in-memory models which can be passed around in graphs easily between components. SOA-based applications or systems revolve more around message passing between clients and services.

The difference in paradigm brings some different design philosophies such as the amount of data and the frequency we communicate between components or services of the system. We might not think twice about making a call for each item added to our order if it is inside our desktop application. If we are adding these items to our order over the network you may fall pray to “The Eight Fallacies of Distributed Computing”. A possible way to combat this is a local persistent cache and guaranteed delivery options such as those found in JMS.

Many times, SOA-based applications or systems are a step away from overly evolved OO designs. Since a service tends to contain finer grained slices of functionality, developers can focus more of their efforts on handling the task at hand. For example, adding an item to an order may only entail finding the order by a unique identifier and then adding the specific item passed into the service via a message. In a service grid or bus there may be any number of services which can perform this action. And all of those services may just be copies of each other and therefore handle the message in the same manner.

To be continued…