SOA What? Demystifying SOA for the Process Industry. Copyright, Notices, and Trademarks Honeywell International Inc All Rights Reserved

Transcription

1 SOA What? Demystifying SOA for the Process Industry Andrew Duca, Neil Freeman and Siggy Drews Copyright, Notices, and Trademarks

2 Contents Introduction... 3 Abstract... 3 Authors... 3 Service Oriented Architecture... 4 Background... 4 Definition... 4 Use Cases... 4 Technology Requirements... 5 Industry Standards... 6 Background... 6 The Standards Soup... 6 Pros and Cons of Current Content Standards... 6 Why is SOA important to the Process Industry... 8 Choosing an SOA Partner... 9 Conclusions P a g e 2

3 Introduction Abstract Interfacing of data between applications is always a problem for large Manufacturing Execution Systems. This is gradually getting easier and more uniform especially with the emergence of de facto standards such as Microsoft s Web Services. However by just interfacing data, businesses are still locking themselves into solutions that are unwieldy by not providing the flexibility to modify the processes needed to keep pace with the business. Service Oriented Architecture (SOA) is a methodology designed to provide interoperability between applications at service or business process level. This provides for more than just data interfacing in that the services that comprise applications are exposed and made available for integration. In this way not only data but business processes and workflow become explicit and released from within the confines of traditional monolithic applications. Hence business flexibility is enabled through ease of modifications to business processes and workflow empowering the process to keep pace with the business. SOA has been a philosophy adopted by the commercial world for many years however it is the new buzzword that is taking the process industries information systems by storm. This paper will provide an overview of what SOA is; why it is important to the process industries and what the value of adopting this technology is. Authors Andrew Duca Principal MES System Architect, Honeywell Process Solutions, Pheonix, USA Neil Freeman Principal Consultant Mining and Metals, Honeywell Process Solutions, Perth, Australia Siggy Drews Account Executive Mining and Metals, Honeywell Process Solutions, Johannesburg, South Africa P a g e 3

4 Service Oriented Architecture Background There is a tremendous amount of literature and attention being generated about SOA today. It has penetrated the financial and telecommunications industries as well as many others and is starting to garner a lot of attention within the process industry. This paper will attempt to demystify what SOA is, why it s important, and how it helps to simplify the complexity of existing solutions and deployments. Definition Service Oriented Architecture is an architectural style founded on the provision and consumption of services. Practically speaking, a service is a software program that implements a useful and reusable unit of work that can be interacted with through a well-defined interface. A key difference between SOA and other software architectural styles are that services are defined at an abstraction level relevant to the users of the service, while hiding the implementation details of the underlying service. Typically, services related to business functions like Create Order or Update Inventory rather than software functions such as inserting or updating records in a database. At this level, services can provide a common ground between the IT and the business requirements. Services and Web Services are often used interchangeably, and while it is true that most Service Oriented Architectures are based on web services, services can be implemented and hosted in multiple environments. It is also important to note that many existing web services are not suitable for use in Service Oriented Architectures, due to insufficient abstraction, poorly defined interfaces, or lack of support for relevant standards. A Service Oriented Architecture is broader than just simply services, it also includes the aggregation of services into higher order workflows, themselves services, that meet a specific business process need. Well architected SOAs exemplify a loose-coupling between services and the underlying operating system or supporting technologies to achieve a composition framework where business process or user interfaces can be customized, extended, or changed. A complete SOA includes the necessary infrastructure to support service composition to meet the requirements of end to end integration. Use Cases There are a number of use cases that are enabled by a Service Oriented Architecture: 1) External Integration Standards-based integration between systems using loosely coupled, high level services implemented at system or application boundaries. Integration often crosses domains and consolidated end points are P a g e 4

