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 http://mycompany.com/customers) 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: http://shipka.com