soa

Service Layer and Model Design

When designing services, it is important to create categories that the different types of service requirements fall into. This allows us to establish standards, best practices, and reference implementations for those types of services. Also, we can better understand the problem domain by understanding the service requirement and then being able to apply a solution for all services within that service layer.

Two of the better books for service layers and models are:

These books refer to concepts (such as Thomas Erl talks about at http://serviceorientation.com), three types of service layers called task service layer, entity service layer, utility service layer. You can find an explanation for these at the following site:

ServiceOrientation.com – Service Layers

We can see a similar concept when reading the Oracle SOA Reference Architecture, the following diagram is a representation of that from a technical article. It classifies different service layers and the types of services that exist.

OracleSOAReferenceArchitecture
A Guide to Ensuring the Success of Your SOA Governance

There is also a similar reference or description within the Oracle AIA (Application Integration Architecture) documentation:

OraclesAIASharedServicesInventory
Understanding the Oracle AIA Reference Architecture

The interesting thing about reading through the materials, is that the concept of designing services or web services is no different from designing proper APIs. The issue is that as teams are new to the concept of designing services, the concept seems foreign and therefore is treated totally different from API design (which is probably a reflection of sloppy API design). So taking these suggested categories, and the concepts for strategies that are used for Java Application development we can define some generic service types.

The following are the types and these services are based on a functional role, some standards that help drive how they are developed, what dependencies they have, and what standards are applied to them.

  1. Access Service
  2. Utility Service
  3. Data Service
  4. Search Service
  5. Messaging Service
  6. Subscribe Service
  7. Business Service

This blog is a work in progress and I will continue to update with additional information.

Share and Enjoy

Service Model – Access Service

Access Services are designed specifically to proxy a 3rd party web service or API. In the realm of proxying a 3rd party web service, this is related to the pattern called Legacy Wrapper. The goal of this is to expose a Canonical Model to the enterprise or other services instead of the legacy model that is provided from the legacy application. This keeps the legacy application’s model from bleeding into the architecture, which allows for isolating the legacy service and provide the potentiality for replacing the service at a later date.

The Access Service is therefore responsible for doing mediation between the Canonical Model and the Legacy Model. This mediation can be done with different technologies and in different languages.

ESB Based Solutions for Mediation
Writing a Mediator in WSO2 ESB – Part I
XSLT transformations in Oracle Service Bus

Java Based Solutions for Mediation
Dozer is a Java Bean to Java Bean mapper

Obviously we can just write Java logic to walk the object graph of one messaging model and map it to another messaging model. This isn’t ideal, but the benefit is we don’t have to learn how to use a new API in order to do this, and we don’t have to run an ESB in order to provide mediation (see the Guerilla SOA presentation on InfoQ).

Because the services are 3rd party services or legacy services, there are no rules applied to the naming of operations within the contract. There are requirements around the naming of a service, as these services should have a suffix of AccessService. And if the internal framework proxies an external service call, then this service will have a suffix of ProxyService. This helps to identify how these services were developed and that there specific goal is to hide contracts that are not under enterprise control or are generated from legacy technology.

There is no special handling in the development of these services from a technology or framework perspective, unless the Access Service is a proxy for a remoting technology such as an EJB or RMI call where the Spring Integration Framework will be used to make these external calls. Spring/CXF will also be used with JAX-RS to invoke 3rd Party services that require an XML over HTTP capability.

For Java based endpoint development, a 3rd Party/Legacy web service can be integrated with by generating a client off of the WSDL, or we can create Java Interfaces (with JAX-WS annotations) and a model that represents the external model (with JAXB annotations). We can then use CXF’s JaxWsProxyFactoryBean to invoke the service (without an implementation), because this class can scan the JAX-WS/JAXB annotations from our interface/model in order to make the SOAP invocation.

As mentioned earlier, with Oracle Service Bus development, we would install our 3rd Party/Legacy WSDL and service configuration it as a Business Service. We would then develop a WSDL/Schema based on our enterprise requirements and Canonical Model and configure this as a Proxy Service (Proxy/Business Service in this aspect are Oracle Service Bus specific terms). Then a mediation or routing plan would be created in connecting the Proxy and Business Service together. Steps could be configured within the in/out pipelines to add an XSLT or XQuery transformation between the two Schema models, essentially providing the mediation layer.

These are both two different types of approaches that can be used to create these Access Services, and the decision may lay specifically with whether an ESB is available to assist in the integration, or because of time and technology skill set, it is just easier to do the development within Java.

Share and Enjoy