What capabilities can a proxy in a SOA service layer handle?

When implementing a SOA web service layer, a number of issues keeps reappearing in service after service. They should, in other words, be taken care of in a separate service proxy layer on top of the services. The proxy layer could be implemented as a custom developed layer or with an ESB (Enterprise Service Bus).

Contrary to the more classical enterprise application integration (EAI) approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary. An ESB does not implement a service-oriented architecture (SOA) but provides the features with which one may be implemented. The ESB tries to remove the coupling between the service called and the transport medium.

The following capabilities a proxy/ESB can handle:

- Invocation - Support for synchronous and asynchronous transport protocols, service mapping (locating and binding)
- Ruoting - Addressability, static/deterministic routing, content-based routing, rules-based routing, policy-based routing
- Mediation and integration - Adapters, protocol transformation, service mapping
- Messaging - Message processing, message transformation and message enhancement
- Process Choreography - Implementation of complex business processes(think twice before getting into that as it ties you heavily to the ESB product)
- Service Orchestration - Coordination of multiple implementation services exposed as a single, aggregate service
- Quality of Service - Security (encryption and signing), reliable delivery, transaction management, SLA controls
- Management - Monitoring, audit, logging, metering, admin console, BAM
- Thread management - i.e limit number of concurrent calls to a base system

© Copyright 2009, Tomas Elfving