Service Oriented Architecture Case: IBM SOA Reference Architecture

Transcription

1 Service Oriented Architecture Case: IBM SOA Reference Architecture Group 6: Mikko Seppälä Puranen Sami

2 Table of Contents 1 International Business Machines Corporation IBM and Services Oriented Architecture (SOA) Infrastructure IBM Service-Oriented Architecture solution stack Layers of Service-Oriented Architecture solution stack Layer 1. Operational layer Layer 2. Service component layer Layer 3. Services layer Layer 4. Business process layer Layer 5. Consumer layer Layer 6. Integration layer Layer 7. Quality of service layer WS-Reliable Messaging WS-Security WS-Transactions Layer 8. Information architecture and business intelligence layer Layer 9. Governance layer IBM WebSphere Application Infrastructure Application Integration Business process management Business Rule Management Systems Business Innovation and Optimization WebSphere Portals...18 References... 19

3 1 International Business Machines Corporation International Business Machines Corporation (IBM) is a multinational computer technology and IT consulting corporation. IBM manufactures and sells computer hardware, software and offers services. The services are ranging from infrastructure services and hosting services to consulting services. [1] IBM is well known as the world's largest computer company and systems integrator. IBM is the largest and most profitable information technology employer in the world. The company has scientists, engineers, consultants, and sales professionals in over 170 countries with over 398,455 employees worldwide. [1] 2 IBM and Services Oriented Architecture (SOA) Infrastructure IBM is market leader in SOA industry. IBM dominates the SOA infrastructure markets with more than half of the market, based on the report of Services Oriented Architecture (SOA) Infrastructure Market Shares, Strategies, and Forecasts, 2008 to 2014, developed by Research and Markets company. [2] IBM has gained this situation by inventing the concept of refining reusable solutions that have been around for a long time, adding a unique component and SOA manner, by making the SOA components work to create a worldwide integrated enterprise. While the IBM SOA is able to be used as a solution that works across a global enterprise, the SOA services as implemented in a middleware infrastructure are flexible enough to provide for local variation. Services oriented architecture (SOA) represents a fundamental change in the way automated process is delivered to replace manual process [2].

4 3 IBM Service-Oriented Architecture solution stack The Service oriented reference architecture defines the layers, architectural building blocks, architectural and design decisions, patterns and options. Service oriented reference architecture is usually presented in nine layers which each have own purposes. Layers of SOA reference architecture is presented in figure 1. [3] Figure 1 Layers of SOA reference architecture 4 Layers of Service-Oriented Architecture solution stack The Service oriented reference architecture follows the layering principle. It is decomposed into several layers, where each layer serves the layers above, to provide a set of services without revealing how they are implemented. In turn, layers rely on the services provided by the underlying layers [4]. 4.1 Layer 1. Operational layer The Operational layer s mission is to handle packaged application assets in the application portfolio running in an IT operating environment. The operational layer is built of application software systems. That effects directly to the overall cost of implementing the SOA solution. The existing software systems like monolithic custom applications (J2EE and Microsoft.NET applications), legacy applications, existing transaction processing systems and database includes to this layer. In addition enterprise resource planning (ERP) and customer relationship management (CRM) packages like SAP and Oracle are part of the existing software systems in the operational layer.

