While SOA is a great concept that carries a lot of promises for the enterprise, there is a lot of confusion around how to implement it and make it work. The software industry is delivering small pieces of the solution every day in the form of standards or tools, which makes it a full-time job to keep up with the SOA related technologies. Very few people are capable of comprehending all that information and designing successful implementations.
In this article we review the current state of SOA and suggest an alternative approach that simplifies the implementations and enables the average developers to take advantage of SOA.
At the current phase SOA implementations follow the top-down approach. It generally consists of the following steps:
  • Determine enterprise services. Enterprise architects sit down with the business people to figure out what are the high-value services within the business.
  • Implement enterprise services. They figure out how to fund those services and implement them. Initially there is no ROI, since nobody is using those services.
  • Implement SOA governance. It ensures that enterprise services are used within the enterprise. SOA governance requires additional investments in software and infrastructure without immediate ROI.
  • Use enterprise services. It involves changing existing or creating new applications using SOA services. The investments in enterprise services are beginning to pay off.
Here are some observations we can make while examining current SOA approach:
  • SOA implementations are based on single concept ‘service’ that is generally comprehended as either remote procedure call (RPC) or message. The concept is foreign to the average developer, since it does not exist within the object-oriented languages they use on a daily basis.
  • SOA developers need to integrate the concept of service within their application development that involves data retrieval, operation execution and user interface presentations. Services are usually represented by specialized interfaces for data retrieval and operation execution. How about the presentation functionality though? It does not fit well in this model. At the same time the biggest ROI can be achieved by allowing applications to share coarse-grained presentation functionality. The concept of service does not provide solution for it.
  • Companies need to make substantial upfront investments prior to realizing any ROI. There is also the possibility that some of the services may never be used, since they were designed outside of any application context. It makes it more difficult to secure funding for such projects. The business would rather invest in application development that is more expensive, but has predictable ROI.
  • Existing applications may go through multiple rounds of changes and testing as new services are added in the next round.
The fact is that given all the work that was done, SOA is still the right solution to fight code redundancy and increase the agility of the enterprise. We may need to assess our approach though and look for alternatives.

In my opinion the issues we are experiencing with SOA stem from the fact that we look at the problem from a wrong angle. By looking from above we see many applications that do not talk to each other. We are tempted to employ the familiar server paradigm by deploying reusable services and calling them from the individual applications”. It did create some confusion within the Enterprise Application Integration (EAI) community, who claimed that SOA is not a new concept. Instead it is EAI implemented with WebServices rather than messaging.

We will examine a different approach to implementing SOA that we call ‘bottom-up’. This time we look from the perspective of individual applications and try to provide seamless collaboration capabilities. In order to collaborate, individual applications need to be able to consume and expose resources to other applications.
So, which resources do we want to consume and expose? That is determined by looking at the resources needed to create application functionality. They can be abstracted into three main categories:
  • Data (persisted and non-persisted)
  • Operations (data manipulation logic)
  • Presentation components (units implementing user interface)
The resources need to be reusable, since we are exposing them to other applications as well. That is accommodated by implementing them outside of the application context. The access to resources is provided through service interfaces:
  • Data service – generic interface for access and manipulation of data
  • Operation service – generic interface for execution of data manipulation logic
  • Presentation service – generic interface for interaction with user interface components
The application functionality is implemented by consuming resources available from the service interfaces.
What is different from the traditional application development?
  • Data objects are designed outside of the application context and are developed for reusability. All data access and manipulation logic is hidden behind the data service interface. Developers do not have to worry about persistence, transactions, etc.
  • Operations are designed and implemented outside of the application context. They can be reused easily in the next project.
  • Presentation components are reusable. They are designed and implemented outside of the application context and have no references to the application model.
  • The application functionality is implemented with virtual resources (data, operations and presentation components). It enables developers to change the implementation of any resource at the service layer without affecting application functionality.
  • Since any component may be implemented locally or remotely, we can essentially build applications consisting of 100% of remote components.
By attempting to solve the problem of collaboration at application level we were able to define three services that are at the heart of that collaboration. Each application can be a client and server of those services. Let’s evaluate how this approach is helping us in the implementation of SOA strategy.
  • The services are generic and have fixed number of methods. They serve resources based on unique identifiers. Each resource type has different set of metadata associated with it that can be downloaded by the clients. Clients do not need to download WSDLs. Instead they download the XML mapping of the objects that are exchanged. The mapping tells the client how to serialize/deserialize those objects. They are also used to generate data interface classes of the objects.
  • The interfaces establish common language used by the applications for resource sharing. The exchange is supported by the application architecture and does not required additional middleware software or server. Current SOA implementations do not have such generic application level protocols. They use custom service interfaces to communicate with each other.
  • The difference is most obvious when you consider data objects. Current approach requires developers to define custom service with all search, insert, update and delete methods for an entity. When using the DataService developers provide only the XML mapping of the data object. The clients can invoke all methods that are part of the DataService interface to access and manipulate the object. That eliminates a whole set of data retrieval services that developers would have to define otherwise. The same is true for OperationService as well.
  • Bottom-up approach reduces the upfront investments. Services are implemented only when they are needed by an application and tested with that application. Later they may be moved into specialized enterprise repository instead of being served by the hosting application. It provides immediate ROI for implemented services.
  • Since application functionality is built by consuming virtualized resources it is not affected by changing the service implementation from local to remote or vice versa.
The interface implementations handle many additional aspects developers do not have to worry about:
  • User authentication
  • Distributed transaction management
  • Extensions of the user session, etc.

At the core of the application collaboration is the ability of integrated remote applications to extend the user session of the main application. It ensures that their session will expire only if the main application session expires. The feature also enables the main application to access the objects stored at the user session of integrated applications. An example of that may be an order entry application that integrates ‘make-payment’ presentation functionality provided by another enterprise application. It is explained below.

Within the main application we create presentation component that is mapped to the payment component at integrated application. The user will access the payment functionality through the main application. That enables the main application to intercept events within the integrated application and take back the control when appropriate. Within the order workflow the user gets to ‘make-payment’ step, which invokes the payment workflow at the integrated application. The user works within that flow until the user clicks either ‘confirm-payment’ or ‘cancel’ button. The order entry application intercepts those events and forwards the user back to the order entry workflow. In case of ‘confirm-payment’ it will also need the payment object stored at the user session of integrated application. The order entry application will save it until the order is submitted.

The bottom-up SOA approach makes it really easy for developers to take advantage of the shared resources available within the enterprise. The main differentiator is the service-oriented application architecture that implements resource virtualization. It operates with concepts that are familiar to developers (data objects, operations and presentation components) and tells them how to consume and exports such resources. The approach lifts the application collaboration barriers and enables IT to align better with the business in its vision of agile enterprise.

You can learn more about implementing bottom-up SOA at: http://shipka.com


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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s