5 often used to minimize security exposure. Examples are interfaces between ERP and MES or MES and the DCS. 2) Application Integration - typically within a system or domain, to implement a business workflow. Services are typically implemented at the application boundary and expose application functions and data at the appropriate level to support workflows tailored to customer or industry needs. These workflows in turn may be exposed as services for integration into higher level business processes. Examples include integration between Planning & Scheduling, Production Dispatch, and Production Reconciliation & Reporting applications 3) Information Access Provision interfaces to allow commodity software to access and display application information, often in context with other business information. Examples are support for portals, third party tools and Office products such as the integration of Production or Maintenance Schedules with calendar programs. 4) Application Decomposition Applications are decomposed into a number of finer-grained functions which are exposed as services. These fine-grained services may be re-used by multiple applications and/or composed into coursegrained services for different markets or customers. Technology Requirements Commodity Tools External Applications Application Function External System The technology choice for a service oriented solution needs to consider a number of requirements including: System Function Application Function - Support for interoperability in a heterogeneous technology environment (.NET, Windows, SAP NetWeaver, IBM WebSphere ) - Support for Industry Standards (ISA S-95, MIMOSA ) - Support for complex network topologies (Internet, WAN, Process Control Networks, firewalls, DMZ ) - Support for WS-* standards (WS-Security, WS-ReliableMessaging ) - Support for different requirements (e.g., performance, transport, security ) - Support for messaging, orchestration, data mapping - Support for service management, versioning, visibility, deployment - Support for Model and event driven architectures - Support for service hosting and brokering and business data integration - Support for workflow customization and management 3 Figure 1: SOA Use Cases P a g e 5

6 Industry Standards Background Users have a job to do and simply want the information that they need to perform their job. In an ideal world, these users could select software that meets their business needs and which seamlessly forms a part of the overall IT architecture. The software industry has come a long way over the last 30 years, introducing new technologies that promise improved integration and interoperability such as Open Systems, Ethernet, SQL, CORBA, COM/DCOM, OPC, XML, and Web Services. While each new technology introduction has lowered the barriers to integration, none have managed to deliver on the promise of true plug-and-play interoperability. Fast forward to today, and while it is easier than ever to wire-up components from different vendors, we still struggle with interoperability through the management and transformation of content, largely because many vendors still expose their proprietary data structures via web services that don t communicate through a common language or standard. True interoperability will only be accomplished once messages published and received between software modules are understood, and given that there are literally thousands of traditional software application in any corporate IT architecture, meeting this goal requires that industry standards for message content are well-defined and universally implemented. The Standards Soup Quite naturally, the early initiatives to define and maintain content standards focused their activities on a particular area of domain expertise. For example, the ISA S95 group focused on models and terminology for the exchange of information between ERP and MES/CPM systems, while the MIMOSA group traditionally focused on models to support Operation and Maintenance of Plant Assets. Both unfortunately need to define an equipment model, for example, and as a result there is overlap between these groups as well as many others. As we look across the landscape of content standards for the process control industry, the question becomes; which content standard should I chose or support, and when should I chose one standard over another? Several standards bodies are working to eliminate this overlap, and have come together to form a working group, whose goal is to develop guidelines that explain how the various standards will merge and / or how users should select from the overlapping capabilities. The Manufacturing Interoperability Guideline (MIG) working group will be harmonizing industry guidelines for business process models between operation management and business layers of manufacturing support systems. This working group has voting members from each of the following organizations: ISA S95, World Batch Forum B2MML, OAGi, MIMOSA, OPC Foundation, as well as advisory representatives from several vendors including: Honeywell, IBM, SAP, Oracle, and the ARC Advisory Group which also coordinates customer representation through their Interoperability Customer Advisor Council. Pros and Cons of Current Content Standards Adopting standards provides benefits in many areas, starting at the bid and proposal stage with the ability to easily define requirements for message interchange, and extending through to the project implementation where component re-use is can be realized through the adoption of a standard schema for message exchange. P a g e 6

