ibm software group/ cio eodt ® ibm swg industry solutions & cio eodt a proposal for a web...

IBM Software Group/ CIO EODT

®

IBM SWG Industry Solutions & CIO EODT

A Proposal for a Web Services-Based Approach to Vertical Industry Standards



Vertical XML Industry Standards… today’s background

Multiple industry standards use the same or similar messaging infrastructures

Example: several vertical standards use or recommend the RosettaNet Implementation Framework (RNIF) as their messaging infrastructure - CIDX, PIDX, OAGi and RosettaNet

The market is searching for less expensive and more functional interconnectivity infrastructures to increase the ROI of supply chain initiatives

Web Services now offer a robust alternative approach Replacing RNIF with Web Services would provide Web

Services with several built in business communities for transition

RosettaNet itself wishes to move away from RNIF as soon as other messaging infrastructures are available (WS, AS2, …)



RosettaNet and Web Services will both benefitRosettaNet Users Gain…

Ability to link existing RosettaNet PIPs to create more powerful automated transactions. For example: “Query these n suppliers and buy this item on the

best combination of spec, price and availability” “Check this buyer’s credit in real time as part of his

purchase request” New combinations of PIPs and standardized “ancillary”

services? Check validity of requested product configurations

(and suggest amendments for faulty configurations) Identify services available to support a given

hardware or software product (and alternatives) Verify lines entered in an order Automatically check validity of serial numbers View service contract/coverage for a given serial #

Scalability - reduced boarding and implementation costsIncreased take-up of RosettaNet – ecosystem benefits

Web Services Gains…Critical mass of RN users

in Technology, Logistics and Telecoms Sectors who want to see the cost and functional advantages of web services … and of others

standards users – CIDX, PIDX, OAG – who use the same existing RNIF transport as RosettaNet

Business-level standardization of deployment and use of web services



What has to be done (1/2)?

We have to replace the RosettaNet Implementation Framework (RNIF) with a web services equivalent

This will be the role of the Multiple Messaging Services (MMS) program

Public Process (Conversation)

Business Messages – Partner Interface Processes (PIPs)

Dialogs: sequenced, performance-delimited exchanges of messages and data that define business processes

RosettaNet Implementation Framework (RNIF)Exchange protocols that allow PIPs to operate

HTTPS/SMTP

Message Validation

Enterprise Business Processes

Dictionary

Transport Protocol

Message Protocol

Private Process

Validate Message

“Correctness”







HTTPS/SMTP

Message Validation


Dictionary

Transport Protocol

Message Protocol

Private Process

Validate Message

“Correctness”





HTTPS/SMTP

Message Validation


Dictionary

Transport Protocol

Message Protocol

Private Process

Validate Message

“Correctness”







HTTPS/SMTP

Message Validation


Dictionary

Transport Protocol

Message Protocol

Private Process

Validate Message

“Correctness”



What has to be done (2/2)? Existing RosettaNet PIPs will be re-

factored into xml schema (as is being undertaken now)

We then have to: Recreate the choreography

and orchestration of each PIP, using Business Process Execution Language (BPEL)

Define and reference the separate web services that execute the PIP, using Web Services Description Language (WSDL)

This could be the subject of future milestone programs

In addition the Message Control and Choreography (MCC) program will define how PIPs can be linked





HTTPS/SMTP

Message Validation


Dictionary

Transport Protocol

Message Protocol

Private Process

Validate Message

“Correctness”







HTTPS/SMTP

Message Validation


Dictionary

Transport Protocol

Message Protocol

Private Process

Validate Message

“Correctness”





HTTPS/SMTP

Message Validation


Dictionary

Transport Protocol

Message Protocol

Private Process

Validate Message

“Correctness”







HTTPS/SMTP

Message Validation


Dictionary

Transport Protocol

Message Protocol

Private Process

Validate Message

“Correctness”



How is IBM supporting the creation of “RosettaNet over Web Services”?

White paper, setting out how to replace existing RNIF capabilities with web services

Whitepaper will be made available shortly

Participation in RosettaNet Multiple Messaging Services (MMS) program

We will participate in the Web Services workgroup

White Paper will provide a key input

We will be joining Intel, Cisco, HP, DHL, E2Open, Formfill, Fujitsu, Motorola, Sterling Commerce, Tyco and ePSA

As MMS completes: Propose the re-start of Message Control and Choreography (MCC)

program to identify ways to leverage web services to create more functional PIPs

Identify priorities for PIPs to recreate with BPEL

