SOA - Evolutionary Path: From OOPs to SOA

What is SOA?

 

The road to SOA has been a progressive one—driven by the need to improve how developers build complex enterprise systems. The principals behind enterprise system design are far-reaching: from object-oriented programming to component-oriented programming to service-orientation. All three approaches share the common goal of encapsulation and reuse.

 

OOP:

 

With object-oriented programming, classes encapsulate functionality and provide code-reuse.

To share classes between distinct applications  or binaries, however, you have to copy the code, as shown in Figure 1-2.

 

 

Component-oriented programming

 

·         Introduces the concept of sharing binaries that encapsulate reusable classes.

·         Initially, this was limited to the same machine until distribution was made possible with technologies like COM and DCOM, CORBA, and later Enterprise Java Beans (EJBs) and .NET Remoting.

·         Although these technologies accomplish distribution in different ways the result is the same—binary components are activated over process and machine boundaries (see Figure 1-3).

 

·         Component-oriented programming has many limitations, but the most obvious is tight coupling to a specific technology. How can a Java client call a COM component? How can a .NET assembly invoke an EJB? It all boils down to protocols and messaging formats.

·         Invoking a remote component of any kind requires serializing a message and passing it across applicable process or machine boundaries.

·         Bridge technologies and adapters exist to transform messages from one technology into another, so that when the message arrives it can be understood and processed.

·         The reverse happens as responses are fed back to the caller.

 

This approach is cumbersome, however, sometimes introducing multiple transformations between clients and components— and sometimes not even possible. Instead of exposing components directly, components can be accessed through service boundaries to alleviate some of this pain.

 

 

SOA:

 

So, does service-orientation solve the problems inherent to component-oriented programming? It depends on where you sit on the meaning of service-orientation. I would definitely agree that in its purest form, service-orientation delivers a solution to these problems by introducing (via web services) the concept of contracts, policies, and interoperability. In that respect, applications can communicate with

one another’s services, without concern over the technology each employs. But you could also argue that service-orientation is an approach to development that implies the encapsulation of business components, data access, and data storage such that access is controlled through a top-level entry point. The package is a service, accessible over whatever protocols are supported, even if it lacks interoperability.

 

 

Hope this helps.

 

Regards,

Arun Manglick

 

 

---

Disclaimer: The information contained in this message may be privileged, confidential, and protected from disclosure. If you are not the intended recipient, or an employee, or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.