The document discusses Service Oriented Architecture (SOA) and the role of the Business Process Execution Language (BPEL). It defines SOA as an architectural style that allows components to work together through standardized interfaces. BPEL is presented as an XML-based language used to specify business processes composed of discrete web services. BPEL allows the orchestration of services by defining message sequences and processing logic. It bridges the bottom-up exposure of services and the top-down definition of business processes in SOA.

1. SOA & BPEL: Basics

2. Agenda What is SOA What are Services? Why Composite Applications BPEL in the Mix Summary

3. What's the need? Architecture should be such that IT enterprises has the infrastructure is heterogeneous across operating systems, Must be process centric not data centric Should keep up with business process change. Should address the business process. Leverage existing investments in applications and application infrastructure to address newer business requirements EAI solutions are technically very complex, need specialized skills and are very expensive to maintain. an enterprise employing SOA could create a supply chain composite application using a set of existing applications that expose the functionality via standard interfaces

4. Service Oriented Architecture In April 2006 the Object Management Group's ( OMG ) SOA Special Interest Group adopted the following definition for SOA Service Oriented Architecture is an architectural style for a Community of providers and consumers of services to achieve mutual value, that Allows participants in the communities to work together with minimal co-dependence or technology dependence Specifies the contracts to which organizations, people and technologies must adhere in order to participate in the community Provides for business value and business processes to be realized by the community Allows for a variety of technologies to be used to facilitate interactions within the community

5. Service Oriented Architecture In March 2006 the OASIS group SOA Reference Model released its first public review draft. This defines the basic principles of SOA that apply at all levels of a service architecture, from business vision through to technical and infrastructure implementation Service Oriented Architecture; a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations

6. Principles of SOA Services share a formal contract Services are loosely coupled Services abstract underlying logic Services are composable Services are reusable Services are autonomous Services are stateless Services are discoverable

7. SOA Components:

8. Why Services? SOA = an architectural principle for structuring systems that SOA emphasizes the de-coupling of system components New services are created from existing ones in a synergistic fashion Strong service definitions are critical Services can be subsequently re-composed in response to changing business requirements

9. What Are Services? A function accessed using XML message exchange Message exchanges have well known exchange patterns Services are self-describing, usingmetadata (WSDL)

10. What Does a Service Do? Transform data Route messages Query databases Orchestrate conversations Apply business logic Apply business policy Handle business exceptions Solicit approvals …

11. How Is a Service Implemented? • XSLT • Enterprise JavaBeans™ (EJB™) technology • BPEL • SQL • XQuery • Routing table • Business rules • EDI transform • …

12. Supply Chain Application

13. SOA Infrastructure

14. SOAP, WSDL, UDDI WSDL is used to describe the service; UDDI, to register and look up the services; SOAP, as a transport layer to send messages between service consumer and service provider. WS-I Basic Profile Service providers can use the Basic Profile test suites to test a service's interoperability across different platforms and technologies. J2EE and .Net Provide the framework for developers to naturally participate in the SOA, but also, by their inherent nature, bring a mature and proven infrastructure for scalability, reliability, availability, and performance to the SOA world.

15. Quality of services:Should be able to provide Quality of service comprising such as security, reliability, and transactions. Security:The Web Services Security specification addresses message security. This specification focuses on credential exchange, message integrity, and message confidentiality. Reliability:Delivery of messages with characteristics like once-and-only-once delivery, at-most-once delivery, duplicate message elimination, guaranteed message delivery, and acknowledgment become important in mission-critical systems using service architecture. Policy: A policy may consist of multiple assertions.policies are to be communicated between service consumers and service providers. Orchestration services can be used to integrate silos of data, applications, and components. Integrating applications means that the process requirements, such as asynchronous communication, parallel processing, data transformation, and compensation, must be standardized. BPEL4WS or WSBPEL (Web Services Business Process Execution Language) addresses service orchestration, where business processes are created using a set of discrete services. Management As the number of services and business processes exposed as services grow in the enterprise, a management infrastructure that lets the system administrators manage the services running in a heterogeneous environment becomes important.

16. SOA==Web Services?? "Web services are about technology specifications, whereas SOA is a software design principle. Web services' WSDL is an SOA-suitable interface definition standard: this is where Web services and SOA fundamentally connect. Fundamentally, SOA is an architectural pattern, while Web services are services implemented using a set of standards; Web services is one of the ways you can implement SOA. The benefit of implementing SOA with Web services is that you achieve a platform-neutral approach to accessing services and better interoperability as more and more vendors support more and more Web services specifications.

17. Benefits of SOA Flexible (Agile) IT Adaptable to changing business needs Faster time to market Reuse existing code, minimize new development Business and process-driven New business opportunities Greater ROI Leverage existing IT asset

18. Composite Applications—Summary A composite application is a collection of existing and independently developed applications and new business logic, orchestrated together into a brand new solution of a business problem that none alone can solve Such an application looks to the user like a regular new interactive application, yet in reality it may be only 10 percent new and 90 percent an assembly of pre-existing components or data; The “glue” that brings a composite application together is integration technology

19. Composite Applications Composite applications are... applications ! Comprised of heterogeneous parts Some existing parts Some new parts Composite applications != SOA Composite applications employ SOA principles Features exposed as Web services Standards-based interaction between services Described by standards-based artifacts Are themselves composable

20. How it fits? Service Oriented Architecture (SOA) :. The bottom-up view of the SOA sees different business applications exposing their functionalities through web services. Thus we can now access different functionalities of different legacy and new developed applications in a standard way (through web services). Developing the web services and exposing the functionalities is not sufficient. need a way to compose these functionalities in the right order – a way to define business processes which will make use of the exposed functionalities. should be flexible