“ IT IS CLEAR THAT ROSETTANET OVER WEB SERVICES WILL BE A DISRUPTIVE CAPABILITY FOR B2B AND WILL SPRINGBOARD

ADOPTION AND ACCELERATE BUSINESS VALUE. CISCO HAS BEEN AND CONTINUES TO BE AN ACTIVE ADVOCATE OF WEB

SERVICES ENABLEMENT.”

7

ANDY STARR, Senior Director Enterprise B2B



“Intel has committed to validate WS-I through the MMS program in Q1 ’05. WS-I will be an important foundational component as we move from pilot implementations of the RosettaNet Automated Enablement (RAE) to widespread deployments next year. Without the MMS program delivering a WS-I alternative to RNIF 2.0, we could not achieve Intel’s planned proliferation of RosettaNet through the RAE program”

John Cartwright, Program Director, RAE Program, Intel Corporation



High Level Overview of WS Approach (1/2)Modernization and Repackaging or Adaptation of the

Business Message

Conversion of non-schemas definitions from XML DTD to XML Schema

• Business Message header documents

• Business signal documents defined in RNIF

• Business action documents

Create a set of files for each role in the process (ie, buyer and seller)

• WSDL definitions

• Abstract BPEL processes

• WS-Policy requirements



High Level Overview of WS Approach (2/2)We propose the following Web Services runtime stack for

message exchange and handling

WS-BPEL sub-system WS-Security sub-system (inc signature/validation and

encryption/decryption) WS-ReliableMessaging sub-system Non-repudiation sub-system (recommendation for WS-Security) RosettaNet unique message validation sub-system WS-Addressing sub-system. WS-Policy (including WS-SecurityPolicy and WS-

PolicyAttachment) Implemented via sub-systems above



Web Services QoS and Policy Files

Covering all the security requirements and some of the timing requirements specified in the PIP requires:

QoS parameters to be defined externally using the pluggable WS-Policy framework and attached to different parts of a WSDL definition using the WS-PolicyAttachment specification

WS-Policy assertions related to WS-Security to be defined in the WS-SecurityPolicy specification

WS-Policy assertions related to WS-ReliableMessaging to be defined within the WS-ReliableMessaging specification itself



<process>

<flow>

<invoke>Seller

sendPO

<invoke>Seller

sendPO

<receive>Seller

confirm

<receive>Seller

confirm

<receive>privatePrcvPO

<receive>privatePrcvPO <process>

<flow>

<invoke>Seller

sendPO

<invoke>buyer

confirm

Business Messagesin BPEL

Executable Processes -

Private View(Derived from abstract)

<process><flow>

<invoke>Seller

sendPO

<invoke>Seller

sendPO

<receive>Seller

confirm

<receive>Seller

confirm



<process>

<flow>

<invoke>Seller

sendPO

<invoke>buyer

confirm


<receive> buyerrcvPO

<invoke>privateS

sendPO

privatePrcvPO

<receive>privateSconfirm

Buyer’sBackend Systems

Seller’s Backend Systems

<invoke>privatePconfirm

Abstract Processes -Standards View

Buyer Seller

WS

-Sec

urity

WS

-Rel

iabl

eMes

sagi

ngP

olic

y A

tta

chm

ents

SO

AP

w/

WS

-Sec

urity

WS

-Rel

iabl

eMes

sagi

ngH

eade

rs


<receive>buyerrcvPO



In addition to the business message exchanged, the following are included in the full abstract BPEL processes:

Timers

Business level acknowledgements

Fault handling and out of band failure notification (example: PIP 0A1)

Content and business specific validation

Managed by the rest of WS stack: Security

Retries

Schema validation

Business Messages in BPEL



<process>

<process>

<receive>Provider

PO

<receive> buyer

PO<flow>

Seller

<flow>

EventHandler:

sellerFailure:throw fault

EventHandler:

buyerFailure:throw fault

<invoke>Seller

sendPO

<invoke>Seller

confAck

Alarm Handler:24 hours<sequence> send buyerFailure invoke 0A1 throw fault</sequence>

Buyer

FaultHandler:x

<sequence> send buyerFailure

throw fault</sequence>

FaultHandler:y

invoke 0A1

<assign>confirm=opaque

<throw>Fault x

POValid POValid

<throw>Fault x

confValid confValid

<receive>Seller

POAck

Alarm Handler8 Hours<sequence> Send buyerFailure Throw fault y </sequence>

<receive>Seller

confirm

<receive>Seller

confirm



<receive>buyer

confAck

Alarm Handler8 Hours<sequence> Send buyerFailure Throw fault y </sequence>