5 The IBM WebSphere DataPower SOA appliances section gives as a overview and an example about the product DataPower family and what are the strengths of this platform. To the end it will be shown that what is the position of appliances in frame of the network infrastructure. There are three primary products in the IBM DataPower family XA35, XS40, and XI50. The Data Power family has for example the following features: WebSphere MQ client option, WebSphere Java Message Service (JMS) Jetstream protocol connectivity, TIBCO Enterprise Message Service (EMS) connectivity, IBM IMS Connect client, Database option (DB2, Sybase, Oracle, SQL Server), Optimized run-time engine for non-xml transformations. [5] The IBM DataPower family strengths are integrating different platforms. Due to the variety of protocols,http, FTP, MQ, JMS/JFAP, IMS, NFS and so, supported by the DataPower appliances, there is a wealth of opportunity for protocol bridging, content enrichment, and integration between platforms. The XI50 DataPower appliance can handle either XML-to-XML or non-xml transformation scenarios, meaning that messages can be transformed to the appropriate format for any intended backend. DataPower family has also important feature in integration area like appliance as ESBs and WebSphere Message Broker (WMB) and WebSphere Enterprise Service Bus (WESB). [5]. IBM DataPower is also a Member of the Network Infrastructure. At their physical core, the DataPower appliances are network devices which can be split up so that two receive client traffic and the third connects to the backend private network, thereby segregating the network data for network security. IBM DataPower has also a number of network protocols supported on the appliance. These include HTTP, HTTPS, FTP, FTPS, SFTP, NFS, MQ, MQ/SSL, JMS, and Tibco EMS for application traffic, and SNMP, SMTP, sftp, and others for administrative usage. Specially SNMP is useful for infrastructure monitoring which can be achieved by using SOAP, as is the case with the integration with IBM Tivoli ITCAM for SOA. [5] 4.2 Layer 2. Service component layer Service component layer includes software components, figure 3, for operation on a service. Service components effect by functionality and by quality of service. These software components can present as Service Component Architecture (SCA) which based on the industry-standard serviceoriented architecture. SCA presents all business processes like Web services, Enterprise Information System (EIS) service assets, workflows and databases.

6 Figure 2 gives short abstract as example about service component layer functionality: The figure shows service A implemented using a combination of behavior from the third-party Package X and Application Y. Application B, the consumer, is coupled only to the description of the exposed service. The consumer must assume that the realization of the service is faithful to its published description, and it is the providers' responsibility to ensure that it is. The details of the realization are of no consequence to Application B. Service Component A acts as a service implementation facade, aggregating available system behavior and giving the provider an enforcement point for service compliance. [6] Figure 2. Service component The main function of Service Component Architecture is to separate business integration logic from implementation. It make possible that both a developer and on the other hand a implementator can focus their own business. Near by Service components lives business integration logic and implementation as shown in the following figure 3. Next sections gives a little bit deeper presentations about service components, service data objects, qualifiers and modules. Figure 3. The frame of service component Figure 4. The Service Component details The Service Components details are presented in a figure 4. A component consists of an implementation one or more interfaces, which defines its inputs, outputs and faults, and zero or

7 more references. A reference (R) identifies the interface of another service or component that this component requires or consumes. An interface (I) can establish in two languages like a WSDL port type or Java. Figure 4 also illustrates the service implementation types like Java objects, BPEL process, state machines, Business rules and so on.. These implementations will appear in services in the assembly editor and or within BPEL processes. [7] Service Data Objects (SDO) is a complement like a link which define the data flowing between components. Each component has traffic information (XML document) as input and output, so data objects are the preferred form for data in Service Component Architecture services. This information traffic acts like components. It means that service data objects separate the data object from its implementation, so developer can focus on working with business artifacts. In the figure 5 service data objects traffic is gone from an external service to an export. Then it continue from an export to a component, from a component to a component, from a component to an import, and to the end from an import to a service. [7] Figure 5. Service Data Objects The Service Components needs also service qualifiers. These are part of the quality of service (QoS) and they define the interaction between a service client and a target service. Qualifiers can be specified on service component references, interfaces, and implementations. It is possible to change qualifier s values without changing the implementation. The categories of qualifiers are transaction (rules for the type of transaction), activity session (rules for joining the active session), security (rules for permission) and asynchronous reliability (rules for asynchronous message delivery Modules). [7]

8 A module is a unit of deployment. It determines the artifacts in an Enterprise Archive (EAR) file. A module can be seen as a scoping mechanism - it sets an organizational boundary for artifacts. A module is also a composite of service components wihch imports and exports reside in the same project and root folder. There are two types of modules - module and a mediation module. The first one contains a choice of many component types and the second contains up to one component. A library is a project used to store shared resources among modules. These products are for example implementations, interfaces, business objects, business object maps, roles, relationships. [7] Figure 6. Module. In the figure 6, the module contains an export, two imports and a service component that uses them. Module and mediation module artifacts also includes several issues: module definition which defines the module definitions of the services in the module definitions of imports (calls to services external to this module) definitions of exports (expose components to callers that are external to this module) References from one component to another in the module Stand-alone references applications that are t defined as SCA components (JavaServer Pages) Other artifacts which include WSDL files, Java classes, XSD files, BPEL processes [7]

