Butler Group on iWay Service Manager

Abstract

The iWay Service Manager can be considered as a third-generation integration product; moving the first and second-generation styles of point-to-point and hub-and-spoke into the new space that allows for more dynamic coupling between applications and infrastructure elements. A SOA helps address the limitations of the previous integration styles ? the management complexity and time taken to hand-code interfaces of point-to-point, and the expense and lack of agreed standards in the hub-and-spoke model. The iWay Service Manager is a runtime management system, and is less concerned with the high-level management of the SOA environment (although tools are available for this) than the actuality of ensuring controlled and controllable throughput during the execution of the process or transaction. iWay Service Manager is a complete integrated design environment that removes the need to code interfaces, write process code, and specify translation and transformation routines within the developed process-based applications. iWay Service Manager makes use of two constructs in its operation. Firstly, there are events, which are the messages that flow between systems. Secondly, there are services, which are the processes that are invoked when iWay Service Manager detects events. Although this is the terminology used by iWay to describe the operation of the solution, from an end-user perspective it is simply a complete management solution that can be used with the graphical interface to design process-centric applications without the need for developers to understand or map to the underlying infrastructure. With security such an important consideration in a SOA, it is relevant to note that iWay Software has created a more manageable security environment by decoupling security from the underlying protocols. Implementation for specific projects is simple and can be undertaken in as little as two weeks, and there is a strong provable ROI model. iWay Service Manager is marketed as an Enterprise Service Bus (ESB) and this negates the strong underlying technology of iWay Software's adapters.

The whole area of service management in a SOA environment is inherently complex and requires integration with disparate elements, and support of emerging standards, and iWay Software is aware of these requirements and future releases will ensure compatibility across the whole operational environment.



Product Analysis

Although iWay Service Manager is promoted as an Enterprise Service Bus (ESB), its history goes far beyond the invention of the ESB and relates more to iWay's core competencies and technical background in the connector and adapter market, and is more relevant to considering the management of a Service Oriented Architecture (SOA) from an holistic view rather than focusing on one element of the infrastructure stack. This is especially relevant if one considers an ESB as more of an architectural style reflecting middleware-type functionality rather than a dedicated product.

Whatever the view of ESB, there is no doubt that iWay Service Manager addresses the complexity of a SOA in three key areas:

- Service Provisioning.

- Service Consumption.

- Service Composition.

The iWay Service Manager can be considered as a third-generation integration product; moving the first and second-generation styles of point-to-point and hub-and-spoke into the new space that allows for more dynamic coupling between applications and infrastructure elements. A SOA helps address the limitations of the previous integration styles ? the management complexity and time taken to hand-code interfaces of point-to-point, and the expense and lack of agreed standards in the hub-and-spoke model. However, there are still issues to address, and these can be viewed in the three previously mentioned areas.

Service Provisioning ? Most of the applications in organisations are not Web service-enabled, and this means that programs have to be written to map the Web service interface to the Application Programming Interface (API). These mapping programmes are required for every process that has to interface with every application. This leads to a large amount of coding, and an ongoing requirement as processes change.