<invoke>buyer

confirm

<assign>confValid=

opaque

<assign>confAck=opaque

<invoke>Seller

sendPO

<invoke>Seller

sendPO

<assign>POValid=opaque

<assign>POAck=opaque

<invoke>buyer

POAck

Full Abstract BPEL Processes - Typical ExampleFaultHandler:

yinvoke 0A1



Our proposals and MMS

Scope of MMS program is a subset of the scope of this proposal that is specific to the aspect of finding alternates for RNIF

The recommendations in this proposal for supporting reliable messaging and RosettaNet specified QoS criteria (re-tries, timeouts, non-repudiation, encryption etc.) will help define the Web Services implementation for MMS

Will be built on the Web Services standards that include WS-Security, WS-ReliableMessaging, WS-Policy, WS-Addressing etc.

Work will be needed to define the mapping between the elements of this proposal and the Abstract Messaging Definition (AMD)



What are we proposing? RosettaNet Implementation Framework (RNIF)Policies

• Security (authentication, non-repudiation S/MIME, x509 v1/3)

• Compliance• Trading Partner Agreements

Specifications• Network protocols• Message structure• Message handling• Exception handling

Architecture• Meta-model: A generic message• Network component reference model

Initially, seven Web Service specifications will be used:

• XML Schema – Message Part Definitions• WSDL – Interface & Message Definitions• WS-BPEL – Process Choreography• WS-Security – All Security Functions• WS-Reliable Messaging – Reliable Message

Delivery• WS-Policy

• WS-SecurityPolicy - Security QOS• WS-PolicyAttachment – Other QOS

• WS-Addressing – All Service Addressing



Next Steps (1/2)

WS Standards stack: Add functionality to existing standards

• Non-repudiation (recommendation made to WS-I Security Group on non-repudiation of receipt; further work needed on non-repudiation of origin and content)

• RN-specific processing

Validate assumptions:• WS-Security sub-system must cover attachments

• WS-ReliableMessaging will require a policy assertion for max attempts

Areas that were left for future investigation:• XML Namespace usage (currently an issue for other vertical

standards)



Next Steps (2/2) MMS (Web Services)

Create WS-enabled transport mechanism and gain RosettaNet ratification

MCC Build on existing demonstrator to define how to link multiple

PIPs in more powerful transactions Creation of “ancillary” services/PIPs?

Application to PIPs Define priorities for enablement of existing PIPs Undertake enablement


®


Backup Material



RosettaNet Implementation Framework

Policies• Security (authentication, non-

repudiation S/MIME, x509v1/3)• Compliance• Trading Partner Agreements

Specifications• Network protocols• Message structure• Message handling• Exception handling

Architecture• Meta-model: A generic message• Network component reference model

RN Implementation Framework (RNIF)

(packaging, transfer, routing, security)

The RNIF is independent of themessages that it transports

RNIF is the framework on which the business content/business messages rests, “implementing” the vertical standards in system to system terms



Multi-Party Multi-PIP Example over RNIF

3A2PIP

3A4PIP

3A2PIP

3A4PIP

Buyer Seller/Supplier 1

3A2PIP

RN-Gateway

RNIF 2.0 over

HTTPSRN Gateway

SupplierBackend

Application

SupplierBackend

Application

EnterpriseEAI

PrivateProcurementApplication

RN Gateway

Me

ssag

e V

alid

atio

n

RN

IF In

frastru

cture

Me

ssag

e V

alid

atio

n

RN

IF In

frastru

cture

Me

ssag

e V

alid

atio

n

RN

IF In

frastru

cture

3A2 – Request for Quote3A4 – Submit Order

Seller/Supplier 2

PublicProcess

Note: Internal process engine must initiate each individual PIP process for each partner and understand total process

A “Purchase via Lowest Price” Scenario



Seller 1 InternalBPEL

Seller 2 InternalBPEL

Multiparty Process Flow Using WSSeller 1Buyer Seller 2

RF

Q RF

Q

Procurement WSDLs

RF

Q

1., 2. Generate RFQ

RF

Q

3., 4. Generate Std RFQ

5., 6. Receive RFQ Response

7., 8. Return prices

PO

15. Procurement Process Done

PO

11. Generate PO 12. Generate PO Request

13. Receive PO Response

14. Return Confirmation

10. Trigger PO Process

WSDLs WSDLs

9. Pick Winner

Buyer InternalBPEL

ExternalBPEL

ibm software group/ cio eodt ® ibm swg industry solutions & cio eodt a proposal for a web...

Documents