Upload
lena
View
60
Download
0
Tags:
Embed Size (px)
DESCRIPTION
SOAP based WS* Standards and MISMO. Agenda. Review standards & technologies relating to SOAP, XML, Web Services, and the WS* standards Roadmap for moving MISMO towards a SOAP based solution Industry’s challenges, advantages, disadvantages of moving to a SOAP based communications framework. - PowerPoint PPT Presentation
Citation preview
SOAP based WS* Standards and MISMO
Agenda Review standards & technologies
relating to SOAP, XML, Web Services, and the WS* standards
Roadmap for moving MISMO towards a SOAP based solution
Industry’s challenges, advantages, disadvantages of moving to a SOAP based communications framework
What is SOAP? A standardized message structure
based on the XML Infoset A processing model that describes how
a service should process the messages A mechanism to bind SOAP messages to
different network transport protocols A way to attach non-XML encoded
information to SOAP messages Current version 1.2
What is SOAP? 3 aspects of SOAP Message
Envelope Header Body
SOAP is SOAP is not XML Based Protocol Independent Standards based Extendable
Supports an extension model similar to MISMO today.
Robust High adoption rate Cross industry buy in Seasoned Standard since
(2000) Strong 3rd party support
Independent of Web Services Web services have an
implementation as SOAP based extensions.
Protocol Dependant SOAP over MQ HTTP
What are Web Services? W3C Definition
A software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with XML serialization in conjunction with other Web-related standards.
What are the WS* Specifications/Standards? A set of requirements that codify
typical problem areas trading partners face when communicating over the internet.
XML based specifications and standards
SOAP based extensions
WS* SOAP Based Standards/Extensions Stack
SOAP HTTP SSL
WS-Security
Discovery
UDDI
Description
WS-Policy
WSDL
WS-BPEL
WS-MetaDataExchange
Delivery
WS-Reliable Messaging WS-Addressing
WS-Transaction WS-Coordination
Core Standards
Emerging Core
Extensions
WS-Events
Can MISMO use SOAP without Web Services? Yes
SOAP is an independent specification A complete Web Service-based solution is out of scope
Discovery Description
SOAP and Web Services are two independent adoptions There are SOAP extensions that have nothing to do with
Web Services SOAP allows MISMO to create their own extensions if we
desire Some WS Standards do not deal with the concepts of Web
Services Other WS Standards require the core concepts of Web
Services and are designed to support these services
Current MISMO challenges that SOAP can help solve. Security
XML encryption Authentication (Digital signatures)
Routing Flexibility to identify multiple intermediaries via pass
through headers Messaging
Unique message identification Large attachments/Messages Preferred Response(s)
Compression
Mapping MISMO to SOAPand WS* Can be implemented in several
different ways, all that are within the SOAP spec are “right”.
Standards/Specifications allow us to leverage multi-industry experts experience and knowledge.
What else can SOAP provide MISMO? Allow MISMO to concentrate on the
business of real estate transactions properties, borrowers, products .
Increased adoption/speed of integration by using open standards, tools, and 3rd party products.
Flexibility to allow MISMO workgroups to continue to push forward on pressing issues
Roadmap to SOAP, WS* Evolution not revolution Decide what can be placed in SOAP
headers and what can stay in body Decide whether to use current standards
or leverage SOAP extensibility (e.g. with an oversight body & approval)
Complete proof of concept Begin with basic SOAP headers
WS-Addressing WS-Security WS-Reliable Messaging
Which WS* Standards make sense for MISMO? Phase 1: Direct mappings to MISMO Envelope today
WS-Addressing WS-Security MISMO Security Workgroup WS-Reliable Messaging
Phase 2: Possible in the near future WS-Coordination- Multi-Services Workgroup WS-Eventing WS-Transaction WS-Coordination- Multi-Services Workgroup WS-BEPL- BREW
Phase 3: Potential Long Term Options WS-Metadata Exchange WS-Policy
Conceptual Sample SOAP based Envelope MISMO structure
SOAP Envelope
Security Header Block
Addressing Header Block
SOAP Body
SOAP Header
XML Payload
XML
WS-Security
WS-Addressing
MISMO
Sample WS-Addressing SOAP Header with MISMO Payload
Headers
Body
Current WS* Overview
SOAP HTTP SSL
WS-Security
Discovery
UDDI
Description
WS-Policy
WSDL
WS-BPEL
WS-MetaDataExchange
Delivery
WS-Reliable Messaging WS-Addressing
WS-Transaction WS-Coordination
Core Standards
Emerging Core
Extensions
WS-Events
For initial MISMO enveloping strategy concentrate on SOAP and message related standards first then evaluate other soap based standards as the need arises
How can SOAP and MISMO be Used Together Headers are used for
protocol/messaging specific items. (Headers are optional)
MISMO may be passed in the body of the SOAP message with little or no change to structure
MISMO XML Body goes here
What functionality do the MISMO headers provide today? Trading Partner information via
MISMO XML Submitting Party
Preferred Response Requesting Party Receiving Party
SOAP Node (Party), Roles, and Targeted Headers SOAP embraces the concepts of multiple
Nodes communicating together. SOAP defines 3 roles which can be put in
the header(s) to target the SOAP headers to specific Nodes along the service chain. (Insert roles here)
SOAP can be extended to support more roles as the need arises.
Client Server Integration
Client Boundary
Service Requestor
Provider Boundary
Service Provider
XmlMISMO
Scenario 1
SOAP Client, SOAP Intermediary, and SOAP Ultimate Receiver
Client Boundary
Service Requestor
(SOAP Node)
SOAP Intermediary
Service Provider(SOAP Node)
Service Provider
SOAP Sender(SOAP Node)
XmlSOAP/MISMO
XmlSOAP/MISMO
Message contains information for the original request and information intended to be
passed through the intermediary and destine for the end SOAP
node.
Certain XML headers in the SOAP header are passed through the intermediary to the SOAP server based on their defined role.
Scenario 2
SOAP Client, Intermediary, ServerMISMO Use Case
Client Boundary
Service Requestor
SOAP Intermediary
Service Provider
Service Provider
SOAP Sender
XmlSOAP/MISMOLOS Portal Product
Company
Securing SOAP•SOAP is the Foundation
•WS-Security is the Baseline
MISMO Security Requirements Requirements
Multiple security tokens for authentication or authorization
Multiple encryption technologies Payload integrity Multiple trust domains End-to-end message-level security
Security Issues w/ existing MISMO Envelope specification Clear text password is a security risk Clear text passwords transmitted
through intermediaries exposes all parties to unauthorized access
No embedded confidentiality of payload
No embedded integrity of payload Authentication multiple end point
support
WS-Security (SOAP Message) Design Goals
“… flexible set of mechanisms that can be used to construct a range of security protocols; in other words this specification intentionally does not describe explicit fixed security protocols.”
WS-Security Support Authentication
Username/Password (Clear/HASH Security token) PKI through X.509 Certificates (Security token) Kerberos (Security token)
Message Signing / Integrity All, part or external message (XML Signature)
Message Encryption All, part or external message (XML Encryption)
WS-Sec – Authentication
Username to be authenticated
Password to be used
Problem: Password is still in clear text and therefore
problematic for the intermediary situation.
Compatible support for
UserId/Passwd exchange
WS-Sec – Authentication/Hash
Password now sent as a SHA1
digest instead of clear text
Advantages:1. No clear text2. Anti-reply attack3. Intermediate
confidentiality
WS-Security Auth Summary When done correctly, a digest will
prevent replay attacks Digest provides confidentiality WS-Security also supports field level
encryption of the username and password, but only secure when done correctly. (Encryption vulnerable to replay/offline dictionary attack.)
WS-Addressing Design Goals
…provide a transport-neutral mechanisms to address Web services and messages. Provide a specification that enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner.
WS-Addressing Requirements
Ability to provide service endpoint reference information within SOAP headers
Ability to uniquely identify message that is sent to endpoint
Ability to define attributes for the return endpoint location.
Sample MISMO XML utilizing WS-Addressing URL this
message is being sent to
URL this message is being
sent from
URL the response should be sent back
to
Sample WS-Addressing SOAP Header with MISMO Payload
Maps to MISMO Preferred Response
WS-Reliable Messaging Defined Design Goals
Provide a SOAP based mechanism to for two services that wish to communicate to do so reliably in the presence of software component, system, or network failures. The primary goal of this specification is to create a modular mechanism for reliable message delivery. It defines a messaging protocol to identify, track, and manage the reliable delivery of messages between exactly two parties, a source and a destination. [spec 2004 Introduction]
WS-Reliable Messaging Supports Four messaging delivery assurances models
AtMostOnce-Message will be delivered at most once or an error will be raised
AtLeastOnce-Every message sent will be delivered or an error will be raised on at least one endpoint. Some messages may be delivered more than once.
ExactlyOnce-Every message sent will be delivered without duplication or an error will be raised on at least one endpoint. This delivery assurance is the logical "and" of the two prior delivery assurances.
InOrder -Messages will be delivered in the order that they were sent. This delivery assurance may be combined with any of the above delivery assurances. It requires that the sequence observed by the ultimate receiver be non-decreasing. It says nothing about duplications or omissions.
Concentrate on these aspects of RM
WS-Reliable Messaging Requirements
Support Works well with other SOAP based
standards that solve MISMO Issues. WS-Security WS-Addressing
WS-Reliable Messaging Benefits for MISMO Advantages
eMortgage Guaranteed delivery Acknowledgement of message receipt
and order of message receipt Others
WS-Reliable Messaging Sample
WS-Addressing Header
WS-Reliable Messaging Header
1/25/2006
1/25/2007
2/1/2006
3/1/2006
4/1/2006
5/1/2006
6/1/2006
7/1/2006
8/1/2006
9/1/2006
10/1/2006
11/1/2006
12/1/2006
1/1/2007
Mismo MilestonesEnveloping SOAP POC Milestone
10/15/2006Begin POC coding
With Java and .NET clients
11/14/2006Complete SOAP based
POC
9/5/2006Review structure POCWith Enveloping Group
7/25/2006Review if what is in the envelope
Makes sense and if it should stay or be moved
7/5/2006Determine SOAP based envelope
Structure (Header vs Body)
9/12/2006Mismo Face to Face
New Challenges SOAP brings “The XML looks harder to
understand” Expectations- It does not solve all
problems! (Provides framework to address the issues)
Competing / changing specifications and standards from various industry groups.