9 4.3 Layer 3. Services layer Services layer include of all the services defined within the SOA. This reference architecture is considered to be an abstract specification of a collection of business-aligned information technologies functions. The specification provides consumers with sufficient detail to invoke the business functions by a platform-independent. This usually done with the abstract stage of a Web Services Definition Language (WSDL) description. The specification also includes several issues like a policy document, SOA management descriptions and attachments that show service dependencies. [8]. The common properties for this layer are that services as functions are accessible across a network through well-defined interfaces. This layer also takes enterprise-scale components, business-unitspecific components, and project-specific components and externalizes a subset of their interfaces in the form of service descriptions. The components provide services through their interfaces that are exported as service descriptions. And those services are available in two way, in atomic or as composite services. This layer 3 also includes the contracts as service descriptions that bind the provider and consumer. Figure 7 presents that the services layer can be further divided into sublayers. And comparing figure 7 to figure 1 it can be noticed that the services that will be delivered by a given architecture, including both composite and atomic services. Figure 1 shows an SOA solution with the underlying middleware and infrastructure services. Those services are provided and categorized in figure 7 as the middleware view of the SOA reference architecture. [9] Figure 7. The middleware view of the SOA reference architecture

10 4.4 Layer 4. Business process layer In layer 4 Compositions and choreographies of services are defined. Service composition is used to combine groups of services into flows thereby establishing applications out of services. These applications support specific use cases and business processes. Figure 8 gives short abstract as example about functionality of business process layer. In the figure a business process P is implemented by using services A, B, C, and D from the services layer. Process P contains the logic for the sequence in which the services need to be invoked and executed. The services that are aggregated as a business process, or flow, can be individual services or composite services made up of individual services. [9] Figure 8. Services orchestration The process representation, composition methods, and building blocks for aggregating loosely coupled services includes all in the business process layer. Data flow and control flow are the tools for interactions (via enterprise or across multiple enterprises) between services and business processes. Other issues of business process layer are the life-cycle management and choreography. And the run-time process engine covers all aspects of composition, collaboration, compliance, process library, process service, and invocation elements.

11 Figure 9. Business Process Layer and Service Layer One of the principal of implementing an SOA is to provide a coupled integration platform. This means that application can instance to change and evolve without affecting the core integration technology. Same idea is also in the process modifications. Process requires different applications to communicate with each other which should not effect to the core integration technology. [8] This process and service independence helps to establish the relationship between business process modeling and application implementation. Figure 9 shows the relationship between BPM and SOA: BPM does the modeling, simulation, and redesign of processes. SOA infrastructure orchestrates business processes and mediates service providers. Services are exposed, to be used in various processes. Service changes should not impact processes. Process changes reuse various services as needed. [8] A business process captures the activities needed to accomplish a specific business goal. In general there are two approaches for business process definition, top-down and bottom-up. The top-down approach means that, business processes are defined by business analysts based on customers' requirements. And the bottom-up approaching means that after creating a set of assets, we would try to effect them in a meaningful business context to satisfy customer requirements. The flexibility and extensibility of services composition guided by business requirements and composition rules help make business process into an on demand entity for addressing different types of customer pain points by reusing services assets. [8]

12 A B C D Figure 10. Business process layer - the heart of SOA stack. Business process layer is kind of the heart of SOA stack. This sections describes how the business process layer linking to other layers: The business process layer 4 is dealing with the consumer layer 5 to communicate (red arrow A) inputs and results from the various people who use the system through Web portals or business-to-business programs. Most of the control-flow messages and data-flow messages of the business process may be routed and transformed (red arrow B) through the integration layer. The structure of the messages is most often defined (red arrow C) by the information architecture layer. The key performance indicators for each task or process could be defined (red arrow D) in the QoS and business intelligence layers. The design of service aggregations is guided by the governance layer [9] To the end it can say that the business process layer in the SOA solution stack plays a central coordinating role. This means that business-level requirements and IT-level solution components are connecting through collaboration with the layer 3 to layer 8. So, the challenging issues that come up in the business process layer can later affect the presented SOA solution stack from conceptual reference architectures proposed by other vendors.

