Transcript Meta, Meta, Meta a proposal to WS-CHOR

Elements of
Web Services Choreography
Jean-Jacques Dubray
WS-CHOR f2f 3/13/03
Redwood Shores, CA
Bio
• Got interested by B2B, BPM and XML in 1998 at
NEC System Laboratories
• 1999 - eXcelon to develop a B2B Integration
Server based on a Business Process Engine
• 2001 - Eigner (PLM vendor) to design next
generation architecture
• Contributor to OAG (IF), ebXML (BPSS), and
BPML (ebXML binding)
• Represent no particular interest, just want to
learn, share ideas and experiences
Outline
•
•
•
•
•
Introduction
Paradigm Shifts
WS-Choreography and SOA
Collaboration, Choreography and Orchestration
Elements of WS-Choreography
–
–
–
–
–
–
Message Exchange Patterns
Choreography protocol
Transactional behavior
Message content
Control flow
Technical Binding
• Conclusions
Introduction
• XML, Web Service and BPM will
revolutionize the way we built applications
• Applications as we know it will disappear
– 1990-1999 looking for a better way to build
applications (CORBA/DCOM, J2EE, but also
EDOC, BOCA, …)
– 2000-2010 found the better way
• Towards a new “component model”: SOA
Paradigm Shifts
• Can the web do for applications what it had
done for humans?
– From a given application access any service (data,
transaction, computation) regardless of its location
• Can the web give us hints on a better application
model?
– Loosely coupled, plug & play, Message based
– REST?
• Meta, Meta, Meta
– Current programming languages show lots of
limitations when developing business applications
(e.g Java/J2EE, C#/.NET)
WS-Choreography is at the
convergence of
•
•
•
•
B2B
EAI
Distributed computing model
Applications models (s.a. J2ee and .NET)
WS-Choreography and SOA
Request
Web Services
Provider
Internet
Web Services
Provider
Response
This is the WRONG
Picture for SOA
J2EE™
AppServer
SOAP
Messages
.NET
What is a Service?
Load Payable
Accounts
Receivable
Sync Party
Lo
ad
Re
ce
iv
ab
le
Update SalesOrder
Order
Management
Sync ItemMaster
Get PickList
Receiving
Show PickList
Update PickList
OAGIS 8.0 Scenario 41
Inventory
Human
Resources
Sync
Employee
Work
Schedule
Accounts
Payable
Sync
Personnel
This is
A
Service
Sync SalesOrder
Customer
Service
Add SalesOrder
r
te
t
as
M
en
Post JournalEntry
Create
m
m
e nt
Ite
v
ProductionOrder
o
e
nc
Sync ChartOfAccounts
yM vem
r
Sy
o o
t
n M
ve ory
n
t
I
Sync ExchangeRate
ue ven
General
s
Production
Is eIn
Ledger
v
ei
c
Re
SOA’s Foundation is “Peer-to-Peer”
Sync ItemMaster
Sync ProductionOrder
Manufacturing
Capacity Analysis
Sync Routing
Sync BillOfMaterial
No Application
Or Corporation
Boundaries
Sync ItemMaster
Sync ProductionOrder
ERP
Sync Item
OAGIS 8.x Scenario 50
Sync Prodorder
Show DispatchList
Sync Routing
Get DispatchList
Sync BOM
Sync DispatchList
Update WIPConfirm
Confirm InventoryIssue
Manufacturing/
Production
Planning
Manufacturing
Execution (MES)
Update WIPConfirm
Sync BillOfMaterial
Confirm InventoryIssue
Sync Routing
Intra / Inter Company
Message Exchange
• Message exchange between corporation
boundaries is sufficiently different to justify
special treatments:
– State alignment (no shared “memory”)
– Legal aspects (non-repudiation)
SOA as an Application Model
(MVC Revisited)
Thin
Fat
Other
Firewall
Task Engine
Process & Data
Process Engine
Federation
ERP
Model
PLM1
Model
PLM2
Model
Key Takeaway
• Ws-chor is a major enabler of SOA
• Ws-chor foundation is peer-to-peer
Collaboration, Executable Business
Processes and Services
Start
Buyer
Supplier
ROLE
Manager
Order Entry
(Self)
PO
AckPO
PO
PO
BTA1
Wit1
B2B
Collaboration
Executable
Business
Process
PO
AckPO
Sales
order
OpA1
OpA2
Message
Exchange
Billing
Collaboration And Executable
Business Process
• Both are state machine
• A collaboration has no engine associated
with it (nothing is in the middle)
– It is merely the execution of activities of the
executable business processes in each party
that advances the state of the collaboration
Collaboration And Executable
Business Processes
• The Process Engine is responsible for:
– Mapping (many-to-one-one-to-many)
– Decoupling services via message routing
• sequence, flow, switch, while
– Monitoring (coupled) interaction between services to
advance the state of the process instance
• A Collaboration “service” is responsible for
ensuring that an incoming/outgoing message is
expected at this point in time
– No mapping, no routing, no “advancement”
(Business) Components
a.k.a. Services
Start
Buyer
Supplier
Order Entry
Manager
Billing
(Self)
PO
AckPO
BTA1
Map
Route
Review
PO
Task
PO
PO
Wit1
PO
AckPO
OpA1
Process
PO
Sales
order
OpA2
Orchestration
Process
Sales
Order
Choreography and Orchestration
• Business component can exhibit a long running
behavior and looking from the perspective of
such component, the flow of messages between
itself and other components can also be
expressed using a meta language.
– This is orchestration
• The confusion is that Components are typically
very coarse and can directly be exposed to
partners. The long-running behavior might also
be complete.
Choreography and Orchestration
Eigner PLM
Sync
BOM
BPM
SAP
Transform
Route
[for each]
Sync Item
exists?
Sync BOM
no
yes
Create BOM
Update BOM
[any error]
Create History
Failure
Success
Key Takeaway
• ws-chor applies to Collaboration and
executable business processes
• Orchestration might be different
Elements of WS-Choreography
•
•
•
•
What do we choreograph, how?
What is a message content?
Choreography between who/what?
Choreography technical binding
Choreograph Messages or
Message Exchange Patterns?
One way
Notification
Solicit
Response
Request
Response
Message Exchange Pattern
Choreography
This is far easier
than trying to
choreograph
Notifications and
One ways
PO
AckPO
Buyer
Change
PO
Change
PO
AckPO
AckPO
Invoice
Payment
Seller
Choreography Protocol
• There is a need, specially in B2B scenario to
exchange signals in addition to messages
• Signals feature typically a fixed format and carry
special meaning
– Message structure and content is valid
– Message was successfully processed by the
receiving application
• Signals are typically part of the Message
Exchange Pattern
• Exception associated to signal content:
business, technical exception
Choreograph Exceptions
Buyer
Supplier
Order Entry
Billing
(Self)
[TechnicalFailure]
PO
BTA1
PO
[BusinessFailure]
OpA1
Invoice
[AnyFailure]
OpA2
Invoice
[AnyFailure]
BTA2
[Success]
Success
Failure
Transactional Behavior
• WSCI, BPEL4WS features transaction
specifications as part of the choreography
– BPEL4WS scopes
• BPSS doesn’t, all compensating
transactions must be explicit
• Transactional behavior sounds reasonable
to be within the scope of WS-Chor
• First step is expressing meaningful
exceptions: timeout, technical, business,…
Message Content
• Any number of XML or Binary documents
• XML document type or content might be
used to specify condition expressions in
the control flow
Control Flow Specification
•
•
•
•
•
Prof. van der Aalst patterns
BPEL4WS
WSCI
BPSS
Receive / Reply issue
– BPML spawns a new sub process altogether
– BPSS has an onInitiation condition
– BPEL correlates a reply with a receive. The reply can
be located anywhere in the choreography
• Should consolidate to one control flow, no need
for half-baked overlapping specification there.
Control Flow Specification
Start
Buyer
Supplier
Order Entry
Manager
Billing
(Self)
PO
AckPO
BTA1
PO
PO
Collaboration Control Flow
Wit1
Semantics
are different from
the semantics of an
executable business process
PO
AckPO
Sales
order
OpA1
OpA2
[BusinessFailure]
Failure
[Success]
Success
Technical Binding
• Two approaches
– Start with WSDL specification and express a
choreography of these services
– I suggest an alternative approach which I
think will work better
• Specify the choreography in terms of roles and
usage of message exchange pattern types
• Then generate the corresponding WSDL
automatically
Beyond Choreography
• UMM
• Business Collaboration Patterns &
Monitored Commitments, e.g. from COOL:
–
–
–
–
Negotiation: Offer and Counter-offer
Offer and Acceptance
Commitment and Fulfillment
Deliver the goods and Pay for them
• REA
– http://homepage.interaccess.com/~linkage/REA4SCM.htm
• Business Entities
– http://www.collaborativedomain.com/standards/
Conclusion
• SOA appears as a valid application model
moving forward
– No more application or corporation boundary
– Process and Data federation
– Decoupled services?
• SOA is at the convergence of traditional
application models, EAI and B2B
• Service Choreography is essential to SOA
Conclusion
• Service Choreography MUST be peer-to-peer
• Scope is everything that is pure message
exchange: Collaboration and EBP
• Message Exchange Patterns are the units of
what is being choreographed
• B2B is different than EAI / Business Process
Execution
• More metadata is good by beware of metadata
hell and poorly articulated layers