• Login
• Become a member
• RSS
• Part of the TechTarget network

Service-oriented architectures hold the promise to radically change business processes by replacing tightly coupled proprietary interfaces and data formats with standards-based reusable business interfaces. Conventional business processes and roles tend to be defined within company boundaries and focus on managing activities with the help of information available in tightly coupled enterprise information systems like ERP. In traditional systems, even the applications that ideally required loose coupling such as supply chain management and customer relationship management were also built to be hardwired to the existing ERP suite. The resulting system architecture offered efficiency, security and predictability, but at the same time took away flexibility and, hence, any scope of evolution of the process concerned.

As organizations grew in size, more and more activities of an organization were outsourced. This led to a steep increase in the number of interactions and interacting partners. This form of loosely coupled architecture could not possibly be supported using traditional tight coupling between business processes where a whole range of activity was bundled into a single application. The solution lay in functional decomposition of applications in reusable services that can be consumed by interested applications towards creation of a process.

In this article we describe a pilot showcasing SOA in a manufacturing and inventory management scenario. The objective

behind the creation of the pilot was identification of key issues faced while creation of processes from services and defining solutions to these issues. In the pilot we have captured a real life manufacturing scenario where a company accepts demand orders from multiple customers. The demand order is processed in a number of steps and finally a manufacturing order, or a purchase order, is generated. Purchase orders meant for individual vendors can be accessed via Web service over the Internet.

The pilot is implemented across three different layers of organizational SOA. A process orchestration engine is used for creation of business workflows in Business Process Execution Language (BPEL). At the integration layer ESB (enterprise service bus) is used, which calls multiple types of end points -- e.g., Web services, Java, EJB, JMS in some sequence -- and exposes them as Web services. It is also possible to create sub processes from these end points within the ESB. The ESB acts as a single point of request entry from the process engine. It takes care of exposing multiple types of end points as services, reliable messaging, content based routing, translation, policy based access, service metrics and security across multiple application domains. The ESB also maintains a metadata layer that defines structure of all the documents needed for a manufacturing process.

The process flow (figure 1) is triggered by submission of demand order from process engine to ESB where it is translated to a common format according to a metamodel (demand orders submitted by different clients can have different formats). It was realized that in absence of a metamodel, in order to incorporate a new demand order format (specific to a client) numerous translators need to be defined for each new consuming application. In the present scenario only one translator needs to be built for each incremental client format. After transformation to a common format, the demand order is routed by the ESB to calculate part and find the part type Web service interface, which is a sub-service created at the ESB level. These sub-services represent SOA at the integration layer and they themselves are consumed at the process layer. Consequently the orchestration engine calls inventory check service, then for the parts that do not have minimum stock, a manufacturing order or purchase order is raised based on whether the part is a manufactured or procured part.

At the process layer, a process itself is exposed as a Web service thereby hiding details of the steps and implementation involved from the consuming application.

The following are the key findings from the pilot:

• Distributed SOA should allow dynamic addition of trading partners with minimal effort.
• Sub-processes may be defined at the integration layer, which are consumed at the process layer. This functionality allows for grouping native interfaces together towards creation of coarse-grain services without exposing each of these interfaces as Web services and then creating processes using them, thereby reducing overheads of XML processing.
• Internal constitution of process need not be made visible to consuming applications, i.e. the process definition/interface should abstract out the workflow and involved services.
• Realization of SOA in case of a distributed process will require support for SOA at multiple layers of organizational IT, e.g. process, integration, service interface, etc.
• In absence of a domain-specific syntax, there is a challenge in integrating data formats specific to multiple trading partners. One way of addressing it is to define a metamodel for a particular domain at the integration layer. This approach will lead to standardization of communication formats within the enterprise and will require far less effort to add incremental clients.
• Apart from the basic requirement of creation of process from services, non-functional requirements like authentication across multiple domains, role-based access, services metrics, reliable delivery and translation needs to be implemented across services and hence these functions are ideal candidates to be implemented at the integration layer.
• Multiple types of endpoints (e.g. EJB, JMS, and Web Services) need to be accessed as services. There should be some means to abstract out the implementation-specific details and create processes by combining these interfaces.
• In the present scenario, in absence of proper specifications to manage transactions across long running distributed processes there should be appropriate means to communicate and manage errors.

Organizations have realized the there are definite benefits in the principles of SOA. However, there are different views regarding the right means for adoption of SOA. It is important to realize that SOA can exist in multiple flavors at different layers of enterprise IT architecture. It is incumbent on the adopting organization to choose the right approach, keeping in mind that the chosen architecture fulfills the promise of reusability and interoperability.

About the authors

Krishnendu Kunti is a senior technical specialist with Web Services/SOA Center of Excellence in SETLabs, the R&D arm of Infosys Technologies. He has contributed to architecting, design and testing of SOA-based data services frameworks for enterprise grade deployment of data services. His areas of interest include service-oriented architectures, data services and enterprise architectures. He can be reached at Krishnendu_kunti@infosys.com.

Bijoy Majumdar is a Senior Technical Specialist with Web Services/SOA Center of Excellence in SETLabs, the R&D arm of Infosys Technologies. He has contributed to architecting, design and testing of Syndeo, the in-house ESB from Infosys which provides for enterprise-grade deployment of services. His areas of interest include Web Services, ESBs and SOA. His professional experience includes compilation of proposals, business solution architectures, design and implementation with six sigma vigour. He can be reached at Bijoy_majumdar@infosys.com.

This article originally appeared on SearchSOA.com.

Join the conversationComment

All Rights Reserved,Copyright 2007 - 2013, TechTarget