13 4.5 Layer 5. Consumer layer Consumer layer describes the various channels through which the IT functions are delivered. The purpose of this layer is to standardize on the access protocol and data format to enable the quick creation of front ends to the business processes and services exposed from the layers below.[5] The adherence to standard mechanisms for developing the presentation layer components for the business processes and services helps in providing template solutions in the form of standard architecture patterns, which helps the developer community to adopt common front-end patterns for service consumption [10]. 4.6 Layer 6. Integration layer Integration layer provides the capability for service consumers to locate service providers and initiate service invocations. Integration layer has three basic capabilities, mediation, routing, and data and protocol transformation. Based on these capabilities, services can communicate with each other while being a part of a business process. Also nonfunctional requirements such as security, latency, and quality of service between adjacent layers in the reference architecture are implemented by the architecture building blocks in this layer. [10] The functions of Integration layer are typically defined as the enterprise service bus (ESB) which is a collection of architecture patterns that uses open standards and protocols to implement the three basic capabilities of this layer and provide a layer of indirection between the service consumers and the service provider by exposing the services only through the ESB. Figure 10 gives you a logical view of the enterprise service bus [10]. Figure 11 A logical view of the enterprise service bus (ESB)

14 4.7 Layer 7. Quality of service layer Quality of service layer focuses on implementing and managing the nonfunctional requirements that the services need to implement. These services are security, availability, scalability, and reliability. [10] The QoS layer of the current Web services standard stack (Figure 12) defines a set of standards to help developers and service providers enhance the quality of Web services at the message level and the transaction level. Current Web services QoS standards focuses on a couple of QoS attributes, such as security and reliability. Major requirements supporting QoS in Web services should include more attributes, such as availability, accessibility, integrity, performance, reliability, regulatory, and security. [11] Figure 12. QoS layer in Web services standard stack WS-Reliable Messaging WS-Reliable Messaging protocols allow different operating and middleware systems (such as IBM WebsphereMQ) to reliably exchange messages, thereby bridging different infrastructures into a single, logically complete, end-to-end model for Web services reliable messaging. The specification defines three basic assurances which can be combined as you wish [12]: In-order delivery The messages are delivered in the same order in which they were sent. At least once delivery Each message that is sent is delivered at least one time. At most once delivery No duplicate messages are delivered WS-Security WS-Security is the basic building block for secure Web services. WS-Security uses existing security models (such as Kerberos and X509). The specifications concretely define how to use the existing models in an interoperable way. Multiparty Web service computations cannot be secure without WS-Security. Security relies on predefined trust relationships. Kerberos works because

15 participants trust the Kerberos Key Distribution Center. Public Key Infrastructure (PKI) works because participants trust the root certificate authorities. [12] WS-Transactions WS-Transaction supports the notion of the service and participant as distinct roles, making the distinction between a transaction-aware service and the participants that act on behalf of the service during a transaction: transactional services deal with business-level protocols, while the participants handle the underlying WS-Transaction protocols. The finds two coordination types: Atomic Transaction for individual operations, and Business Activity for long running transactions. Developers can use either or both of these coordination types when building applications that require consistent agreement on the outcome of distributed activities. [13] Figure 13. WS-Transaction global view WS-ResourceLifetime In a distributed computing environment, a client may become disconnected from the service provider s endpoint and therefore may be unable to, or unwilling to cause the immediate destruction of the WS-Resource. The lifecycle of a WS-Resource is defined as the period between its instantiation and its destruction. [14] WS-ResourceLifetime specification standardizes the means by which a WS-Resource can be destroyed. The specification also defines the means by which the lifetime of a WS-Resource can be monitored. In addition, WS-ResourceLifetime defines the means by which a resource may be destroyed after a period of time. [14]

