The era of EAI
The concept of sharing services within the enterprise is and old one and precedes the Service Oriented Architecture (SOA). Many big companies implemented such services using messaging systems and called them Enterprise Application Integration (EAI).
While EAI did a great job of enabling applications running on different platforms to access enterprise resources it was constrained within the boundaries of the enterprise.

SOAP Web Services
During e-commerce boom, when enterprises began opening themselves for collaboration with other companies over Internet, EAI could not meet that need.
That was the time when SOAP Web Services took the lead and in many companies replaced the existing EAI infrastructure. Since they were designed around the needs of e-commerce they solved the difficult problem of sending requests that may travel through multiple processing nodes until it reaches the final destination. The services exposed by the provider are defined through WSDL, which establishes strongly-typed contract between the client and the server. SOAP Web Services enabled the implementation of synchronous and asynchronous Remote Procedure Calls (RPC), which fulfilled the needs of e-commerce and EAI.

REST Web Services
With the advent of SOA, enterprises began leveraging SOAP Web Services for application collaboration. As they were used more broadly, their deficiencies serving data became more apparent. Developers had to create WSDLs including all methods for accessing a data object (get, set, delete, etc.).
The REST approach made it easier to access resources on Internet. It uses an URI (for example to identify resources (Customers data set) and enable clients to manipulate them using HTTP verbs (GET, POST, PUT and DELETE).
The information returned for specific URI request is not strongly-typed. That enables the server to return HTML in case of browser requests and XML, JSON, etc. for requests made by applications.
Initially intended for data access, the REST approach may be used to make remote procedure calls as well by assigning URI to operations and using the GET method.

SOA Implementation Choices
From current discussions it is obvious that both SOAP and REST are designed around single concept. SOAP has the notion of service. You send a request to service and get back the response.
REST has the notion of resource. You request a resource identified with URI and get back the representation state of that resource.

Most of today’s applications are not built on single concept though. Instead they need:
– data
– behavior
– presentation

That leaves developers with the following choices:

  • Standardize on SOAP Web Services – they will use behavior methods to retrieve data.
  • Standardize on REST Web Services – they will treat behavior methods as resources and use GET resource paradigm to execute them.
  • Use both SOAP Web Services to share behavior and REST Web Services to share data.

While option 3 plays on the strengths of individual collaboration technologies it has the complexity of maintaining two very different paradigms. More importantly, none of those technologies allows developers to share presentation functionality across applications.

The difficulties of implementing SOA are often blamed on inexperienced architects, lack of business understanding, cooperation, etc. While those are all valid concerns, we oversee the fact that existing collaboration technologies do not reflect the reality of application development. We also lack application architectures supporting the development of collaborative applications.

You may be thinking, well we have SOAP Web Services “stack” (I love this term) and REST Web Services “stack”. Yes, we do, but those are only building blocks within your custom application architecture.

SOA Beyond Web Services and REST
If we need data, operations and presentation components to create applications, we also need a new collaboration paradigm that recognizes those concepts and enables sharing at that level. The solution consists of two parts:

  • Application architecture that defines standard interfaces (DataService, OperationService and PresentationService) to access data, operations and presentations. It implements application functionality by consuming components from the service layers. All data objects are retrieved from the DataService, operations invoked through the OperationService and presentation components accessed through the PresentationService.
  • Enterprise architecture, where each application can serve and consume data, operations and presentation components (exposed through Remote DataService, OperationService and PresentationService, SOAP Web Services, REST Web Services, Messaging, etc.).

The new collaboration paradigm (Shipka) is based on three concepts (data, operations and presentation component) instead of just one. It defines generic interfaces for each concept type (DataService, OperationService and PresentationService). The application architecture provides local and remote implementations of those interfaces. The local implementations are used by the application functionality running locally. Remote implementations serve requests from other applications.
The appeal of Shipka collaboration stems from its ability to extend the application architecture into enterprise architecture. It makes the application integration seamless for developers and eliminates the need to introduce new concepts.
Shipka collaboration is strongly-typed (like SOAP Web Services) and light-weight (like REST). It does not require WSDL. The remote exchange of data objects requires XML object mapping only. Applicable methods are defined by the DataService interface. The remote operation invocation requires operation metadata and XML mapping of the data objects that are exchanged as parameters. Remote presentation component access requires presentation component metadata and XML mapping of the data objects that are part of presentation component model.

What did we achieve?

  • Every application can be a client and server for all service types (data, operations and presentations).
  • Applications become independent of the data implementations – data may come from memory, XML, database, Remote DataService, SOAP Web Services, REST Web Services, etc. The implementation is configured at the data service layer.
  • Applications become independent of the operation (behavior) implementations – operations may be implemented locally, over Remote OperationService, SOAP Web Services, REST Web Services, etc.
  • Applications become independent of the presentation component implementations – they may be implemented locally or over Remote PresentationService.
  • All collaboration software including SOAP Web Services and REST Web Services are integrated at the DataService and OperationService layer, so developers do not have to deal directly with them.
  • Developers can replace the implementation of any service component (data, operations, presentations) without affecting the application functionality.

Most importantly the new architecture makes the development of collaborative applications based on SOA easier than standalone ones. The configuration of remote services is easy and they do not have to provide local implementations. This is the kind of incentives developers need to boost the adoption of SOA.

We have just scratched the surface of a really big and important topic. Hopefully I got your attention. More information is available at:

In my opinion one of the things that are holding back the wide adoption of SOA is the abstract concept of service. It conveys really vague meaning that you are asking someone to do something for you. But, what is that? Most of the people interpret the service as Remote Procedure Call (RPC) or sending a message.
I believe that we are going to make a breakthrough in SOA adoption if replace the term service with concrete service types that developers and business people can relate to. For example we build applications:
– data;
– operations – programming logic;
– presentation component;
We can define standard interfaces for data service, operation service and presentation component service.

It is much easier to approach the business saying:
– Which data do you want to standardize? Customer, Order, etc. We do not need to discuss specific methods (like how to search for customers). It is handled by data service interface. At some point we need to define the access control to data for different user roles.
– Which business operations do you to standardize? Check customer credit, address validation, etc.
– Which presentation functionality do you want to standardize? Those are coarse-grain presentation components that implement certain workflow like: Make payment, Select cell phone plan, etc.

Conceptually every enterprise application can be a client or server of such services, but it also may make sense to deploy the services in specialized enterprise repositories.

The benefits are really obvious when coupled with an application-level architecture that is based on the same service types. For example it gives developers the flexibility to get a data object from locally implemented data service (using access to DB), another application or Enterprise Data Repository.

SOA like any other term is good only when used in the right context. When used with IT people it allows you to communicate meaning in a condensed form. When used with business people or CEO it is bad term, because it does convey any meaning to them.

Business people will invest money in projects that either deliver ROI or solve important business problem. When IT people go to the business with a proposal for SOA project, they are asking money to replace the existing IT infrastructure with a vague promise of future ROI. That is not good enough for most businesses even in a good time, much less in today environment.

When I started my career as software developer, Borland came up with great suites of software developer tools, Turbo C, Turbo Pascal, etc. They were about to overtake Microsoft in this market. Borland were one of the first to jump on the object-oriented bandwagon. Unfortunately they made the decision to rewrite all their tools using object-oriented technology. By the time they did that Microsoft was a lightning years ahead of them and Borland lost most of the market share they had.

We should learn from this lesson and not kill the business with expenses that do not produce immediate ROI or provide competitive advantage. We should use SOA to deliver business value.

It is our term and we should keep it for ourselves. After all even we cannot agree on a single SOA definition. I see ‘big SOA’ and ‘little SOA’ terms proliferating and that is troubling. If SOA is an architectural approach you either use or not. There is nothing wrong in applying it iteratively. A company may be in an early phase of SOA adoption, but I would not call that ‘little SOA’.