Gain Knowledge From this post

1. SOA & BPEL:
Building a Service With BPEL
and the Java EE Platform

2. Agenda
This session describes how
developers using Java™ Platform,
Enterprise Edition can create
composite applications using BPEL
with current Java EE tools and
application servers that support Java
Business Integration

3. Agenda
 Why Services
 Why Composite Applications
 BPEL in the Mix
 A Java EE Based Composite Application
 Summary

4. 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

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

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

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

8. 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

9. 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

10. 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

11. 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

12. 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

13. Purchase Service

15. Purchase Service Functions

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. BPEL: Relationship to Partners

23. 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

24. BPEL Document Structure

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

26. 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

27. 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 "no-op" instruction into a business process
– This is useful for synchronization of concurrent activities, for
instance

28. 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

29. Example Business Process

30. Sample Activities in BPEL

31. BPEL: Relationship to Partners

32. 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
– Highly likely in JBI enabled platform

33. Example Scenario
The Loan Processing Composite Application

35. WSDL: Schema Types (1)
LoanProcessor.wsdl

36. WSDL: Schema Types (1)
LoanProcessor.wsdl

38. BPEL Header

39. BPEL: Partner Links & Variables

40. BPEL: Partner Links & Variables

41. BPEL: …the Decision

42. BPEL: …the Decision, Reply

43. Loan Processor Service (EJB 3)

44. What Are the Artifacts?

45. Service Consumption (Java APIs)
for XML Web Services (JAX-WS 2.0)

46. Runtime: Java EE Platform
and Java Business Integration
 Java Business Integration serves as messaging
infrastructure
 Java EE web services interact through Java Business
Integration
 Java Business Integration bindings allow remote consumers
and providers
 Add other service technologies as Java Business
Integration components
 Transparent to programmer using Java EE
technology
 Reuse without re-coding

47. Java Business Integration (JSR 208)

49. Web Service Orchestration
 Author, design, deploy and test business processes
with the BPEL Designer
– Supports the BPEL 2.0 constructs
– Adds powerful methods for visual authoring
– Step through debugging support
– Built in testing capability for unit testing
 BPEL Mapper for BPEL variable assignments
– Quickly generate XPath expressions
 Deploy to the built in BPEL engine
– Running as a service engine in the JBI environment within
the provided Sun Java System Application Server

50. Summary
 SOA enables flexible and agile enterprise application
architecture
 Services can be created and used using a variety of
Java EE technologies
 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
 Java Business Integration is the enabling
infrastructure

51. THANKS