410 likes | 571 Views
Processing of structured documents. Part 5. XML for data interchange. Simple Object Access Protocol (SOAP) BizTalk (Microsoft) ebXML (UN/CEFACT & OASIS). Simple Object Access Protocol (SOAP). A lightweight protocol for exchange of information in a decentralized, distributed environment
E N D
XML for data interchange • Simple Object Access Protocol (SOAP) • BizTalk (Microsoft) • ebXML (UN/CEFACT & OASIS)...
Simple Object Access Protocol (SOAP) • A lightweight protocol for exchange of information in a decentralized, distributed environment • XML-based protocol • submitted to W3C in May 2000; latest working drafts Dec 2001 (SOAP 1.2) • IBM, Lotus, Microsoft, DevelopMentor, UserLand Software
SOAP • Soap consists of three parts: • an envelope: defines a framework for describing what is in a message and how to process it • a set of encoding rules for expressing instances of application-defined datatypes • a convention for representing remote procedure calls and responses • SOAP messages may be exhanged using a variety or ”underlying” protocols • usually used together with HTTP (Post)
Example: SOAP request <SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://www.w3.org/2001...” SOAP-ENV:encodingStyle=”http://www.w3.….”> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m=”Some-URI”> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Example: SOAP response <SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://www.w3.org...” SOAP-ENV:encodingStyle=”http://www.w3.….”> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m=”Some-URI”> <Price>34.6</Price> </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
SOAP Message Exchange Model • SOAP messages are fundamentally one-way transmissions between SOAP nodes, from a SOAP sender to a SOAP receiver • SOAP messages are often combined (by applications) to implement patterns such as request/response • ”conversations”
SOAP messages • a SOAP message contains two SOAP specific subelements within the Envelope • Header and Body • contents of these subelements are application defined • SOAP defines (partially) how these elements must be handled
SOAP messages • a header is optional • there may be intermediate SOAP nodes along a message’s path from a sender to an ultimate receiver • the intermediate nodes may provide value-added services using the header information • without understanding the body • the body is the mandatory element within an Envelope • main information is carried in the body
SOAP message exchange • SOAP is a simple messaging framework for transferring information in the form of XML documents between a SOAP sender and receiver • the scenarios typically involve multiple message exhanges • the simplest form: request-response pattern
SOAP message exchange • If the exchanged messages conform to a well-defined signature for a remote call and its return, the exchange is modeled as Remote Procedure Calls (RPCs) • otherwise the message exchanges can be modeled simply as documents exchanged • semantics are at the level of sending and receiving applications
Remote procedure call • SOAP specification defines a uniform representation for RPC invocations and responses • target (the procedure to be called) and the parameters have to be given • RPC is carried as a part of the Body element • modelled as struct which takes the name of the procedure or method • subelements represent the parameters
Remote procedure call • encodingStyle attribute • tells how the contents (e.g. parameters) have been serialized • SOAP specifies particular encoding schemes for various datatypes, but other encoding schemes may be used for application-specific data
Remote procedure call • A transport binding supporting request-response pattern can provide the correlation between a request and a response (e.g. HTTP) • the application designer can also put a correlation ID relating a call and its return in a SOAP header • makes the RPC independent of any underlying transport
Apache SOAP implementation • Apache SOAP is an open-source implementation of the SOAP v1.1 specification in Java • Apache SOAP can be used • as a client library to invoke SOAP services available elsewhere • as a server-side tool to implement SOAP accessible services
Apache SOAP implementation • As a client library it provides • an API for invoking SOAP RPC services and • an API for sending and receiving SOAP messages • as a mechanism to write new RPC accessible services or message accessible services, it expects to be hosted by a servlet container (e.g. Apache Tomcat)
Application-specific content • SOAP is a simple and general framework • the problem remains, how to model the application-specific content? • Applications/systems should interoperate... • (partial) solutions: • semantics general to many application areas (e.g. E-commerce in general) • vertical schemas (e.g. for retail industry)
BizTalk Framework • Version 2.0: Document and Message Specification • Microsoft, 2000 • provides a set of basic mechanisms required for most B2B electronic exchanges • does not prescribe the content or schema of individual business documents • builds upon HTTP, MIME, XML, SOAP
BizTalk concepts • Biztalk Framework Compliant (BFC) server • represented by the set of services providing the message-processing functionality defined in the BizTalk specifications • Application • a line-of -business system where the business data or logic are stored and executed • also includes any additional adapters that may be required to input or output Business Documents (see below) and communicate with a BFC server
BizTalk concepts • Business Document • a well-formed XML document containing business-transaction data (purchase order, invoice, sales forecast…) • BizTalk Document • a SOAP message in which the body of the message contains the Business Documents, and the header contains BizTalk-specific header entries for enhanced message-handling semantics
BizTalk concepts • Schema • describes the content and structure of a class of XML documents, in particular for a class of Business Documents • is used by application developers to create systems that process corresponding Business Documents, or by parsers that validate Business Document’s conformance to the Schema at run time
BizTalk concepts • BizTags • the set of XML tags that are used to specify Business Documents handling (SOAP header entries) • BizTalk message • the unit of wire-level interchange • are used to send BizTalk Documents and any related files • must always contain a primary BizTalk Document that defines the semantics of the Message
Example:document structure <SOAP-ENV:Envelope> <SOAP-ENV:Header> <dlv:delivery SOAP-ENV:mustUnderstand=”true”> <dlv:to> <dlv:address xsi:type=”agr:department”> Book Order Department</dlv> </dlv:to> <dlv:from> <dlv:address xsi:type=”agr:organisation”> Booklovers Anonymous</dlv> </dlv:from></dlv:delivery> … continues
Example: document structure <prop:properties SOAP-ENV:mustUnderstand=”true”> <prop:identity>uuid:74b9…</prop:identity> <prop:sentAt>2000-05-14T03:00:00+08:00 </prop:sentAt> <prop:expiresAt>2000-05-15T04:00:00+08 </prop:expiresAt> <prop:topic> http://electroniccommerce.org/purchase_order/ </prop:topic> </prop:properties> … continues
Example: document structure </SOAP-ENV:Header> <SOAP-ENV:Body> <po:PurchaseOrder> <po:Title>Essential BizTalk</po:Title> </po:PurchaseOrder> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
In the example: • An application-specific Business Document (a book purchase order), carried in the body of a SOAP message • BizTalk-specific <delivery> and <properties> SOAP header entries, constructed using BizTags
BizTags • delivery (mandatory) • properties (mandatory) • manifest (optional) • process (optional)
delivery • Document routing is specified with delivery header entry • contains information about the source and destination of the BizTalk Document • subelements • to: destination business entity (mandatory) • address • from: source business entity (mandatory) • address • reliability: reliable delivery (optional) • sendReceiptTo • receiptRequiredBy
reliability • Optional element that contains the information necessary to perform reliable delivery of the enclosing BizTalk Document • if the <reliability> element is present, the destination business entity is required to send a receipt back to the given URL upon receiving and accepting the document • sendReceiptTo: URL to which a receipt must be sent • receiptRequiredBy: time instant, absolute time by which a receipt must be received
Example: delivery <dlv:delivery SOAP-ENV:mustUnderstand=”true”> <dlv:to><dlv:address xsi:type=”agr:department”> … </dlv:address></dlv:to> <dlv:from> <dlv:address xsi:type=”agr:organisation”> … </dlv:address></dlv:from> <dlv:reliability> <dlv:sendReceiptTo>www.we-love- books.org></dlv:sendReceiptTo> <dlv:receiptRequiredBy> 2000-05-14T08:00:00+08:00</dlv:receiptRequiredBy> </dlv:reliability></dlv:delivery>
properties • Document identity information and other concepts • subelements (all mandatory): • identity: URI; identifies the document for purposes of logging, tracking, error handling... • sentAt: sending timestamp • expiresAt: expiration timestamp • topic: URI that uniquely identifies the overall purpose of the BizTalk Document • interest-based routing • verifying the consistency (BizTalk Document vs. the content)
manifest • Document catalog information • includes references to both the Business Documents carried within the primary BizTalk Document in the BizTalk Message, as well as any additional attachments, such as images of binary data, that may be considered a part of the BizTalk Message • purpose: provide a complete catalogue of the content for consistency checking, and for integrity and verification (e.g. digital signatures)
manifest • Subelements • sequence of <reference> elements • reference (mandatory) • uri: reference that resolves to the resource denoted by the enclosing <reference> element • #id (within the BizTalk Document), CID:content-id-value (MIME attachments), URL (large attachments that are carried separately) • description: free text description of the Business Document or attachment • could be used as a supporting comment, or as a keyword for additional implementation-specific processing
Example: manifest <fst:manifest xmlns:fst=”…”> <fst:reference fst:uri=”#insurance_claim_document_id”> <fst:description>Insurance Claim</fst:description> </fst:reference> <fst:reference fst:uri=”CID:claim.tiff@claiming-it.com”> <fst:description>Facsimile of Signed Claim Document</fst:description> </fst:reference> <fst:reference fst:uri=”CID:car.jpeg@claiming-it.com”> <fst:description>Photo of Damaged Car</fst:description> </fst:reference> </fst:manifest>
process • Process-management information • includes information about the business process that provides the processing context for the BizTalk Document
Example: process <prc:process SOAP-ENV:mustUnderstand=”true”> <prc:type>purchasing:Book_Purchase_Process</prc:type> <prc:instance>purchasing:Book_Purchase_Process#12345 </prc:instance> <prc:handle>port:po_receiver</prc:handle> </prc_process>
process • Subelements: • type: URI; the type of the business process involved, e.g., the process of purchasing a book (mandatory) • pattern of interchange that is agreed upon among two or more business partners • instance: URI; uniquely identifies a specific instance of the business process (mandatory) • e.g. an instance of the process of purchasing a book in which Booklovers Anonymous is in the process of purchasing a copy of Essential BizTalk • e.g. extends the type URI with sequence number • handle: URI; provides further information
ebXML • International initiative established by UN/CEFACT and OASIS • vision: create a single global electronic marketplace where enterprises of any size and in any geographical location can meet and conduct business with each other through the exchange of XML based messages • ebXML: a set of specifications
ebXML Architecture • a way to define business processes and their associated messages and content • a way to register and discover business process sequences with related message exchanges • a way to define company profiles • a way to define trading partner agreements • a uniform message transport layer
Vertical specifications • ontologies, vocabularies, schemas • e.g. Global Commerce Internet Protocol • Internet trading in the consumer good industry • manufacturers (e.g. Coca-Cola, Kodak, Nestle, Philips) and retailers (e.g. Carrefour, Marks & Spencer, WalMart Stores) + trade organisations representing 850000 companies (year 2000) • ebXML for message transportation and routing