7 There are challenges also. The schemas for the content standards are generally complex and are increasing to accommodate the merging of different standards. Also, a single standard generally does not cover all requirements, and once multiple standards are used, you run into overlap between the standards. The MIG Working Group will eventually simplify some of these overlaps, but in the meantime, there will be a strong potential for differences in standards support between vendors. P a g e 7

8 Why is SOA important to the Process Industry To remain competitive in today s environment, organizations must continually improve their current business processes whose ultimate end goals are to improve productivity, profitability, safety, and reliability, while decreasing production costs and downtime, while also coping with an aging workforce, globalization, and increasing regulatory compliance pressures. Some quick wins for IT are: lower costs through server consolidation and virtualization, enterprise globalization, enterprise services, improved security, performance, uptime, service management, etc. A common emphasis is on the IT Infrastructure. For the business, some quick wins include: improvements in data integration, data visibility, portal integration, business intelligence, role-based access, improved integration, interoperability, and presentation. Dealing with the conflicting needs of the Business and IT is an important consideration in undertaking a SOA initiative. Honeywell believes that both can be addressed through the proper application of technology, standards, and governance. In putting together a SOA initiative, a first step is to understand your company s business processes, followed by the development of an information strategy complete with performance indicators that can be used to show progress and results. From this, a blueprint for SOA realization can be created as well the identification of the quick wins that further demonstrate the value received to stakeholders. The use cases enumerated in the prior section describe different interoperability and composition scenarios. For the business and IT departments, the External and Application integration scenarios enable integration between heterogeneous applications and systems (e.g., ERP to MES, application to application.). Explicit definition of contracts and schemas between service consumers and providers facilitates management of multivendor solutions, consistency of design and development across projects with more consistent, predictable, and better tested solutions as well as alignment with industry trends. This aspect can t be highlighted enough, as content standards continue to evolve; the ability to easily map between services from different vendors will enable organizations to be successful in rolling out multi-vendor solutions or integrating with external systems. Information Access scenarios help to achieve data visibility and data integration requirements that help to achieve goals that revolve around the single version of the truth. In a properly formed SOA, Application Decomposition scenarios provide the flexibility to create composite solutions and workflows that are tailored to the needs of the business and the ability to easily accommodate changing business requirements often via configuration changes. In summary, SOA provides the agility and adaptability for businesses to stay competitive in today s changing environment. P a g e 8

9 Choosing an SOA Partner A key element in the process of choosing an SOA partner is to understand what your business model for adopting and rolling out a Service Oriented Architecture is and how that affects your cost of ownership. One methodology is that applications are purchased for their set of services for the purpose of integrating the base services into a custom framework. Contrast this to the view of looking at the offering as a complete system and how it integrates into pre-existing infrastructure. In either case, understanding how the system is constructed and its integration approach are crucial to understanding how it supports these two models. Customization of the offering is also generally required to adapt the applications to the work practices and business processes of an organization. Understanding how the system is deployed, managed, and customized as well as the level of expertise required to do so help in assessing the short term roll-out costs as well as the long-term lifecycle costs. There are a number of areas to consider when looking at SOA offerings. Will the system scale to meet my requirements? How is the system managed and monitored? How are users and services provisioned? What are the security requirements and how do they integrate into the existing enterprise? What are the platform requirements? How does it integrate with existing applications and data? These and many other questions need to be formulated and answered. In addition to these more technical questions, it is also important to understand how the following themes are embodied in the solution as they play a critical role in areas of integration and customization. Services need to be defined with the right level of abstraction. Services that are too course-grained are not easily reused while services that are too fine-grained require more work when customizing or composing new solutions. Services need to do useful work and be able to accomplish that independently of other services. Contracts establish the communication agreement between services. They identify the structure and format of messages or information that is passed into and returned from a service. Well-defined contracts support service abstraction and allow services to be reused with other solutions or upgraded / replaced without impacting other systems. Services built with the right level of abstraction with well-defined contracts promote loose-coupling. This is an important consideration both in terms of composing new applications or customizing solutions, but also with respect to making deployment decisions about where services are deployed and how they will scale to meet changing usage requirements. Service discovery is the notion that services and their definitions have an outward projection that enables them to be discovered and used. While not exhaustive, these themes illustrate some of the complexities involved with SOA solutions and why they are import considerations. To support composition, services that have been defined with the right level of abstraction and with well-defined contracts become reusable, especially so when their contracts conform to industry standards for both content and communication. P a g e 9