21. What is BPEL XML-based language used to specify business processes based on Web Services BPEL processes describe Long running, stateful, transactional, conversations between two or more partner web services BPEL is key to implementing SOA Big Rules Conversational Mostly Async XML Document-based Orchestrated

22. What is BPEL Business Process Execution Language A BPEL Abstract Process represents a set of publicly observable behaviors in a standardized fashion. An Abstract Process includes information such as when to wait for messages, when to send messages, when to compensate for failed transactions, etc. BPEL is an Orchestration language, not a choreography language (see Web Service Choreography). BPEL's focus on modern business processes, plus the histories of WSFL and XLANG, led BPEL to adopt web services as its external communication mechanism. Thus BPEL's messaging facilities depend on the use of the Web Services Description Language (WSDL) 1.1 to describe outgoing and incoming messages.

23. BPEL supports: A property-based message correlation mechanism XML and WSDL typed variables An extensible language plug-in model to allow writing expressions and queries in multiple languages: BPEL supports Xpath 1.0 by default Structured-programming constructs including if-then-elseif-else, while, sequence (to enable executing commands in order) and flow (to enable executing commands in parallel) A scoping system to allow the encapsulation of logic with local variables , fault- handlers , compensation-handlers and event-handlers Serialized scopes to control concurrent access to variables

24. BPEL allows composition of web services and is thus the top-down approach to SOA – the process oriented approach to SOA.

25. WS-BPEL Works With WSDL Web Services Business Process Execution Language Web services are described in WSDL Operations are message exchanges Each operation represents an individual unit of action We need a way to orchestrate these operations with multiple web services in the right order to perform a Business process Sequencing, conditional behavior etc. BPEL provides standard-based orchestration of these operations

26. Role of BPEL & relationship with Java Allows us to define Abstract and Executable processes Is supported by the majority of companies Software exists (from several vendors) on which such processes can be executed (BPEL servers) and developed (BPEL designers).

27. BPEL Is a Web Service Sequencing Language Process defines “conversation” flow chart Conversation consists of only WSDL-described message exchanges BPEL provides and consumes WSDL defined services Process instance is a particular conversation following the chart Execution systems can support multiple concurrent conversations

28. BPEL “Fixes” WSDL WSDL: unordered set of operations Operations are message exchanges Need rules for ordering Support for sequencing Support for concurrency Choreography with external entities

29. Orchestration vs. Choreography Orchestration An executable business process describing a flow from the perspective and under control of a single endpoint (commonly: Workflow) BPEL handles Orchestration Choreography (WSDL) The observable public exchange of messages, rules of interaction and agreements between two or more business process endpoints WSDL handles Choreography

30. BPEL: Relationship to Partners

31. Business Process Needs To... Co-ordinate asynchronous communication between services Correlate message exchanges between parties Implement parallel processing of activities Implement compensation logic(Undo operations) Manipulate/transform data between partner interactions Support for long running business transactions and activities Handle exception handling Need for universal data model for message exchange

32. BPEL Activities Basic Activities • <invoke> • <receive> • <reply> • <assign> • <throw> • <wait> • <empty> Structured Activities • <sequence> • <while> • <pick> • <flow> • <scope> • <compensate> • <switch> • <link>

33. BPEL: Basic Activities <invoke> To invoke a one-way or request/response operation on a portType offered by a partner <receive> To do a blocking wait for a matching message to arrive Can be the instantiator of the business process <reply> To send a message in reply to a message that was received through a <receive> The combination of a <receive> and a <reply> forms a request-response operation on the WSDL portType for the process

34. BPEL: Basic Activities <assign> Can be used to update the values of variables with new data <throw> Generates a fault from inside the business process <wait> Allows you to wait for a given time period or until a certain time has passed <empty> Allows you to insert a &quot;no-op&quot; instruction into a business process This is useful for synchronization of concurrent activities, for instance

35. BPEL: Structured Activities • <sequence> Perform activities in sequential order • <flow> Perform activities in parallel • <switch> Conditional choice of activities • <scope> Enclose multiple activities in a single scope

36. Example Business Process

37. BPEL: Relationship to Partners

38. Why Do You Care on BPEL? • In SOA-enabled environment, you are more likely to build an application by orchestration various services via BPEL • You will probably use BPEL design tool to create a BPEL document • The BPEL document is then executed by BPEL engine

39. Basic terminology used in BPEL Partners are the external users or services that interact with the process. Activities are the individual business tasks within the process that compose the larger business goal. Elements supplement activities, and assist them in accomplishing their tasks. They are nested within the activities with which they interact. Variables store the messages that are passed between these activities and partners .

40. Basic terminology used in BPEL Staff assignment sends a task out to a human for interaction. Compensation returns the business process to a balanced state if something happens during execution to upset that balance. Fault handling identifies possible problems ahead of time, and tells the process how to deal with them. Correlation sets identify tokens that allow two participants in a conversation to identify each other in subsequent communications.

42. How to go Ahead Tooling Requirements IDE – build your Web services WSDL authoring – model your interfaces Schema authoring – model your messages Process modeling – model your orchestration Packaging and deployment Debugging Monitoring Analyzing

43. Summary SOA enables flexible and agile enterprise application architecture BPEL is an important language for the process-oriented approach to SOA BPEL is a service orchestration language for creating stateful composite applications Services can be re-implemented using other technologies as long as service interface is preserved without changing consumers

44. Questions?

45. References: http://publib.boulder.ibm.com/bpcsamp/ http://www.ibm.com/developerworks/websphere/library/techarticles/0608_kagan/0608_kagan.html http://www.research.ibm.com/journal/sj/432/kloppmann.pdf http://docs.jboss.com/jbpm/v3/demos/movies/jbpm-overview.swf http:// www.theserverside.com/tt/articles/article.tss?l = BPELJava