IT2401 SERVICE ORIENTED ARCHITECTURE L T P C 3 0 0 3 UNIT I Roots of SOA Characteristics of SOA - Comparing SOA to client-server and distributedinternet architectures Anatomy of SOA- How components in an SOA interrelate - Principles of service orientation UNIT II Web services Service descriptions Messaging with SOAP Message exchange Patterns Coordination Atomic Transactions Business activities Orchestration Choreography - Service layer abstraction Application Service Layer Business Service Layer Orchestration Service Layer UNIT III Service oriented analysis Business-centric SOA Deriving business services- service modeling - Service Oriented Design WSDL basics SOAP basics SOA composition guidelines Entity-centric business service design Application service design Taskcentric business service design UNIT IV SOA platform basics SOA support in J2EE Java API for XML-based web services (JAX-WS) - Java architecture for XML binding (JAXB) Java API for XML Registries (JAXR) - Java API for XML based RPC (JAX-RPC)- Web Services Interoperability Technologies (WSIT) - SOA support in.net Common Language Runtime - ASP.NET web forms ASP.NET web services Web Services Enhancements (WSE). UNIT V WS-BPEL basics WS-Coordination overview - WS-Choreography, WS-Policy, WSSecurity TOTAL: 45 PERIODS TEXT BOOK: 1. Thomas Erl, Service-Oriented Architecture: Concepts, Technology, anddesign, Pearson Education, 2005. REFERENCES: 1. Thomas Erl, SOA Principles of Service Design (The Prentice Hall Service-Oriented Computing Series from Thomas Erl), 2005. 2. Newcomer, Lomow, Understanding SOA with Web Services, Pearson Education, 2005. 3. Sandeep Chatterjee, James Webber, Developing Enterprise Web Services, An Architect s Guide, Pearson Education, 2005. 4. Dan Woods and Thomas Mattern, Enterprise SOA Designing IT for Business Innovation O REILLY, First Edition, 2006.
TABLE OF CONTENTS S.NO TOPICS PAGE NUMBER UNIT I 1 Roots of SOA 1 2 Characteristics of SOA 1 3 Comparing SOA to client-server and distributedinternet architectures 8 4 Anatomy of SOA 9 5 How components in an SOA interrelate 9 6 Principles of service orientation 12 UNIT II 7 Web services 15 8 Service descriptions 15 9 Messaging with SOAP 16 10 Message exchange Patterns 24 11 Coordination 25 12 Atomic Transactions 25 13 Business activities 25 14 Choreography 27 15 Service layer abstraction 29 16 Application Service Layer,Business Service Layer Orchestration Service Layer UNIT III 17 Service oriented analysis 31 18 Business-centric SOA 31 19 Deriving business services- service modeling 32 20 Service Oriented Design 32 21 WSDL basics 33 22 SOAP basics 34 23 SOA composition guidelines 36 24 Entity-centric business service design 36 25 Application service design 37 26 Taskcentric business service design UNIT IV 27 SOA platform basics 39 28 SOA support in J2EE Java API for XML 39 29 37
29 -based web services (JAX-WS) - Java architecture for XML binding (JAXB) Java API for XML Registries (JAXR) - Java API for XML based RPC (JAX-RPC) 30 Web Services Interoperability Technologies (WSIT) 43 31 SOA support in.net 44 32 Common Language Runtime 45 33 ASP.NET web forms 46 34 ASP.NET web services 47 35 Web Services Enhancements (WSE). 47 UNIT V 36 WS-BPEL basics 50 37 WS-Coordination overview 50 38 WS-Choreography 51 39 WS-Policy 52 40 WSSecurity 53 41,42
UNIT-1 Introduction: ROOTS OF SOA Pre-requisite Discussion: Application architecture is to an application development team what a blueprint is to a team of construction workers. Different organizations document different levels of application architecture. An SOA can refer to an application architecture or the approach used to standardize technical architecture across the enterprise. Contents: CHARACTERISTICS OF SOA: Service-oriented architecture: An SOA can refer to an application architecture or the approach used to standardize technical architecture across the enterprise. The components of the basic (first-generation) Web services framework. This framework can be applied to implement services in just about any environment. Services are discoverable and dynamicallybound. Services are self-contained and modular. Services stress interoperability. Services are loosely coupled. Services have a network-addressable interface. Services have coarse-grained interfaces. Services are location-transparent. Services are composable. Service-oriented architecture supports self-healing. CONTEMPORARY SOA 1 S.SHARMILA 2015-2016
Major software vendors are continually conceiving new Web services specifications and building increasingly powerful XML and Web services support into current technology platforms. The result is an extended variation of service-oriented architecture we refer to as contemporary SOA. SOA increases quality of service Ability for tasks to be carried out in a secure manner, protecting the contents of a message, as well as access to individual services. Reliability so that message delivery or notification of failed delivery can be guaranteed. Overhead imposed by SOAP message and XML content processing does not inhibit the execution of a task. SOA is based on open standards Standard open technologies are used within and outside of solution boundaries. SOA supports vendor diversity 2 S.SHARMILA 2015-2016
SOA promotes discovery SOA encourages intrinsic interoperability SOA promotes federation 3 S.SHARMILA 2015-2016
SOA promotes architectural composability Different solutions can be composed of different extensions and can continue to interoperate as long as they support the common extensions required. SOA encourages intrinsic reusability 4 S.SHARMILA 2015-2016
SOA emphasizes extensibility Extensible services can expand functionality with minimal impact. SOA supports a service-oriented business modeling paradigm 5 S.SHARMILA 2015-2016
Partitioning business logic into services that can then be composed has significant implications as to how business processes can be modeled SOA implements layers of abstraction Application logic created with proprietary technology can be abstracted through a dedicated service layer. SOA promotes loose coupling throughout the enterprise 6 S.SHARMILA 2015-2016
SOA promotes organizational agility 7 S.SHARMILA 2015-2016
Client server Architecture: Mainframe back-ends served thin clients, are considered an implementation of the singletier client-server architecture Mainframe systems natively supported both synchronous and asynchronous communication. The latter approach was used primarily to allow the server to continuously receive characters from the terminal in response to individual keystrokes. Only upon certain conditions would the server actually respond. Distributed Internet Architecture: Distributing application logic among multiple components (some residing on the client, others on the server) reduced deployment headaches by centralizing a greater amount of the logic on servers. Server-side components, now located on dedicated application servers, would then share and manage pools of database connections, alleviating the burden of concurrent usage on the database server A single connection could easily facilitate multiple users. How the components of a service-oriented architecture relate. How the components of a service-oriented architecture define each other. 8 S.SHARMILA 2015-2016
ANATOMY OF SOA Application architecture is to an application development team what a blueprint is to a team of construction workers. Different organizations document different levels of application architecture. Service-oriented architecture: An SOA can refer to an application architecture or the approach used to standardize technical architecture across the enterprise. The components of the basic (first-generation) Web services framework. This framework can be applied to implement services in just about any environment. 1. Logical components of the Web services framework Each Web service contains one or more operations. This diagram introduces a new symbol to represent operations separately from the service. Each operation governs the processing of a specific function the Web service is capable of performing. The processing consists of sending and receiving SOAP messages, 9 S.SHARMILA 2015-2016
The Web services framework provides us not only with a technology base for enabling connectivity, it also establishes a modularized perspective of how automation logic, as a whole, can be comprised of independent units. The following fundamental parts of the framework: SOAP messages Web service operations Web services activities The latter three items represent units of logic that perform work and communicate using SOAP messages. messages operations services processes (and process instances) The one exception is the use of "process" instead of "activity." the word "activity" is used in different contexts when modeling service-oriented business processes. Web service activity is typically used to represent the temporary interaction of a group of Web services, a process is a static definition of interaction logic. An activity is best compared to an instance of a process wherein a group of services follow a particular path through the process logic to complete a task. messages = units of communication operations = units of work services = units of processing logic (collections of units of work) processes = units of automation logic (coordinated aggregation of units of work) Figure 4 provides us with a primitive view of how operations and services represent units of logic that can be assembled to comprise a unit of automation logic. Figure 4. A primitive view of how SOA modularizes automation logic into units. 10 S.SHARMILA 2015-2016
The messages are a suitable means by which all units of processing logic (services) communicate. No actual processing of that logic can be performed without issuing units of communication (in this case, messages). Figure 5 A primitive view of how units of communication enable interaction between units of logic. The purpose of these views is simply to express that processes, services, and operations, on the most fundamental level, provide a flexible means of partitioning and modularizing logic. Regardless of the technology platform used, this remains the most basic concept that underlies service-orientation. 11 S.SHARMILA 2015-2016
3. Components of an SOA A message represents the data required to complete some or all parts of a unit of work. An operation represents the logic required to process messages in order to complete a unit of work (Figure 6). Figure 6. The scope of an operation within a process. Components of SOA A service represents a logically grouped set of operations capable of performing related units of work. A process contains the business rules that determine which service operations are used to complete a unit of automation. In other words, a process represents a large piece of work that requires the completion of smaller units of work. Figure 7. Operations belonging to different services representing various parts of process logic. 12 S.SHARMILA 2015-2016
SIGNIFICANCE: The SOA is important because without this no service can be provided to the user easy and efficiently APPLICATION AREA: The service oriented architecture is used in all the web oriented service application in internet. GLOSSARY: CSA: client server architecture DIA: Distributed internet architecture SOA: service Oriented Architecture SOAP: Simple object access protocol REFERENCE: 1. Thomas Erl, SOA Principles of Service Design (The Prentice Hall Service-Oriented Computing Series from Thomas Erl), 2005 13 S.SHARMILA 2015-2016
UNIT II WEB SERVICES PRE-REQUISITE DISCUSSION: CONCEPT: SOA is Interoperation issues Heterogeneous network protocols Heterogeneous hardware platforms Heterogeneous operating systems Heterogeneous application formats 1 Increased Competitions 2 Enhancement of Business Capabilities 3 There must be consensus On Interoperability What is Web Services? 14 S.SHARMILA 2015-2016
Web Services can convert your applications into Web-applications. Web Services are published, found, and used through the Web. Web services are application components Web services communicate using open protocols Web services are self-contained and self-describing Web services can be discovered using UDDI Web services can be used by other applications XML is the basis for Web services Web Services can convert your applications into Web-applications. Web Services are published, found, and used through the Web. Web services are application components Web services communicate using open protocols Web,services are self-contained and self-describing, Web services can be discovered using UDDI Web services can be used by other applications XML is the basis for Web services There are five fundamental Web Services standards. Two of them are general standards that existed beforehand and were used to realize the Web Services approach: XML is used as the general format to describe models, formats, and data types. HTTP (including HTTPS) is the low-level protocol used by the Internet. The other three fundamental standards are specific to Web Services and were the first standards specified for them: Service is component of distinctive functional meaning that typically encapsulate a highlevel business concept 1 Lego block Service contains Contract message type def, constraint, description (comment) 2 Interface set of operations 3 Implementation Logic and data Web Services refers to a collection of standards that cover interoperability MESSAGING WITH SOAP: 1 SOAP - Simple Object Access Protocol 2 SOAP Envelope 3 SOAP Header 4 SOAP Body 5 SOAP Fault 15 S.SHARMILA 2015-2016
6 SOAP Roles 7 SOAP Message Exchange Patterns SOAP - Simple Object Access Protocol SOAP is short for Simple Object Access Protocol. SOAP is an XML based message format used in the client - service communication popularly called web services. SOAP XML Format includes SOAP Message Styles SOAP MEP (Message Exchange Patterns) SOAP Message Routing SOAP via HTTP SOAP Message Format Here is a simple sample SOAP message: <?xml version= 1.0?> <soap:envelope xmlns:soap= http://www.w3.org/2001/12/soap-envelope" > <soap:header> </soap:header> <soap:body> <soap:fault> This element is optional </soap;fault> </soap:body> </soap:envelope> A SOAP message consists of a Envelope element, inside which a Header and a Body element can be nested. Inside the Body element a Fault element can be nested, if an error occurs in the web service. Each of these SOAP elements will be explained on the following pages of this SOAP trail. SOAP Requests and Responses Both Use Envelope's The SOAP message format as shown earlier is used both to send requests from the client to the web service, and to send responses back to the client from the web service. Thus the SOAP request and response message format is the same. It is not like in HTTP where the request and response formats are different. SOAP Envelope The SOAP Envelope element is the root element in a SOAP message. Inside the SOAP Envelope you find a Header (optional) and a Body element. 16 S.SHARMILA 2015-2016
The name space declaration inside the Envelope element: xmlns:env="http://www.w3.org/2002/06/soap-envelope" This name space declaration must always be present in a SOAP Envelope element. The prefix (env) can change as you see fit. SOAP Header Table of Contents Header Child Element Attributes o mustunderstand o encodingstyle o role o relay The SOAP Header element is an optional child element of the Envelope element. Inside the Header element you can put information that is not part of the body of a SOAP message. Whatever that information could be, is up to you. For instance, it could be information about the maximum time the SOAP request may take to process, or something similar which is not directly related to the message itself. Here is a sample SOAP Header element (Header element marked in bold): <?xml version="1.0"?> <env:envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > <env:header> <jj:maxtime value="10000" xmlns:jj="http://jenkov.com"/> </env:header> <env:body> </env:body> </env:envelope> Header Child Element Attributes The Header child elements has a list of standard attributes you can use inside them: mustunderstand encodingstyle role relay Each of these attributes are described in the following sections. mustunderstand 17 S.SHARMILA 2015-2016
The mustunderstand attribute means that any node (computer) processing the SOAP message must understand the given header block. A "node" may not alway be the final of the SOAP message. The message might be routed via intermediate nodes before ending up at the receiving / processing node (the final web service). Here is an example: <env:header> <jj:maxtime value="10000" xmlns:jj="http://google.com" mustunderstand="true" /> </env:header> encodingstyle role The encodingstyle attribute is skipped here. A node processing / forwarding a SOAP message is said to act in one or more SOAP roles. Header blocks (elements) can be targeted at nodes acting in specific roles. In other words, if a header block is targeted for nodes acting in the "ultimatereceiver" role, then only nodes acting as ultimate receivers must process that header block. All other nodes should leave it unprocessed. SOAP roles are explained in more detail in the SOAP Roles text. relay The relay attribute determines if a header block is allowed to be relayed if not processed. In other words, if an intermediary node forwards the SOAP message without processing the header element in which the relay attribute is found, should that header element then be forwarded (relayed) in the message, or taken out? The relay attribute only has two valid values: 1. true 2. false If the attribute is set to true then this header element can be forwarded even if not processed.if the attribute is set to false then this header element should be removed if the message is forwarded. Omitting the relay attribute is equivalent to setting it to false. Here is an example header using a relay attribute: 18 S.SHARMILA 2015-2016
<env:header> <jj:maxrelaytime value="10000" xmlns:jj="http://jenkov.com" role="http://www.w3.org/2003/05/soap-envelope/role/next" relay="true" /> </env:header SOAP Body The SOAP Body element is the element in a SOAP message that contains the main part to be processed by either client or web service. While a Header element is optional, a Body element is mandatory. You MUST have a Body element in a SOAP message. Here is a sample SOAP Body element (Body element marked in bold): <?xml version="1.0"?> <env:envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > <env:header> </env:header> <env:body> </env:body> </env:envelope> The body of a SOAP message can consist of pretty much whatever XML you feel like putting inthere, as long as it is valid. However, you cannot put text inside the Body element. Text should be nested inside child elements of the Body element. It is recommended that child elements of the Body element are name space qualified. Here are two Body element examples. The first example sends 4 parameters (elements) separately inside the Body element. The second example nest these 4 parameters inside a <service> element. 19 S.SHARMILA 2015-2016
These standards define both the protocols that are used to communicate and the format of the interfaces that are used to specify services and service contracts Fundamental Web Services Standards WSDL is used to define service interfaces. In fact, it can describe two different aspects of a service: its signature (name and parameters) and its binding and deployment details (protocol and location). SOAP is a standard that defines the Web Services protocol. While HTTP is the low-level protocol, also used by the Internet, SOAP is the specific format for exchanging Web Services data over this protocol. UDDI is a standard for managing Web Services (i.e., registering and finding services). Message exchange patterns SOAP Fault Table of Contents 20 S.SHARMILA 2015-2016
SOAP Fault Structure o Code Reason Node Role Detail The SOAP Fault element is returned inside the Body element from a web service (or intermediary node) in case an error occurs while processing the received SOAP message. Here is a sample SOAP Fault element (Fault element marked in bold): <?xml version="1.0"?> <env:envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" > <env:body> <env:fault> <env:code> <env:value>env:sender</env:value> </env:code> <env:reason> <env:text xml:lang="en-us">processing error</env:text> <env:text xml:lang="da">processerings-fejl</env:text> </env:reason> </env:fault> </env:body> 21 S.SHARMILA 2015-2016
</env:envelope> xmlns:jj="http://jenkov.com" >10000</jj:MaxRelayTime> </env:detail> </env:fault> SOAP Roles Table of Contents Predefined SOAP Roles Custom SOAP Roles SOAP Roles in Header Elements SOAP Roles in Fault Element A node processing / forwarding a SOAP message is said to act in one or more SOAP roles. Here is a simple diagram showing 3 nodes (computers) involved in the processing of a SOAP message: Nodes acting in different SOAP roles during SOAP message processing. The first node is the sender. This role is not mentioned in the SOAP specification though. The second node is an intermediary node which forwards the SOAP message. Intermediary nodes may also alter the SOAP message. For instance, they may add, modify or remove header elements, or even change the body. Intermediary nodes are set to act in the next role. The last node in the diagram is the "ultimatereceiver" of the SOAP message. The ultimate receiver is the node that actually processes the SOAP message. It is the "web service" in other words. Clever minds may claim though, that the "web service" actually consists of the whole chain of SOAP message processing nodes, and not just the ultimate receiver. Predefined SOAP Roles The SOAP specification predefines three roles: 22 S.SHARMILA 2015-2016
SOAP Roles Role Name Role URI next http://www.w3.org/2003/05/soap-envelope/role/next none http://www.w3.org/2003/05/soap-envelope/role/none ultimatereceiver http://www.w3.org/2003/05/soap-envelope/role/ultimatereceiver The next role are assumed by both intermediary nodes, and the ultimate receiving node. The none role is special. No node should act in the "none" role. Header blocks targeted at this role should usually either be left unprocessed, or is used when processing some other header block. The ultimatereceiver role is reserved for the ultimate receiver of the SOAP message. Header blocks without this role attribute value should not process that header block. Custom SOAP Roles SOAP roles are not limited to the three predefined roles listed in the previous section. SOAP roles can be any role you define yourself. If you define your own roles, you will also have to define the semantics of those roles yourself. In other words, you will have to decide what it means to act in these roles you make up yourself. SOAP Roles in Header Elements SOAP roles can be used in SOAP Header elements. Here is a Header example using the role attribute: <env:header> <jj:maxtime value="10000" xmlns:jj="http://jenkov.com" role="http://www.w3.org/2003/05/soap-envelope/role/ultimatereceiver" /> </env:header> When a SOAP Header child element contains a role attribute, only nodes acting in that role must process that element. All other nodes should leave it be. SOAP Roles in Fault Element 23 S.SHARMILA 2015-2016
SOAP roles can also be used in SOAP Fault elements. When used in a Fault element the role tells which role the faulting node was acting in, when the fault occurred. Here is a Fault element example using a Role element: <env:fault> <env:code> <env:value>env:sender</env:value> </env:code> <env:reason> <env:text xml:lang="en-us">error in Input Data</env:Text> </env:reason> <env:node>http://jenkov.com/thenodethatfailed</env:node> <env:role> http://www.w3.org/2003/05/soap-envelope/role/ultimatereceiver </env:role> </env:fault> SOAP MESSAGE EXCHANGE PATTERNS : Request - Response Response The SOAP specification mentions a concept called "message exchange patterns" (MEP). There are two basic message exchange patterns described in the SOAP specification: 1. Request - Response 2. Response 3. These two message exchange patterns are described in the following sections. 4. Request - Response 5. In a request - response message exchange the SOAP client sends a SOAP request message to the service. The service responds with a SOAP response message. 6. A request - response message exchange patterns is necessary when the 24 S.SHARMILA 2015-2016
SOAP client needs to send data to the SOAP service, for the service to carry out its job. For instance, if the client request that data be stored by the service, the client needs to send the data to be stored to the service. 7. Here is an illustration of a request - response message exchange: A SOAP request - response message exchange. Response In a response message exchange the SOAP client connects to the service, but does not send a SOAP message through. It just sends e.g. a simple HTTP request. The service responds with with a SOAP message. This message exchange pattern is similar to how a browser communicates with a web server. The browser sends an HTTP request telling what page it wants to access, but the HTTP request does not carry any additional data. The web server responds with an HTTP response carrying the requested page. Here is an illustration of the response message exchange pattern: A SOAP response message exchange. ATOMIC TRANSACTIONS & BUSINESS ACTIVITIES: Transactions as Atomic Actions Two Phase Commit Transactions A Two Phase Commit Weakness Transaction Coordination One Service Per Transaction A bank application needs to transfer money from one account to another. Currently the bank system has two services: Deposit Service Withdrawal Service Here is an illustration of the bank system: Service Transactions - a simple bank application using two services. Transactions as Atomic Actions 25 S.SHARMILA 2015-2016
A transaction groups one or more actions together, and makes sure they are executed as if it was just a single action. If one of the actions fail, all of the actions fail. Only if all actions succeed will the result of the actions be "committed" (permanently stored) to the system. Here is an illustration of the withdrawal and deposit service being grouped into a transaction: Service Transactions - two services grouped into a single transaction. Two Phase Commit Transactions Services participating in a transaction needs to be coordinated in order to assure that either all or non of the services called "commit" their actions within that transaction. A popular way to coordinate such distributed transactions is the "Two Phase Commit" protocol. The two phase commit protocol consists of three steps: 1. Begin Transaction 2. Prepare Phase 3. Commit Phase First all participants are told to participate in a transaction. From this point on, all actions carried out by each participant refering to this transaction, must be carried out as a single action (all or non). The actions cannot be committed to the main system yet, but must be kept internally in the participant (service), until the participant is instructed to commit the actions. Second, once all actions are executed successfully by all participants, all participants (e.g. services) are ordered to move to the "prepare phase". Once a participant is successfully in prepare phase, the participant must guarantee that all actions carried out inside the transaction are ready to be committed. If the participant fails after it has successfully moved into the prepare phase, it must be able to commit the actions once the participant is functioning correctly again. In other words, the actions executed inside the transaction must be able to survive even a participant crash / reboot. This is usually done by writing a transaction log to a durable medium, e.g a hard disk. If one of the participants cannot move to the prepare phase, all participants are ordered to rollback (abort) the transaction. If all participants successfully move to the prepare phase, then all participants are now ordered to commit their actions. Once committed, the actions are then visible in the system, and permently executed. 26 S.SHARMILA 2015-2016
A Two Phase Commit Weakness o The two phase commit protocol is not 100% secure. Imagine if a service crashes after entering the prepare phase. Now all services are requested to commit. Imagine that the failed service is the last service in the chain to be ordered to commit. But the commit order fails, because the service has crashed. o All other services in this transaction would already have committed their actions, but not this last one. Normally, the service would have to commit it's part of the transaction once the service is operational again. Here is an illustration of a two phase commit transaction where the last service fails to commit: Service Transactions - A two phase commit transaction failing. Transaction Coordination When multiple services are to participate in a transaction, some entity must coordinate the transaction. In other words someone has to say when the transaction begins, and when to move to the prepare and commit phases entity, the transaction coordinator, can be either: The application An enterprise service bus A separate transaction manager / service One Service Per Transaction A way to simplify transaction management in a service oriented architecture is to design the services so each transaction is contained within a single service. For instance, in the example at the beginning of this text the money transfer would be implemented as a separate service, instead of a transaction involving two services. ORCHESTRATION AND CHOREOGRAPHY Used to standardize enterprise application integration as well as to extend the integration to previously isolated systems Between enterprises, BPEL enables easier and more effective integration with business partners Definitions of business processes described in BPEL do not affect existing systems Is the key technology in environments where functionalities are already or will be exposed via Web services. Orchestration Usually used in private business processes 27 S.SHARMILA 2015-2016
A central process (which can be another Web service) takes control of the involved Web services Coordinates the execution of different operations on the Web services involved in the operation. The involved Web services do not "know" (and do not need to know) that they are involved in a composition process and that they are taking part in a higher-level business process. Only the central coordinator of the orchestration is aware of this goal, so the orchestration is centralized with explicit definitions of operations and the order of invocation of Web services Markup language for composing a set of discrete services into an end-to-end process flow The Top Down Perspective Choreography Does not rely on a central coordinator Each Web service involved in the choreography knows exactly when to execute its operations and with whom to interact Collaborative effort focusing on the exchange of messages in public business processes All participants in the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges. Orchestration versus Choreography From the perspective of composing Web services to execute business processes, orchestration is a more flexible paradigm and has the following advantages over choreography: The coordination of component processes is centrally managed by a known coordinator. Web services can be incorporated without their being aware that they are taking part in a larger business process. Alternative scenarios can be put in place in case faults occur. BPEL supports two different ways of describing business processes that support orchestration and choreography: 28 S.SHARMILA 2015-2016
Executable processes allow you to specify the exact details of business processes. They follow the orchestration paradigm and can be executed by an orchestration engine. Abstract business protocols allow specification of the public message exchange between parties only. They do not include the internal details of process flows and are not executable. They follow the choreography paradigm. BUILDING A BUSINESS PROCESS Specifies the exact order in which participating Web services should be invoked sequentially or in parallel. Express conditional behaviors. an invocation of a Web service can depend on the value of a previous invocation. Construct loops, declare variables, copy and assign values, define fault handlers, etc. By combining all these constructs, you can define complex business processes in an algorithmic manner Because business processes are essentially graphs of activities, it might be useful to express them using Unified Modeling Language (UML) activity diagrams. BPEL Steps consists of steps; each step is called an "activity." supports primitive as well as structure activities. Primitive ActivitiesPrimitive activities represent basic constructs and are used for common tasks, such as the following: Invoking other Web services, using <invoke> Waiting for the client to invoke the business process by sending a message, using <receive> (receiving a request) Generating a response for synchronous operations, using <reply> Manipulating data variables, using <assign> Indicating faults and exceptions, using <throw> Waiting for some time, using <wait> 29 S.SHARMILA 2015-2016
Terminating the entire process, using <terminate> Combining Primitives Combine these and other primitive activities to define complex algorithms that specify exactly the steps of business processes To combine primitive activities, BPEL supports several structure activities. The most important are: Sequence (<sequence>), which allows us definition of a set of activities that will be invoked in an ordered sequence Flow (<flow>) for defining a set of activities that will be invoked in parallel Structure Activities Case-switch construct (<switch>) for implementing branches While (<while>) for defining loops The ability to select one of several alternative paths, using <pick> Each BPEL process will also define partner links, using <partnerlink>, and declare variables, using <variable>. SIGNIFICANCE: Improved Integration, intrinsic interoperability Organizational agility Loosely-coupled with reusable assets and services Drives business processes closer to end users Leverage and integrate existing applications Provide standard connections between systems Abstract complexity for developers The SOA is important because without this no service can be provided to the user easy and efficiently APPLICATION AREA: The service oriented architecture is used in all the web oriented service application in internet. REFERENCE: 1. Thomas Erl, SOA Principles of Service Design (The Prentice Hall Service-Oriented Computing Series from Thomas Erl), 2005 UNIT 3 SERVICE ORINTED ANALYSIS 30 S.SHARMILA 2015-2016
PRE-REQUISITE DISCUSSION Service-oriented analysis establishes a formal analysis process completed jointly by business analysts and technology architects. Service modeling, a sub-process of service-oriented analysis, produces conceptual service definitions called imodeling processes result in the gradual creation of a service inventory blueprint. DERIVING BUSINESS SERVICES With the detailed example explain about the entity- centric business layer. Case Study This is only TLS's second service-oriented solution. The first was created to establish an external interface with their accounting system via a B2B environment. That solution was built according to the top-down delivery strategy and therefore resulted in a collection of entity-centric business services. Architects involved with the service design for this new Timesheet Submission application are pretty confident that the new set of services in no way overlaps with the existing ones. However, because the B2B solution was built by a completely different project team, they agree that it is worth the effort to review existing services before commencing with the design process. Their investigation reveals that the following entity-centric business services were delivered as part of the B2B project: Accounts Payable Service, Purchase Order Service, Ledger Service, and Vendor Profile Service STEP 1.. The Employee Service candidate. Step2. The existing inventory of TLS services. project architects then conclude that no overlap exists, which gives them the green light to proceed with the design of the Employee Service. TLS invested in creating a standardized XML data representation architecture (for their accounting environment only) some time ago. As a result, an inventory of entity-centric XSD schemas representing accounting-related information sets already exists. At first, this appears to make this step rather simple. However, upon closer study, it is discovered that the existing XSD schema is very large and complex. After some discussion, TLS architects decidefor better or for worsethat they will not use the existing schema with this service at this point. Instead, they opt to derive a lightweight (but still fully compliant) version of the schema to accommodate the simple processing requirements of the Employee Service. They begin by identifying the kinds of data that will need to be exchanged to fulfill the processing requirements of the "Get weekly hours limit" operation candidate. They end up defining two complex types: one containing the search criteria required for the request message 31 S.SHARMILA 2015-2016
received by the Employee Service and another containing the query results returned by the service. The types are deliberately named so that they are associated with the respective messages. These two types then constitute the new Employee.xsd schema file. <xsd:schema xmlns:xsd="http://www.w3.org/2001/xmlschema" targetnamespace= "http://www.xmltc.com/tls/employee/schema/accounting/"> <xsd:element name="employeehoursrequesttype"> <xsd:complextype> <xsd:sequence> <xsd:element name="id" type="xsd:integer"/> </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:element name="employeehoursresponsetype"> <xsd:complextype> <xsd:sequence> <xsd:element name="id" type="xsd:integer"/> <xsd:element name="weeklyhourslimit" type="xsd:short"/> </xsd:sequence> </xsd:complextype> </xsd:element> </xsd:schema> Example 15.2. The EmployeeHistory schema, with a different targetnamespace to identify its distinct origin. <xsd:schema xmlns:xsd="http://www.w3.org/2001/xmlschema" targetnamespace= "http://www.xmltc.com/tls/employee/schema/hr/"> <xsd:element name="employeeupdatehistoryrequesttype"> <xsd:complextype> <xsd:sequence> <xsd:element name="id" type="xsd:integer"/> <xsd:element name="comment" type="xsd:string"/> </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:element name="employeeupdatehistoryresponsetype"> <xsd:complextype> <xsd:sequence> <xsd:element name="responsecode" type="xsd:byte"/> </xsd:sequence> </xsd:complextype> </xsd:element> </xsd:schema> To promote reusability and to allow for each schema file to be maintained separately from the WSDL, the XSD schema import statement is used to pull the contents of both schemas into the Employee Service WSDL types construct. The WSDL types construct being populated by imported schemas. <types> <xsd:schema targetnamespace= "http://www.xmltc.com/tls/employee/schema/"> <xsd:import namespace= "http://www.xmltc.com/tls/employee/schema/accounting/" schemalocation="employee.xsd"/> <xsd:import namespace= "http://www.xmltc.com/tls/employee/schema/hr/" schemalocation="employeehistory.xsd"/> </xsd:schema> </types> The TLS architects decide on the following operations names: GetEmployeeWeeklyHoursLimit and UpdateEmployeeHistory They subsequently proceed to define the remaining parts of the abstract definition, namely the message, and porttype constructs. 32 S.SHARMILA 2015-2016
Example 15.4. The message and porttype parts of the Employee Service definition that implement the abstract definition details of the two service operations. <message name="getemployeeweeklyhoursrequestmessage"> <part name="requestparameter" element="act:employeehoursrequesttype" WSDL BASICS CONTENTS: WSDL stands for Web Services Description Language. WSDL is a language for describing web services and how to access them. WSDL is written in XML. WSDL stands for Web Services Description Language WSDL is written in XML WSDL is an XML document WSDL is used to describe Web services WSDL is also used to locate Web services WSDL is a W3C recommendation WSDL stands for Web Services Description Language. WSDL is a document written in XML. The document describes a Web service. It specifies the location of the service and the operations (or methods) the service exposes. he WSDL Document Structure A WSDL document describes a web service using these major elements: Element Description <types> A container for data type definitions used by the web service <message> A typed definition of the data being communicated <porttype> A set of operations supported by one or more endpoints <binding> A protocol and data format specification for a particular port type The main structure of a WSDL document looks like this: <definitions> <types> data type definitions... </types> <message> definition of the data being communicated... </message> 33 S.SHARMILA 2015-2016
<porttype> set of operations... </porttype> <binding> protocol and data format specification... </binding> </definitions> SOAP BASICS: A WSDL document can also contain other elements, like extension elements, and a service element that makes it possible to group together the definitions of several web services in one single WSDL document. WSDL Ports The <porttype> element is the most important WSDL element. It describes a web service, the operations that can be performed, and the messages that are involved. The <porttype> element can be compared to a function library (or a module, or a class) in a traditional programming language. WSDL Messages The <message> element defines the data elements of an operation. Each message can consist of one or more parts. The parts can be compared to the parameters of a function call in a traditional programming language. WSDL Types The <types> element defines the data types that are used by the web service. For maximum platform neutrality, WSDL uses XML Schema syntax to define data types. WSDL Bindings The <binding> element defines the data format and protocol for each port type. WSDL Example This is a simplified fraction of a WSDL document: <message name="gettermrequest"> <part name="term" type="xs:string"/> </message> 34 S.SHARMILA 2015-2016
<message name="gettermresponse"> <part name="value" type="xs:string"/> </message> <porttype name="glossaryterms"> <operation name="getterm"> <input message="gettermrequest"/> <output message="gettermresponse"/> </operation> </porttype> The TLS architect in charge of the Employee Service design decides to make adjustments to the abstract service interface to apply current design standards. Specifically, naming conventions are incorporated to standardize operation names The revised Employee Service operation names. Example The two operation constructs with new, standardized names. <operation name="getweeklyhourslimit"> <input message="tns:getweeklyhoursrequestmessage"/> <output message="tns:getweeklyhoursresponsemessage"/> </operation> <operation name="updatehistory"> <input message="tns:updatehistoryrequestmessage"/> <output message="tns:updatehistoryresponsemessage"/> </operation> As explained in the Apply naming standards guideline, the use of naming standards provides native support for intrinsic interoperability, a key contemporary SOA characteristic. If entirely new tasks are defined, then they can be incorporated by new operations that follow the same design standards as the existing ones. If new functional requirements are identified that relate to existing operations, then a common method of extending these operations is to add input and output values. This allows an operation to receive and transmit a range of message combinations. Care must be taken, though, to not overly complicate operations for the sake of potential reusability. It often is advisable to subject any new proposed functionality to a separate analysis process. Also, while it is desirable and recommended to produce entity-centric services that are 35 S.SHARMILA 2015-2016
completely self-sufficient at managing data associated with the corresponding entity domain, there is a key practical consideration that should be factored in. SOA COMPOSITION GUIDELINES Service composability is a design principle, applied within the service-orientation design paradigm, which encourages the design of services that can be reused in multiple solutions that are themselves made up of composed services. The ability of the service to be recomposed is ideally independent of the size and complexity of the service composition. This principle is directly responsible for the agility promised by SOA as it promotes composing new solutions by reusing existing services. ENTITY-CENTRIC BUSINESS SERVICE DESIGN (A STEP-BY-STEP PROCESS): Entity-centric business services represent the one service layer that is the least influenced by others. Its purpose is to accurately represent corresponding data entities defined within an organization's business models. These services are strictly solution- and business process-agnostic, built for reuse by any application that needs to access or manage information associated with a particular entity. Be cause they exist rather 36 S.SHARMILA 2015-2016
atomically in relation to other service layers, it is beneficial to design entity-centric business services prior to others. This establishes an abstract service layer around which process and underlying application logic can be positioned. APPLICATION SERVICE DESIGN TASKCENTRIC BUSINESS SERVICE DESIGN 37 S.SHARMILA 2015-2016
project architects then conclude that no overlap exists, which gives them the green light to proceed with the design of the Employee Service. TLS invested in creating a standardized XML data representation architecture (for their accounting environment only) some time ago. As a result, an inventory of entity-centric XSD schemas representing accounting-related information sets already exists. At first, this appears to make this step rather simple. However, upon closer study, it is discovered that the existing XSD schema is very large and complex. After some discussion, TLS architects decidefor better or for worsethat they will not use the existing schema with this service at this point. Instead, they opt to derive a lightweight (but still fully compliant) version of the chema to accommodate the simple processing requirements of the Employee Service. They begin by identifying the kinds of data that will need to be exchanged to fulfill the processing requirements of the "Get weekly hours limit" operation candidate. They end up defining two complex types: one containing the search criteria required for the request message received by the Employee Service and another containing the query results returned by the service. The types are deliberately named so that they are associated with the respective messages. These two types then constitute the new Employee.xsd schema file. SIGNIFICANCE The SOA is important because without this no service can be provided to the user easy and efficiently APPLICATION AREA: The service oriented architecture is used in all the web oriented service application in internet. REFERENCE: 1. Thomas Erl, SOA Principles of Service Design (The Prentice Hall Service-Oriented Computing Series from Thomas Erl), 2005 38 S.SHARMILA 2015-2016
PRE-REQUISITE DISCUSSION: Development environment Runtime APIs Operating system UNIT IV SOA platform basics The WS-Coordination framework exposes an Activation Service which supports the creation of coordinators for specific protocols and their associated contexts. The process of invoking Message Processing Logic The part of a Web service and its surrounding environment that executes a variety of SOAP message processing tasks. Message processing logic is performed by a combination of runtime services, service agents, as well as service logic related to the processing of the WSDL definition. Business Logic The back-end part of a Web service that performs tasks in response to the receipt of SOAP message contents. Business logic is application-specific and can range dramatically in scope, depending on the functionality exposed by the WSDL definition. For example, business logic can consist of a single component providing service-specific functions, or it can be represented by a legacy application that offers only some of its functions via the Web service. SOA support in J2EE: It is important for application development to allow Internet communication between programs. Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic. A better way to communicate between application-specific A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers. SOAP was created to accomplish this. SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages. 39 S.SHARMILA 2015-2016
SOAP Building Blocks A SOAP message is an ordinary XML document containing the following elements: An Envelope element that identifies the XML document as a SOAP message A Header element that contains header information A Body element that contains call and response information A Fault element containing errors and status information Syntax Rules Here are some important syntax rules: A SOAP message MUST be encoded using XML A SOAP message MUST use the SOAP Envelope namespace A SOAP message MUST use the SOAP Encoding namespace A SOAP message must NOT contain a DTD reference A SOAP message must NOT contain XML Processing Instructions <?xml version="1.0"?> <soap:envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingstyle="http://www.w3.org/2001/12/soap-encoding"> <soap:header>... </soap:header> <soap:body>... <soap:fault>... </soap:fault> </soap:body> </soap:envelope> The SOAP Envelope element is the root element of a SOAP message. The SOAP Envelope Element The required SOAP Envelope element is the root element of a SOAP message. This element defines the XML document as a SOAP message. Example 40 S.SHARMILA 2015-2016