Hello Indigo - Service Oriented Architecture (Page 2 of 4 )
What is Service Oriented Architecture (SOA)? There have been so many interpretations of this throughout the years that it seems important to establish a common understanding before I discuss WCF as an SOA platform. The Organization for the Advancement of Structured Information Standards, better known as OASIS (http://www.oasis-open.org), provides this official definition in its Reference Model for Service Oriented Architecture:
Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.
You can find the OASIS SOA Reference Model documentation at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.
You might add to this definition by stating that SOA relies on the ability to access chunks of business functionality, potentially owned by different applications, departments, companies, or industries. Notice that this description does not specify the mechanism through which those chunks of functionality are accessed. In fact, the term "service" isn't even mentioned, although it is implied.
From OOP to 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. 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 Figure1-2.
Figure 1-2. Duplicating types between components
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 (see Figure 1-4).
Figure 1-3. Shared component containing shared types
Figure 1-4. Exposing function through a service boundary
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, as shown in Figure 1-5, 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.
Figure 1-5. Consuming interoperable services
No matter how you define a service, the underlying point here is that to build an enterprise system, developers must be able to distribute chunks of functionality across process and machine boundaries to deal with performance bottlenecks, to introduce security boundaries, and to facilitate reuse. In addition, these chunks of functionality may be important to expose to other applications in a corporate
ecosystem--which implies the potential need for interoperability on top of the rest.
Next: What is a Service? >>
More BrainDump Articles
More By O'Reilly Media
|
 This article is excerpted from chapter 1 of the book Learning WCF A Hands-on Guide, written by Michele Leroux Bustamante (O'Reilly, 2007; ISBN: 0596101627). Check it out today at your favorite bookstore. Buy this book now.
|
|
