What is an SOA?
Let's start with the basics. Service Orientation is a way of building software systems in which the implementation of the features to be done is splitted into discrete collaborative units called services, which depend on each other only through well defined procedural interfaces which define the operations offered and the data they interchange, and that are usually scattered around a network. A Service Oriented Architecture (SOA) is the artifact that makes the system run with the principles of applying Service Orientation, and thus is the result of it. Both concepts are tightly associated and I will freely use one or the other.
Service Orientation and SOAs are useful paradigms for building systems, because having services as loosely-coupled computing units may provide many benefits like componentization (and associated isolation, maintenability and others), reuse, flexibility and interoperability, among others.
To compare them with something more known, let's take Object Orientation (OO). This is another paradigm for building software with similar goals; only, instead of focusing in services, it does in objects and classes of objects, which have several different properties than these. Object Orientation is more complex than Service Orientation and allows to design and create not only the architecture(1) level of systems, but is also useful for lowel levels, like the internal implementation of components. For example, typically in an SOA, each individual service would be internally built using OO principles, not SOA ones.
(Note 1: I won't try to define here what "the architecture of a system" is, but just assume a hopefully common, fuzzy conception related to the macrostructure of an IT system.)
While one of the most praised benefits of Object Orientation is software reuse, I think that all of us are aware now of its limitations regarding this. For start, just applying the Object Orientation paradigm does not help much in making your newly developed software modules really reusable, since this depends also on the actual technology you have used to build it. If you have used Java, then you have a chance to be able to reuse them in a Java environment, but very little to do so in a .Net, C++ or Ruby one; even though all of them are Object Oriented. And even if you stick to the same development language, for example Java, it usually is not enough. If you have used e.g. Hibernate for accessing the database or Swing for your user interface, you will have problems if it happens that the environment in which you want to reuse them uses JDO over an XML database or is a web application. So it is not only the language, but also all of the surrounding framework.
Just the same as Object Orientation principles are not enough to achieve reusability, but also the actual pieces of technology used matters a lot, the same happens with Service Orientation and SOAs. If you stick only to Service Orientation, your code will not be reusable. For example, you may build a component for an SOA using Jini - but then you will able to deploy it only in an SOA based on Jini.
Now I come to my first point: it is useless to talk about SOAs in abstract. One must settle to the actual technology used in order to achieve the true benefits of an SOA. So I will choose such a technology right now and forget about other alternatives.
Which SOA are we talking about?
From these "true benefits" of SOAs, for me the most outstanding one is interoperability. For start, it is a required factor for achieving the holy grail of software reuse, since only if a component you create is interoperable with others may it be reused.
And indeed interoperability is the feature we most miss now: we may have componentization, isolation, maintainability and many other good things - what we do not have is a real way to create software using a technology, that is able to properly interact with software created with most other technologies. And it is not a technical problem. I mean, most technologies are interoperable in theory - but in practice almost all of them miss the proper industry support in order for this to be true. And most people are interested in the in practice part, not in the theoretical one.
For example, Java does not interoperate specially well with other non-Java platforms, except through web services or CORBA. The extent of CORBA support may be discussed, but as long as Microsoft does not embrace it it is not interoperable enough in practice. DCOM is just the complementary to DCOM. And .Net is the complimentary to Java.
The truth nowadays is that XML web services over SOAP and HTTP and described by WSDL are the only realistic option to interoperate with any platform. This is, if you are to build a product that you pretend to have the maximum interoperation with other platforms, there is not other choice that SOAP web services. I do not care about whether it is inefficient, bad or even a total crap. I do not care whether REST is better than SOAP, whether SSDL is superior to WSDL, or whether RELAX outperforms XML Schema in every aspect - the main differentiator of all them against its alternative technologies is that they are supported by every relevant actor in the IT landscape. Microsoft, IBM, Sun and all the other players support WSDL + SOAP + HTTP, and this means that you can indeed interoperate with any other platform in the world (2). And this is interoperability in practice.
By the way, this is the very same value of XML: regardless of whether it is good or bad, what makes it so useful is that it is supported by every player.
(Note 2: I agree in that interoperability of web services is still more a goal than a reality, but today you are much more interoperable if you use web services, than if you use any other technology. And I trust in that they will eventually become fully interoperable.)
I said that for SOAs to really provide interoperability the actual technology to be used must be fixed, but until now I have only talked about WSDL/SOAP/HTTP web services. And as you may well know, SOAs are not only web services. Which is the difference between a bunch of web services and an SOA?
What differentiates a set of web services from an SOA?
More or less, the difference is the same as between the Java programming language and a full Java development/runtime environment with all of the J2EE libraries; and, if you want, additional ones like Spring, Struts, etc. This is, a common framework that provides facilities to the bunch services which is still contained inside the SOA.
For start, when one of these services needs to call any other service, first has to locate it, i.e. find out which is the URL to where the XML message must be sent. If you do not have an SOA, you have to use ad-hoc mechanisms for this, like for example hard-wired URLs taken from WSDLs or ad-hoc configuration files. Such ad-hoc mechanisms are an ovbious obstacle for reuse, since your software depends on them, which means that any environment in which you aim to deploy them muse use these mechanisms too, and none of the two examples given above are a good option for this (e.g. imagine having thousands of services, each one of which requires of a custom, ad-hoc configuration for calling each other). In short, there must be some mechanism for components to discover each other.
To solve this problem there are at least two solutions: use an ESB, or use a UDDI server. In theory they are not exclusive, but I think that in practice they are, since both technologies take a central room in an SOA. The ESB is the communication channel of every communication inside the SOA, while the UDDI must be used at least once before each communication is stablished, but does not intervene during the own communication. You can read here more about my opinion on ESBs versus UDDI.
Having a UDDI server in place, each service must look up into it which is the endpoint to be called at least once before invoking each different interface it depends upon. Depending on the degree of dynamism of the environment this may be at deploy time or at run time. This provides something similar to what in other environments is called dynamic or late binding, since the actual code to be called behind an interface is decided at run time. And this brings dynamism, since you may replace the implementation of any given interface by another one without touching any line of code, and as long as this interface is enforced the SOA keeps working fine.
I keep talking about interfaces, since I think the proper way of building collaborative, loosely coupled services is to make them depend from each other only through well-defined interfaces. These interfaces end up being represented in WSDL 1 as portTypes, bindings and ports, among which the most useful thing to make a service depend upon I think is the binding. This is, when you create a component that invokes some other N services, you should make it depend on N SOAP bindings. When the WSDLs are registered in the UDDI, if you follow the OASIS recommendation about how to do it, then your component may easily look up the binding in the UDDI, and them which are the services which implement them in order to call them.
Note that there may be more than one service found, but this may be a good thing. For example, if you want to find out which vendor sells the cheapest shoes, assumming every vendor implements a given SOAP binding, you may find out all of the provider endpoints in the UDDI, call them one after each other and compare them.
As you can see, I am relying all of the time in having well defined interfaces, and as all of us know, this is something that may be difficult to have, since even for an internal integration we will found a large number of different interfaces. But the own flexibility SOA comes to the rescue, since it allows to build adaptors for each interface and register them as stubs, so that you still can rely on having a given interface. I do not want to ellaborate much about this; maybe I will do a separate post, since this one is already long enough.
By the way, I have focused on UDDI, and maybe you are an ESB fan. For the ESB flavor of SOAs, the thing is very similar. Your nice component still should depend on interfaces, but it does not look up in the UDDI to see who implements them - it just calls the ESB, and it will take care of implementing your interface and deliver your message to the proper place. In the end is just the same, only you lose options: instead of writing the adaptation layer in whichever way you want, you typically will use the ESB. I do not like this because the ESB will become just a trash can of business logic, and we have places enough already where we put business logic to have yet another more. Besides, you usually put your business logic in the hands of some proprietary product, which uses new paradigms and technology to make your system work. With a non-ESB SOA, you are free to implement your services in any way.
As you see, the UDDI approach does not preclude the ESB one: if you stick to UDDI, you always may register your ESB inside it as providing your interface if you want. But if you focus on ESBs, then you lose other options like UDDI. Thus, I like to have ESBs only as an option, and not as the center of a SOA as, unsurprisingly, ESB vendors depict. (For the start, this is what the "Bus" term implies - a common communication facility that everybody uses. If you have not yet guessed out, I do not like ESBs.)
Until now I have drawn some conclusions:
- SOAs based on WSDL + SOAP + HTTP are the base of unparallelled software reuse
- You also need to have some mechanism for discovery to achieve this
But besides discovery there are, of course, still more things one needs before one may claim you have an SOA and not only a bunch of services. Things like security (most critically, authentication and authorization), transactions, asynchronous messaging, publish/subscribe, stateful services, non-functional properties of contracts (e.g. policies), etc. This is all what the large number of WS-* standards aim to settle. For example, if there would be a universally accepted WS-Transaction standard, one could create a component that would access several services like Accounting, Customer and Invoicing, do useful business operations on top of them, in a single transaction. How nice.
I have heard about many of these WS-* standards but do not know well any of them, so that it is pointless I talk about them. I only should say that they are needed in order to achieve true reuse of SOA components.
And only if one has all of these standards in place one will have an SOA. This means that nowadays having a real SOA is impossible, since most of these standards are not mature, agreed or even standrdas but just mere specifications made by a number of vendors, some time with more intention to sell their own products than to create useful standards (e.g. the recent initiative for SCA, SDO and others seems to be quite product-oriented).
But the point is that, the more actual standards does your wannabe SOA support, the more it resembles a true SOA. And what do you achieve when you have a true SOA? A platform on which to deploy arbitrary software components developed by arbitrary vendors. If you are a software vendor, what you gain when you target your software for SOAs is a platform that every one of your potential customers will eventually have, and on top of which you can deploy (i.e. sell) your products and services.
It is like in the hottest dreams of Bill Gates: if every computer in the world would use Windows, then every piece of software in the world would run in it, and would probably offer DCOM interfaces over which every software would be able to interoperate with the other. The IT systems would be much easier to operate and maintain - and Microsoft would be incredibly powerful.
Stop dreaming, Bill - because this dream is possible, although not by means of Windows, but by means of SOA. SOA is the platform. This is the basis of the so much praised Web 2.0 : A world of discrete services, offering well defined interfaces, with no central "bus" inside it, with a nice distributed directory system to find each other and infrastructure services for security, transactions and so on.
But Web 2.0 is the view of a "world-wide SOA", while I am more interesting in the view of lots of SOAs operating inside organizations (i.e. Internet vs intranets). Once most organizations in the world with own IT systems are using an SOA, most pieces of business logic which is available as a service may be reused in most organizations. Most components performing useful functions may find other services fulfilling its needs, in most organizations. The SOA is the ultimate technological platform. And it is non-proprietary, it is not owned by anybody; neither by a pack of greedy executives, nor by a bunch of untidy developers, but shared and developed by them all.
Once this universal platform is available in most organizations, business logic becomes reusable. One can buy a component that calculates the payroll (note that it is possible to buy either the software, or the on demand service). This component will depend on a series of interfaces to be offered by my organization to access e.g. the employee database, and I must create these interfaces before being able to use the component.
Thus, if this vision becomes a reality (which I firmly believe), it well may cause that organizations start converging into using the same business interfaces. For example, if there is a excellent payroll component that becomes popular and many organizations end up using, it is likely that the interfaces it uses would also become popular and used by all of these organizations. Which may end up standardizing the business interfaces and languages used in organizations, which would make life really easy for CIOs (so easy that even they may stop existing).
Well this is too futuristic and, while I firmly believe that SOA will become the ultimate platform, I am not so sure about this business uniformization. But who knows...