The term Service Oriented Architecture (SOA) has become very controversial. Depending on their experience people either love it or hate it. Many are disappointed that the hype has exceeded the benefits delivered by the technology. Adding to the confusion was the announcement of Burton Group that SOA is dead.
What makes SOA so controversial is the fact that everybody understands it intuitively, but at the same time we lack a definition the industry can agree upon. Since the term is so generic, people create different pictures in their mind. That turns SOA discussions into religious wars. With a little more objectivity we can see that everybody is right, because the term allows many interpretations.
Regardless of all differences, we are not ready to throw SOA away yet. It has become synonymous with the need to integrate the enterprise applications and deliver efficient IT services. SOA holds the promise to:

  • Eliminate unnecessary redundancies within the enterprise.
  • Increase agility of the business.
  • Reduce the cost of application development and maintenance.

At the core of the service oriented architecture is the ability of applications to share services. The term service is very broad and means that we are asking another application or server to do something. We may pass input data with the request and receive some data back. The only requirement is that the service is platform independent and applications running on different hardware and operating system can leverage it.

SOA 2.0 enhances the existing SOA paradigm by replacing the generic service concept with concrete services for sharing of data objects, operations and presentation components.

Data Object Service – is a standard interface for access and manipulation of data objects. It is considered a repository of data objects, where objects are organized in groups by objectId. Each object is uniquely identified by object key. The service comes with generic capabilities to search and query data object collections. It relies upon data object model that supports change tracking and transactions. The metadata of data objects consists of XML object configuration that determines how data objects are serialized into XML and exchanged between applications.
Data objects may be persisted by the service to any storage – relational database, XML, LDAP, cloud-databases, in-memory data grids, etc. The use of Data Object Service simplifies application development by eliminating the complexity of dealing with different data types. It also provides enterprises with the flexibility to change the persistence storage without affecting the application functionality.
Search and query capabilities are based on applying generic operations to object attributes and sub-entities. Entity expressions are used to reference attributes or entities within the data object graph.

Operation Service – is a standard interface for executing operations. The operation is a standalone entity for programming logic. The service is considered a repository of operations. Each operation is uniquely identified by operation identifier. Developers execute operations by providing operation identifier and input parameter and receive back the result of the operation and any output parameters.
The metadata of operations defines the operation parameters (input and output) and XML object configuration for all user-defined parameter types. Operation expressions enable developers to combine operations together.

Presentation Service – is a standard interface for accessing presentation functionality. Presentation component is reusable, self-contained unit of presentation functionality. The service is considered a repository of presentation components. Each component is uniquely identified by presentationId. Applications interact with presentation components through the interface of Presentation Service.
Presentation components may implement the functionality of single page, part of screen or workflow-type of functionality involving multiple screens and associated logic. They are integrated within the application context, as if presentation components were implemented locally. The metadata associated with presentation component defines required objects, operations, presentation components, actions and user roles.

SOA 2.0 eliminates the controversy associated with the generic service concept. It defines three types of services (Data Object Service, Operation Service and Presentation Service) that applications can expose or consume from other applications. Remote service implementations enforce access control to the respective resources. All services deployed at specific application share the application context, which extends the context of the main application. It enables the main application to access objects stored at the application model of the applications providing remote presentation services.

SOA 2.0 defines application integration at a level that is independent of the underlying technology. It also creates new capabilities that did not exist under the old paradigm (like sharing of data objects and presentation components).
SOA 2.0 enables IT to communicate the enterprise integration strategy in more intuitive terms like:

  • Data objects standardized across the enterprise
  • Operations standardized across the enterprise
  • Presentation functionality standardized across the enterprise

SOA 2.0 clients can leverage any services that are based on SOA 1.0 paradigm and use SOAP or REST Web Services.

2 Responses to “Introduction to SOA 2.0”

  1. Nya Murray Says:

    Yes, these advances will solve practical integration problems. However, what I do not see yet is a paradigm to address service accessibility. One of the chief problems with SOA is that it spawned a spaghetti of services in place of a spaghetti of code. This is a fundamental problem, as is automated connection to business processes.

  2. shipka Says:

    This is a valid concern. SOA has encouraged developers to share RPC type of functionality over custom interfaces (WSDL). The growing number of interfaces has made things unmanageable. How to deal with that?
    The new approach to application collaboration eliminates the need of custom interfaces, which is major step to simplification. It introduces three types of repositories with different content:
    Data Object Repository – serve data objects over standard interface
    Operation Repository – execute operations (programming logic) over standard interface
    Presentation Component Repository – enable interaction with presentation components over standard interface

    The approach enables any application to be a client as well as repository of data objects, operations and presentation components for other applications. The flexibility creates the potential for overly distributed enterprise architecture, where shared components are spread across many applications. In my opinion, enterprise architects are responsible for determining how shared components: data objects, operations and presentation components are deployed within the enterprise. They can consolidate them in dedicated enterprise repository applications.
    Enterprise architecture make similar decisions today when deciding whether to store enterprise data into 100 small databases or consolidate them into 10 big databases.
    I am interested to hear your opinion on the subject.

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