1. Introduction to SOAP-RP and DIME
11/28/2018 2:20 PM
Introduction to SOAP-RP and DIME
Henrik Frystyk Nielsen Architect Microsoft Corporation
Jul

2. Agenda Introduction to SOAP-RP Introduction to DIME
Adds routing functionality to SOAP
Introduction to DIME
Deals with non-XML data
Helps avoiding parsing overhead
Jul

3. Web Services Communications Model
Decentralized
No central naming or protocol authority
Semi-structured messages
Parties might have only partial understanding of messages
Heterogeneous
Open-ended set of platforms and network environments
Support for Evolution
Jul

4. SOAP goals Based on semi-structured data
Support orthogonal extensions
Composability through extensibility model
Dynamic composition of data
Dynamic composition of processes
Simplicity and extensibility at the core
Features of richer protocols introduced using the SOAP extensibility mechanisms
Jul

5. Dynamic Composition of Data
The SOAP:mustUnderstand attribute
Mark which parts of the message the receiver must understand in order to process the message correctly.
Body parts are by definition mandatory
Header parts are by default optional
Jul

6. Soap:mustUnderstand
<S:Envelope xmlns:env="
<S:Header>
<m:alertcontrol xmlns:c=" S:mustUnderstand="1">
<c:priority>1</c:priority>
<c:expires> T14:00:00-05:00</c:expires>
</c:alertcontrol>
</S:Header>
<S:Body>
<m:alert xmlns:m="
<m:msg>Pick up Mary at school at 2pm</m:msg>
</m:alert>
</S:Body>
</S:Envelope>
Jul

7. Dynamic Composition of Processes
The SOAP:actor attribute
A message may have several parts, each appropriate for a different party along its route.
Start
web://bar
web://toto
web://foo
Jul

8. SOAP:actor
<S:Envelope xmlns:env="
<S:Header>
<m:alertcontrol xmlns:c=" S:actor="
<c:priority>1</c:priority>
<c:expires> T14:00:00-05:00</c:expires>
</c:alertcontrol>
</S:Header>
<S:Body>
<m:alert xmlns:m="
<m:msg>Pick up Mary at school at 2pm</m:msg>
</m:alert>
</S:Body>
</S:Envelope>
Jul

9. Web Services Roadmap Data Exchange Description Discovery DIME SOAP-RP
Existing
In Proc
Future
Reliability
Caching
Process Orchestration
Routing
Attachments
Service Description (WSDL)
Directory (UDDI)
Envelope & Extensibility (SOAP)
Structure (XML Schemas)
Inspection
Syntax (XML)
Data Exchange
Description
Discovery
Jul

10. SOAP Routing Protocol
Represents our view on how one can do routing in SOAP
Publicly available on gotdotnet
Go to
Requirements described in paper for W3C Web Services Workshop
Jul

11. SOAP-RP – Functional Routing
SOAP does not describe a message path
SOAP describes composition of processes
Not how to send a message from A to C via B
SOAP-RP adds a SOAP message path
How to send a message from A to C via B
Defined as a SOAP header entry
Entirely encapsulated within SOAP message
Decouples routing from underlying protocol
Supports TCP, UDP, HTTP, SMTP, etc.
Jul

12. SOAP-RP Services Forward path Reverse Path Message Correlation
Message path from A via B to C
Dynamic or statically generated
Reverse Path
Message path from C via B to A
Dynamically generated
Message Correlation
Indicates how messages are related
Routing Fault
Defines what happens if endpoints not found
Jul

13. SOAP-RP is a SOAP bubble
Deliberately does not provide
Guaranteed Messaging, Caching, Pub/Sub, Notification, Privacy, Signing, Encryption, etc.
Intent is that SOAP-RP Composes with other SOAP bubbles that provides such functionality
Jul

14. SOAP-RP Elements <to> is the destination of the message
<from> is like "from" in s
<fwd> specifies the forward path
<rev> specifies the reverse path
<action> indicates intent of the message
<id> is a message ID
<relatesTo> links to message IDs
Jul

15. SOAP-RP Forwarding mailto:mom@bar.com Pick up Mary at School at 2pm
soap://sink.foo.com
Jul

16. Step 1: From Mom to Sink
<S:Envelope xmlns:S="
<S:Header>
<p:path xmlns:p="
<p:action>
<p:fwd>
<p:via>soap://sink.foo.com</p:via>
</p:fwd>
</p:path>
<c:alertcontrol xmlns:c="
<c:priority>1</c:priority>
<c:expires> T14:00:00-05:00</c:expires>
</c:alertcontrol>
</S:Header>
<S:Body>
<m:alert xmlns:m="
<m:msg>Pick up Mary at school at 2pm</m:msg>
</m:alert>
</S:Body>
</S:Envelope>
Jul

17. Step 2: From Sink to Dad
<S:Envelope xmlns:S="
<S:Header>
<p:path xmlns:p="
<p:action>
<p:fwd>
</p:fwd>
</p:path>
<c:alertcontrol xmlns:c="
<c:priority>1</c:priority>
<c:expires> T14:00:00-05:00</c:expires>
</c:alertcontrol>
</S:Header>
<S:Body>
<m:alert xmlns:m="
<m:msg>Pick up Mary at school at 2pm</m:msg>
</m:alert>
</S:Body>
</S:Envelope>
Jul

