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