Why SOA is different?


The idea of reusing a functionality embedded in software modules (or components) is not new. Even considering only the last decade, the technology of remote reusable services has been well established. Both Microsoft DCOM and CORBA attempted at a distributed service model. Both models failed in some way. I have found an interesting discussion about these failures in the book “Oracle JDeveloper 11g Handbook“. The authors present the SOA concept as an evolution of the earlier attempts at distributed computing such as DCOM and CORBA. From a technical point of view, they point out the following critical advantages of SOA over its predecessors:

  • Communication is based on hypertext protocols. COM and CORBA failed mainly because of the transport mechanism they use to communicate between remote servers  (i.e. the low-level TCP-IP protocol). The problem with this mechanism concerned the need to cross firewall boundaries or pass between proxy servers. SOA uses a different protocol for communication (i.e. HTTP) which works better as a transport layer and is capable of traversing firewalls and proxy servers.
  • Through Web services, SOA has a common (and standard) lexicon. SOA uses both the Web Services Description Language (WSDL) and a publishing mechanism (UDDI, Universal Description Discovery and Integration) for discovering Web services, which are standard formats. CORBA is based on a standard specification, but implementors failed to provide standard implementations. DCOM achieves portability at the binary level, but it is “standard” only in the realm of the Microsoft platform. Porting DCOM outside Windows resulted in several difficulties.
  • SOA emphasize orchestration, not just communication. The typical code we write with either DCOM or CORBA exploits local and remote function call. With marshaling and unmarshaling, this programming style enables a uniform invocation style, which makes local and remote calls look similar. However, that code remains at the functional level. SOA concentrates on the more abstract task of integrating at the service level. Furthermore, using the Business Process Execution Language (BPEL), this task can be reasonably achieved by a business analyst rather than by a programmer.

Of course, any technology succeeds (or fails) for a variety of reasons concerning not only the technical aspects. Nonetheless, I think that the aspects discussed so far are quite interesting as key factors in the comparison between SOA and its predecessors.

Finally, I conclude this post with what I consider a challenge in the actual software modeling scenario. The development of SOA applications promotes the use of a declarative programming style on the top of an object layer. To this regard, it is interesting to see how modeling notations such as UML are/will-be capable of expressing these two different paradigms in a coherent, unified style.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s