SOA Migration Step 2: Enterprise Service Bus (ESB) Evaluation

This step is the next step of SOA Migration Step 1: SOA Assessment. The backbone of SOA is the Enterprise Service Bus (ESB). ESB provides the infrastructure to register services, to route events/requests to the appropriate service provider, and to transform incoming XML messages. The biggest benefit of ESB is to make integration efforts declarative and not developmental. US Trust will be able to register new services with ESB, swap obsolete services, monitor business activities, and most importantly create a unified integration pattern for either existing applications or external trading partners/clients.

Initial Validation Testing

The main purpose of the initial test is to perform end-to-end test for the ESB infrastructure across all layers (not real business case). It will simply validate ESB infrastructure and provide a comfort level to US Trust. For instance, this test will include a generation of some file from Advantage, ESB will receive an FTP event based on that file, ESB will route this event to some service provider, a message will be transformed into “copybook” format, and a legacy component will be invoked either as a scheduled task or as batch program.

How to check the Capabilities of the Existing ESB?

Communication

• Check if Incoming requests can be routed to outgoing partner links.
• Check if there is support for communication using Web services SOAP over HTTP and SOAP over JMS, RMI over IIOP, Java and JMS.
• Check if there is support for event-based calls.
• Check if there is Synchronous and Asynchronous support for process and activity interfaces.

Service Interaction

• Check if WSDL interface is defined for each BPEL4WS process, and each activity within a BPEL4WS process.
• Check if Service providers can be substituted without changing the process structure.
• Check if there is any support provided for UDDI registries.

Integration

• Check if there is support for J2EE Connector Architecture resource adapters to connect to enterprise information systems such as CICS Transaction Server and IMS.
• Check if there is support for multiple transports, as defined by binding settings in WSDL definitions.  Service aggregation can be achieved using parallel process paths and data mapping.

Service level

• Check if Processes can contain multi-threaded, parallel execution paths.
• Check if multiple server instances can be scaled using standard WebSphere clustering techniques.

Quality of Service (QOS)

• Check if Business process instances are persisted and can survive a server restart or failure.
• Check if Business processes can leverage J2EE transaction support.
• Check if Compensation can be used to compensate transactions that have already committed, or to compensate activities that cannot be rolled back due to their non-transactional nature.
• Check if Support of JMS implemented with WebSphere MQ allows assured message delivery.

Security

• Check if there is support for J2EE.
• Check if Process-level authorization can be set, with roles resolved by a pluggable user registry.

Message Processing

• Check if XML message structures can be transformed using XSLT.
• Check if Message and data structures can be transformed, aggregated, correlated and validated using Java code snippets.
• Check if Elements in a data structure can be populated using an assign activity, if no data transformation is required.

Management and Autonomic

• Check if Business Process Web Client provides full administration of business process templates and instances.
• Check if Process instances can be monitored in the Business Process Web Client, or using the Business Process Engine API.
• Check if Server-related administration provided in the Administrative Console.
• Check if Process interfaces can be registered in a directory, such a UDDI.
• Check if Logging and tracing facilities provided.

Modeling

• Check if Broad support for data formats, including SOAP.
• Check if Development and deployment tooling is provided with WebSphere Studio Application Developer Integration Edition.

Infrastructure Intelligence

• Check if Business Rules Beans support allows business rules to be dynamically changed at runtime without modifying or redeploying a process.

See the next SOA Migration Step : SOA Migration Step 3: Requirements, Analysis, Design and Implementation

Tags: Enterprise Service Bus, ESB, SOA, SOA Migration, SOA Tutorial