16 4.8 Layer 8. Information architecture and business intelligence layer Information architecture and business intelligence layer ensures a proper representation of the data and information that is required in an SOA. The data architecture and the information architecture representation (along with its key considerations and guidelines for its design and usage) at each specific horizontal layer are the responsibilities of this layer. Industry models (for example, ACORD, IAA, JXDD) and their usage to define the information architecture, along with business protocols used to exchange business data, are addressed in this layer. It also stores the metadata required for data mining and business intelligence. [10] 4.9 Layer 9. Governance layer Governance layer ensures the proper management of the entire lifecycle of the services. It is responsible for prioritizing which high-value services should be implemented, for each of the layers in the architecture, and for providing a rationalization based on how the service satisfies a business or IT goal of the enterprise. Enforcing both design-time and runtime policies that the services should implement and conform to is one of the key responsibilities of this layer. Essentially, this layer provides a framework that efficiently oversees the design and implementation of services so that they comply with the various businesses and IT regulatory policies and requirements.[10]

17 5 IBM WebSphere IBM WebSphere is a middleware software platform developed by IBM that provides extensive tools and technologies to integrate business processes and expose software systems to the web for a broader reach by company's employees, customers and partners. It was released in June 1998.[14] WebSphere was launched as a response to a growing industry concern that a number of software systems and platforms developed by companies over time hardly integrate with each other slowing down workflow and access to information. WebSphere was created to answer to this demand and implement an idea of application middleware [14]. WebSphere is based on J2EE technology and used to integrate legacy software and enable it to the web, providing single web interface for customers and corporate users. It is composed of the server software and development tools for web site developers and application developers. It also includes extensions for specific customer s needs like commerce sites, enterprise portals or cross-business solutions. WebSphere offers core solutions for different kind of SOA-layers. IBM product mapping is shown in Figure 14. [14] 5.1 Application Infrastructure IBM WebSphere Application infrastructure allows cost effectively build, deploy and manage applications for varying business needs. It can intelligently manage that infrastructure even when the situation calls for extreme processing [15]. 5.2 Application Integration Application integration and connectivity is core to working smarter and fundamental to a Smart SOA approach that enables information to flow freely within and across processes, fostering collaboration, insight and cost effective re-use of data and knowledge [15]. 5.3 Business process management Business Process Management (BPM) software and services optimize business performance by discovering, documenting, automating, and continuously improving business processes to increase efficiency and reduce costs [15].

18 5.4 Business Rule Management Systems Business Rule Management Systems enable flexible decision automation for systems that are subject to complex, variable and evolving rules Business Rule Management System tools and environments for developers, business experts and IT operations, providing a full lifecycle rule management and validation platform [15]. 5.5 Business Innovation and Optimization WebSphere solutions include tools for Business Innovation and Optimization. WebSphere Business Monitor captures real-time, work-in-progress items and perform corrective actions by reassigning or suspending activities or processes. It can display real-time data from work items produced as the monitored process is running, and can also retrieve and view the historical data of the process. 5.6 WebSphere Portals Web Sphere portals allow partners, employees and customers to choose their user experience, with personalized applications based on role, context, actions, location, preferences and team collaboration needs. IBM WebSphere Portal software provides a composite application or business mashup framework and the advanced tooling needed to build flexible, SOA-based solutions, as well as the unmatched scalability required by any size organization [15]. Figure 14. SOA Operating environment based on IBM WebSphere

19 References [1] International Business Machines Corporation (IBM) (referenced ) [2] Services Oriented Architecture (SOA) Infrastructure Market Shares, Strategies, and Forecasts, 2008 to (referenced ) [3] Service Oriented Reference Architecture (referenced ) [4] Layers of SOA Reference Architecture (referenced ) [5] An Introduction to DataPower SOA Appliances (2009). (referenced ) [6] Arsanjani A. et al (2006).Design an SOA solution using a reference architecture. [7] WebSphere Integration Developer. Technical product overview version (Fourth Edition (December 2006). [8] Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language is available at by R. Chinnici, J-J. Moreau, A. Ryman, S. Weerawarana (World Wide Web Consortium, Mar 2006). The latest version (Mar 2007) of WSDL Version 2.0 Part 1: Core Language is available at

20 [9] Gopala Krishna Behara (2006). BPM and SOA: A Strategic Alliance. (referenced ) [10] Layers of SOA Reference Architecture (referenced ) [11] Solution-Level Quality of Service in SOA (referenced ) [12] WS-Transaction (referenced ) [13] WS-ResourceLifetime (referenced ) [14] IBM WebSphere (referenced ) [15] IBM WebSphere (referenced )