18. soap://ipaq.foo.com/dad
SOAP-RP Resolution
Pick up Mary at
School at 2pm
soap://sink.foo.com
soap://ipaq.foo.com/dad
Jul

19. Step 1: From Mom to Sink
<S:Envelope xmlns:S="
<S:Header>
<p:path xmlns:p="
<p:action>
<p:fwd>
<p:via>soap://sink.foo.com</p:via>
</p:fwd>
</p:path>
<c:alertcontrol xmlns:c="
<c:priority>1</c:priority>
<c:expires> T14:00:00-05:00</c:expires>
</c:alertcontrol>
</S:Header>
<S:Body>
<m:alert xmlns:m="
<m:msg>Pick up Mary at school at 2pm</m:msg>
</m:alert>
</S:Body>
</S:Envelope>
Jul

20. Step 2: From Sink to IPaq
<S:Envelope xmlns:S="
<S:Header>
<p:path xmlns:p="
<p:action>
<p:fwd> <p:via>soap://ipaq.foo.com/dad</p:via>
</p:fwd>
</p:path>
<c:alertcontrol xmlns:c="
<c:priority>1</c:priority>
<c:expires> T14:00:00-05:00</c:expires>
</c:alertcontrol>
</S:Header>
<S:Body>
<m:alert xmlns:m="
<m:msg>Pick up Mary at school at 2pm</m:msg>
</m:alert>
</S:Body>
</S:Envelope>
Jul

21. Step 3: From IPaq to Dad
<S:Envelope xmlns:S="
<S:Header>
<p:path xmlns:p="
<p:action>
<p:fwd>
</p:fwd>
</p:path>
<c:alertcontrol xmlns:c="
<c:priority>1</c:priority>
<c:expires> T14:00:00-05:00</c:expires>
</c:alertcontrol>
</S:Header>
<S:Body>
<m:alert xmlns:m="
<m:msg>Pick up Mary at school at 2pm</m:msg>
</m:alert>
</S:Body>
</S:Envelope>
Jul

22. SOAP-RP Reverse Path mailto:mom@bar.com Pick up Mary at School at 2pm
soap://sink.foo.com
Ok, will do
Jul

23. Step 1: From Mom to Sink
<S:Envelope xmlns:S="
<S:Header>
<p:path xmlns:p="
<p:action>
<p:fwd>
<p:via>soap://sink.foo.com</p:via>
</p:fwd> <rev> <p:via>soap:internal.bar.com/mom</p:from>
</rev>
</p:path>
<c:alertcontrol xmlns:c="
</S:Header>
<S:Body> …
</S:Body>
</S:Envelope>
Jul

24. Step 2: From Sink to Dad
<S:Envelope xmlns:S="
<S:Header>
<p:path xmlns:p="
<p:action>
<p:fwd>
</p:fwd> <rev> <p:via>soap://sink.foo.com</p:via>
<p:via>soap:internal.bar.com/mom</p:from>
</rev>
</p:path>
<c:alertcontrol xmlns:c="
</S:Header>
<S:Body> …
</S:Body>
</S:Envelope>
Jul

25. What about Binary data? Not everything is XML
Image data, voice data etc
Even XML is not always XML
Encryption, compression, fragments
Don't always want to embed XML into the SOAP message for robustness reasons
MIME multipart has performance problems
Buffering and parsing overhead
Jul

26. DIME – Direct Internet Message Encapsulation
DIME is a lightweight encapsulation format
Publicly available on gotdotnet
Native support for "multipart"
A DIME message is a collection of records
Support for chunking of records
Records can be chunked for streamed data
Efficient parsing
Size, type, and message id available up front
Jul

27. DIME Message DIME Message is one or more records
Content-type: application/dime
Can be carried in MIME and vice verse
Is fully nestable
One DIME message … … …
Record 1
Record 2
Record 3
Record n
Jul

28. SOAP-RP and DIME SOAP-RP uses DIME for TCP and UDP bindings
DIME addresses two problems in XML
Supports passing arbitrary data
Allows efficient parsing
Jul

29. SOAP-RP Over DIME Examples
Without Attachments
With Attachments
DIME message 1
DIME message 2
DIME
SOAP-RP
DIME
SOAP-RP
One DIME message … …
DIME
SOAP-RP
DIME
GIF
DIME
PNG
Jul

30. DIME Bit Fields MB is the Message Begin flag
ME is the Message End flag
CF indicates a chunked record
TYPE of payload is a URI or content type
TNF indicates the type of the type
ID is a URI identifying the payload
DATA is the record payload
Jul

31. DIME Record
|MB|ME|CF| TNF | ID_LENGTH |
| TYPE_LENGTH |
| DATA_LENGTH |
| |
| TYPE + PADDING /
/ |
| ID + PADDING /
| /
/ DATA + PADDING /
Jul

32. Questions?
Jul