10 Beyond the technical questions and general SOA themes, the following elements in a SOA solution form the cornerstone for a solution that is adaptable to an evolving business environment, reduces the cost of ownership and change, and protects your investment in existing solutions. SOA to the core a first step in the transition to SOA for many systems is to take a service wrapping approach. This clearly has an advantage of enabling integration of a non-soa based solution with other systems. Service wrappers place an interfacing layer on top of an application or components within an application that allow them to be exposed as services. Compare this to an approach where an SOA methodology embodied at all levels of the Figure 2: Scope of Change architecture. This later environment generally serves your cost of ownership better, as smaller pieces of the architecture can be improved, replaced, or upgraded independently of others. When evolving business condition demand change, the scope of change can more easily be minimized and managed. While the section earlier discussed information exchange through content standards, it didn t address how the information is managed within the system or the systems underlying model. A richly-defined model allows businesses to provide a truer representation of their system, thus enabling applications to provide more accuracy or better predictions in terms of planning and scheduling. One model, unfortunately, doesn t fit all, and thus requires the ability to extend or customize to accommodate specific needs of different industries or business. Systems built with a model driven architecture perspective empower domain experts with the ability to extend the underlying model and have that change: automatically create corresponding storage structures for the data; automatically generate services to access the information; provide the ability to automatically update displays that present the new information, and provide a rich contextual environment for using the new information in business services. All of these elements, data storage, data access, and visualization can be generated based upon change to the model and doing so lowers the cost of customization, improves the speed at which change can be effected, while ensuring a high-degree of reliability through generation rather than hand modification. Migration to a Service Oriented Architecture is a major concern for those that have deployed systems and are interested in upgrading or replacing their existing systems as evolving business and IT requirements demand more adaptable and manageable systems. The road to an SOA can take a couple of different paths; consider the rip-and-replace approach where an entire system and set of applications are replaced. While this achieves quicker SOA adoption, it must be weighed against other factors such as; the availability of a complete and compatible application suite for the SOA offering, the migration costs of moving data from older systems, the integration costs with systems that cannot be updated, or the cost of making the change all at once. Compare this to an evolutionary approach to where applications are updated over time in an order that derives the most P a g e 10

11 business value. In this model, the core SOA environment is put in place and integrated with existing solutions through a combination of service wrapping or the application of integration server / middleware components. While this approach generally takes longer to achieving a complete SOA adoption, it does afford higher investment protection with existing applications as well as spreading the cost for adoption over a longer term. Integration with the control system is another area where a services oriented approach can help. Historically, business applications have been run in a network that is separate from the control network, the reasons for doing so are outside the scope of this paper, but it is important to realize that in many control rooms today that evolving business conditions are requiring that control room engineers have access to both process information and business information. The common and easy approach to this today has been to have both the Plant Control Network (PCN) and the Plant Information Network (PIN) available providing access to process information on one network and business applications on a separate network. Providing access to business information and enabling interaction with business applications (e.g., initiating a maintenance request) in the control room without requiring separate networks is an area that SOA can help solve and that some SOA based solutions will be better able to support. P a g e 11

12 Conclusions To remain competitive and successful, businesses and vendors alike are looking to SOA as the roadmap for the future. It will provide the adaptability and agility to respond to changing business requirements. For the business, it will require investment, research, and careful evaluation of SOA partner offerings to ensure that the business requirements are met. P a g e 12