Kerard R. Hogg

Service-oriented architecture and business process choreography in an order management scenario: rationale, concepts, lessons learned

Effective and affordable business-to-business process integration is a key success factor in the telecommunications industry. A large telecommunication wholesaler, supplying its services to more than 150 different service retailers, enhanced the process integration capabilities of its core order management system through widespread use of SOA, business process choreography and Web services concepts. This core order management system processes 120 different complex order types.On this project, challenging requirements such as complexity of business process models and multi-channel accessibility turned out to be true proof points for the applied SOA concepts, tools, and runtime environments. To implement an automated and secured business-to-business Web services channel and to introduce a process choreography layer into a large existing application were two of the key requirements that had to be addressed. The solution complies with the Web Services Interoperability Basic Profile 1.0 and makes use of executable business process models defined in the Business Process Execution Language (BPEL).This paper discusses the rationale behind the decision for SOA, process choreography, and Web services, and gives an overview of the BPEL-centric process choreography architecture. Furthermore, it features lessons learned and best practices identified during design, implementation, and rollout of the solution.

SOI (Service Oriented Integration) and SIMM (Service Integration Maturity Model An Analysis

The constellation of SOA entities encompasses a triplet of Service consumer/provider and an optional registry. In the normal style, the service provider (“Service”) is instantiated and the details are stored in a registry. Service consumers seeking the required service explore the registry, locate the Service end points, receive the service contracts (normally as WSDLs), comply with the established contracts in order to consume the service. While this is an ideal scenario, in integration based environments the style differs where integration enablers as services are required to be built to aid integration. Thus Service Oriented integration (SOI) would mean the following depending on the type of players in the IT industry:• To an ISV (Independent Software Vendor) who develops products, SOI would mean exposing loosely coupled interfaces to be consumed easily by abstracting the implementation;• To a systems integrator, this would mean creating and hosting integration enablers as services( most of the times in the middleware layer) to be consumed by applications which in turn might fulfill the intended functionality by interacting with one or more back end applications. SIMM (Service Integration Maturity Model) defines a maturity model of such SOI based environments. This maturity model in turn will serve as an index to measure the level of flexibility and agility of an industry’s IT Environment to the changing needs of the business which is the key goal of SOA. Though there are many factors affecting SIMM, standards and modularity play a key role. In this paper we intend to analyze SIMM characteristics, benefits of standards combined with modularity, different enterprise environments and suggest the relevance of standards in each environment. In section I, we briefly discuss the functionality of integration enablers and various patterns. In Section II, we discuss the SIMM characteristics combined with modularity, explore in detail the various types of enterprises and requirements to comply with standards to achieve greater SIMM and finally conclude.

SOI (Service Oriented Integration) and SIMM (Service Integration Maturity Model

The constellation of SOA entities encompasses a triplet of Service consumer/provider and an optional registry. In the normal style, the service provider (“Service”) is instantiated and the details are stored in a registry. Service consumers seeking the required service explore the registry, locate the Service end points, receive the service contracts (normally as WSDLs), comply with the established contracts in order to consume the service. While this is an ideal scenario, in integration based environments the style differs where integration enablers as services are required to be built to aid integration. Thus Service Oriented integration (SOI) would mean the following depending on the type of players in the IT industry:• To an ISV (Independent Software Vendor) who develops products, SOI would mean exposing loosely coupled interfaces to be consumed easily by abstracting the implementation;• To a systems integrator, this would mean creating and hosting integration enablers as services( most of the times in the middleware layer) to be consumed by applications which in turn might fulfill the intended functionality by interacting with one or more back end applications. SIMM (Service Integration Maturity Model) defines a maturity model of such SOI based environments. This maturity model in turn will serve as an index to measure the level of flexibility and agility of an industry’s IT Environment to the changing needs of the business which is the key goal of SOA. Though there are many factors affecting SIMM, standards and modularity play a key role. In this paper we intend to analyze SIMM characteristics, benefits of standards combined with modularity, different enterprise environments and suggest the relevance of standards in each environment. In section I, we briefly discuss the functionality of integration enablers and various patterns. In Section II, we discuss the SIMM characteristics combined with modularity, explore in detail the various types of enterprises and requirements to comply with standards to achieve greater SIMM and finally conclude.