SOA, because of its newness, is less well understood, and different people define it in different ways. A detailed comparison with a well-defined middleware technology will therefore help in the definition of SOA itself.
SOA and DO are aimed at different things. The CORBA standard was defined as a general purpose integration technology, but because there was little support for implementing servers when CORBA was introduced (in the early to mid 1990s), the CORBA implementations, and indeed the standard, began to concentrate on helping programmers to implement clients and servers. CORBA’s commercial success made it a rival for other middleware. J2EE was introduced, among many other reasons, to provide a distributed object facility for Java. CORBA and J2EE, and the various other middlewares, formed middleware islands; each with good internal integration, but poor inter-island integration.
SOA has been introduced to tackle the highest-level integration task, one important aspect of which is the integration of middleware islands. DO can be very specific to one specification/standard (e.g. CORBA or J2EE); SOA has to be more technology neutral. SOA has to work at a wider scale across an enterprise: across middleware islands in an enterprise and even across enterprises.
This article looks at differences and similarities between DO and SOA mostly at the modeling level.
Quick definition of terms
A service is a software entity that offers to carry out one or more actions for clients, according to a contract that defines its interface. Clients communicate with it to request it to carry out these actions, and the communication aspects of this are normally worded in one of the following ways:- Each service can accept any of a set of messages, each with a defined format; and for each such request message, it can optionally send a reply message with a defined format,
- Each service offers a set of operations, each taking a set of in parameters, and possibly a set of out parameters.
SOA is a set of architectural principles, including the following aspects:
- services, with well defined interfaces
- easy communications between clients and services, and between services
- the latter allows composition of services, e.g. where a new services is constructed using a number of existing services
- ability to find services
- loose coupling between clients and servers
- no boundaries, including no boundaries between middleware islands
SOA and DO comparison
To help identify the differences and similarities between the two, the core features of DO are listed here, and for each a short statement is made about SOA’s support. For the most part, differences in terminology are ignored. In come cases, web service’s support for a feature is also discussed, although web services should not be considered to be the definition of SOA:Objects provide a service to their clients.
SOA has the same concept, but it uses the term services.
Each object provides a service defined by its interface.
SOA has the same concept.
Interfaces are types, and there can be many instances of any of these types (There is the notion of singleton classes in DO, but these aren’t as common as non-singleton classes)
Some commentators say that SOA should not have interface types that can have multiple instances; but we disagree. It is inconceivable to us that some portion of a wide-ranging SOA could not share an interface type definition, so that clients could knowingly use different instances of the same type. The alternative is that each such service would define its own interface, albeit these could happen to be the same.
For example, a travel agency consortium could specify a shared definition and insist that all of its members adopt this. It is not sensible to prevent the consortium defining such an interface type, and the notion of SOA would be weakened if it does not support this feature.
However, there is a difference between DO and SOA in this regard: DO is under the overall control of one authority, but SOA is not. In DO, there is agreement on types, including interface types, throughout a system, albeit the system could be very large, and most programmers would only know the interfaces of the parts of the overall system that they have experience using. In SOA – which covers even larger systems, including ones for very large enterprises, and even many enterprises – there is no attempt to have overall control of the types. This does not mean that some parts of the SOA – our travel agency consortium, for example – can’t share some types, including some interface types. In fact, such sharing will be a requirement in real a SOA.
Web Services’ WSDL has some support for typing of interfaces: a number of overall WSDL files could share a single logical definition part (by including it). This support is being enhanced in WSDL 1.2, mainly as a way to shorten WSDL files.
The norm in DO is to have fine-grained interfaces.
Coarse-grained interfaces are the norm for SOA, and while these are also possible in DO, fine-grained interfaces are very common.
This difference in the typical size of the units of abstractions is the most commonly discussed differences between the two: in particular, that DO has a finer granularity than SOA. In SOA, a bank service would allow clients to check account balances, transfer money, and so on; whereas, in DO, a bank service would offer some operations itself, but it would also be used to locate multiple account objects – and it is these that offer operations to check account balances, and so on.
The real difference here is that SOA and DO differ greatly in their view on how the real world should be modeled. DO uses fine-grained object types (e.g., accounts); SOA doesn’t. SOA identifies large real world entities that are meaningful at the business level, and it captures these services, normally without introducing other service instance types. While such introductions are possible, they are far less common than in DO.
While defining one SOA service, another new service interface is introduced only when a new high-level service is interacted with. For example, while defining a travel agency service, that service’s interaction with a travel insurance service may have to be defined, and the travel insurance service’s interface would have to be defined if this has not already been done. DO does the same, but it also introduces new interface types as part of the definition of an overall service. For example, the definition of the travel agency service may result in the introduction of interface types such as travel clerk, itinerary, booking, and so on, as well as the interface for travel insurance.
The coarse-grained view is that a travel agency is a real world entity worthy of an interface, but itineraries aren’t: they are more akin to implementation details. The fine-grained view is that itineraries are equally valid as real world objects, and defining an interface to them allows an overall system to be modularised in a natural way.
Sometimes, a very large SOA interface may have to be broken up into a small number of smaller ones in order to reduce its complexity. The cleanliness of SOA’s approach in these circumstances will depend on the ability of the modeler to find the correct high level services into which to split up the overall definition, but at the same time adhere to the SOA principles.
Is the SOA or DO modeling approach better? The answer depends on your view of what is happening when a system modeler produces an object model. If you believe that the set of interfaces/types that are identified are fundamentally tied to the system being modeled (they capture its essence; and so on), then you will probably believe that these are unlikely to change unless there is a fundamental change made to the system. If such a fundamental change is made, you will believe that any model – wherever it lies on the coarse to fine grained spectrum – will have to change. Equally, you’ll believe that this set of interfaces will be easy to use because they model the real world so well.
On the other hand, if you believe that such a model will result in a set of interfaces that artificially segment the coarse-grained interfaces, then you’ll believe that these will be subject to change, and also be difficult to use (akin to the yoyo phenomenon see Taenzer, Ganti, and Podar, Object-Oriented Software Reuse: The Yoyo Problem, Journal of Object-Oriented Programming, 2(3): pp30–35, 1989)
You’ll also believe that if a service (really a set of services) is too granular, then this will expose some implementation details (such as how itinerary objects are defined); and hence the interfaces may have to change when the implementation changes.
Our view is that SOA cannot be dogmatic on the approach used. Interfaces cannot be so fine grained that they will perform well only over very fast networks (this would lead to too tight a coupling between a service and its clients). However, the SOA principles themselves – and certainly the technology used to implement it – shouldn’t restrict the modeling approach that an enterprise believes in. In particular, it is too fine a point to regulate on how granular a set of interfaces should be before the “style police” step in. However, our guidance would be not to err on the side of being too fine grained in either, but especially not in SOA.
Objects can be business level or system level.
Simplistically, services must be business level. However, it is difficult to draw the dividing line between business and system level entities, and this raises much the same issues around modeling as does the previous item. In addition, the principles behind SOA (such as well defined contracts, and separating implementation and interface) are just as valid at the system level as they are at the business level. Some commentators even use the term SOA for the system level, and the term BSOA for the business level; but we prefer to define SOA as the uppermost level of integration (and use the term Enterprise Service Bus to refer to the technology that facilitates communication between SOA entities).
In both SOA and DO, it is common for programmers to generate service/object interfaces from some form of interface on existing systems (perhaps a description of the data that is exchanged, or interfaces defined in programming languages). These lead to low level – and often inappropriate – interfaces. The only excuse for doing this in DO is as a stepping stone to offering a proper high level interface to clients; there is probably no excuse for doing it in SOA, because SOA is above the implementation level.
Calls, usually referred to as operation calls.
SOA has the same concept of calls (both one-way and request reply). These are often referred to as operation calls, probably because WSDL uses the term. However, it is considered more accurate to view these as message exchanges. Web Services’ WSDL certainly concentrates on defining the messages that flow in each direction, even though it uses the term operation.
In our opinion, it is wrong to reject either of these terminologies, and better to look for deeper differences between SOA and DO.
Related to calls, the biggest difference is that SOA often uses chunky messages, whereas many calls in DO are chattier. This arises because of the less granular interfaces in SOA, but also because some uses of DO assume a fast network between some servers and their clients, and therefore chattier interfaces will perform satisfactorily (of course, even in DO, these cannot be anywhere near as chatty as for intra-process OO calls).
As we have seen before, there is no sharp dividing line between chunky and chatty, and so many uses of SOA (and even DO) will results in calls that are far too chatty in the opinion of others. It is only when the network cannot keep up with the chattiness that a definitive argument can be made. If some of the mistakes in using DO are repeated in SOA, there will be many such overly chatty interfaces.
References to objects, and the ability to easily pass these from one object to another, and of course the ability for an object that receives a reference to call an operation on the target object.
SOA supports the same concepts: one simple example is the use of the UDDI registry in web services. However, these concepts are not used anywhere close to the same degree as in DO: the coarse grained interfaces defined in SOA mean that this isn’t needed as often. Our travel agency example would, however, benefit from it: a travel agency service is likely to include a reference to a travel insurance service as part of the information that it passes back to a caller.
Web Services has less support for this than DO (DO has special types for object references, whereas web services uses URIs to pass service references).
Registration of object references in a registry (e.g., the CORBA Naming Service or the J2EE JNDI), and the ability to look up this registry to find a desired reference.
SOA has the same concept, as exemplified by the UDDI registry.
Inheritance, by which one interface can be defined as an extension of another.
SOA does not support this, but we have a feeling that this may be added sometime in the future because it is so useful to have some way to extend an interface. While this isn’t important for early use of SOA, it will become more and more important to enterprises that define hundreds or thousands of related interfaces. (On the other hand, within DO there has been a debate for years over the choice between inheritance and delegation, so maybe delegation will win.)
This difference shouldn’t be over-emphasised: even though inheritance is often described as one of the core characteristics of OO systems, we believe that other aspects (such as objects, interfaces, invocations, reference passing, and so on) are in fact more fundamental to DO.
Polymorphism, by which a formal parameter of a base interface type can accept a reference to an object of a derived interface type.
SOA does not support this.
The ability to find an object’s type given a reference to it; and the ability to find details of this type at runtime.
In DO, a client can determine an object’s type given a reference to it; and it can acquire a reference to an object that represent this type, and call operations on it to find the details of the type’s definition. SOA supports these overall capabilities. In web services, for example, a service’s WSDL file can be found at runtime; albeit there is no standard for how it should be found.
Object Lifecycle management
DO defines the full object life cycle: how objects are created, the system-level states they may be in, and how they are destroyed. These rules also specify how this affects the response given to a client; for example, if it makes a call on a now destroyed object. These rules are not yet specified for SOA.
There are a number of other issues, not covered in any detail here:
State: It is good advice in both DO and SOA that services/objects should be state-less where this is possible. However, many real world systems require a number of interactions in order to achieve some results, and users of SOA are finding that it is in fact easier to write a state-full service in some cases. This increases the coupling between clients and services, but the alternative is to significantly increase the complexity of both. In addition, many existing applications were designed around state-full interactions, making it very difficult to offer these via state-less services.
They have somewhat different requirements on their underlying communication facility, with the main difference being that SOA is more loosely coupled. Probably the most visible and oft-cited difference is that DO mostly uses RPC, while SOA is normally viewed in terms of message passing. This is a very complex issue and one that cannot be summed up by a simple view that message passing is good for SOA while RPC is bad.
Summary
It is very interesting to note that the most important differences at this level are subtle ones in how systems should be modeled. There are some explicit differences, but not everyone agrees on these:- interfaces as types
- inheritance
- polymorphism
- clarity on life cycle
- coarse-grained versus fine-grained interfaces (which can be viewed as a difference in the way that a system is modeled)
- business versus system level interfaces
- chatty versus chunky messages
- the frequency of passing references
- registries
- runtime type information
The biggest difference at the communication level is that SOA requires even looser coupling between clients and servers – and between servers and servers – than can be tolerated in some DO systems. DO systems often require loose coupling, very loose coupling is the norm in SOA.
Dr. Sean Baker is Chief Corporate Scientist, a member of IONA’s Board of Directors, and a Co-Founder of IONA. He holds a Ph.D. in Computer Science from Trinity College (Dublin, Ireland) and has published a number of books and articles in the area of distributed computing. Before joining the industry, Dr. Baker held a tenured post in the Department of Computer Science at Trinity College, where he helped form the Distributed Systems Group in 1980.
Comments