ACORD Web Services Profile: 2.0 vs. 1.0 Kevin Schipani, Serge Cayron ACORD ACORD 2009
Agenda Introduction ti to AWSP 2.0 Members views - Requirements and Use Cases Conclusion
Background AWSP 1 for initial deployment (SOAP 1.1 generation) AWSP 1.0 standard release : January 2008 AWSP 1.1 standard release : May 2008 AWSP 2 - for deployment with target t WS standard versions (SOAP 1.2 generation) Working Group restarted in July 2009
AWSP goals To provide guidance for Service Oriented implementation of ACORD standards Developing a Profile for usage of Web Services Standards d will help ACORD members by lowering the number of unique party-to-party solutions. by providing interoperability rules and reduction of number of options for compatibility and cheaper implementation. by building a roadmap for incremental adoption of Web Services Standards
AWSP key topics How do I define Web Service interfaces for ACORD Standards? Basic SOAP and WSDL Profile Business Message Exchange Patterns and their WS implementation Basic transmission reliability Guidance on WSDL interface design How do I solve end-to-end addressing problems? Addressing Profile Go through messaging intermediaries Enable asynchronous responses Route to fine grain services.
AWSP key topics How do I secure message flows and service access? Security Profile Signature and encryption Identity communication How do I establish advanced Reliable and Secure sessions? Reliable Secure Profile (for future versions)
AWSP key topics How do I report errors at service infrastructure t level? l? SOAP Fault Profile How do I deal with attachments? t Attachment Handling Profile In-band communication Out-of-band communication How do I deal with batches? Message Groups and Batches Profile
What s new in AWSP 2 Seamless transport and security protection of in-band binary attachments Attachments are included as base64 encoded elements and automatically transformed into MIME parts for transport (MTOM standard). More flexibly specify service operations. Service operations can be defined for specific transactions, using WS-Addressing, and response endpoints can be controlled.
Policy Placement: Quotation
Service Granularity options for AML Fine Grain (with WS-Addressing) The ports and operations combine transaction types and line of business types e.g. ProfessionalIndemnityPolicyNewBusiness Coarse Grain (without WS-Addressing) The ports and operations map to transaction types e.g. PolicyNewBusiness
Policy New Business New Business Process Result Service Quotation client Order client PolicyNewBusinessQuotationProcess Acknowledgement PolicyNewBusinessOrderProcess Acknowledgement New Business Process Service Quotation Service Order Service Quotation Result Service Order Result Service PolicyNewBusinessQuotationProcessResult Acknowledgement PolicyNewBusinessQuotationProcessResult Acknowledgement Quotation Result client Order Result client
What s new in AWSP 2 Stronger standardization of WSDL interfaces for off-the-shelf h interoperability Messages (ACORD) Import Port Types (ACORD) Import Ports and Services (Company)
What s new in AWSP 2 Robust support of Messaging Intermediaries SOAP 1.2 header discriminates control information intended for intermediaries or endpoints. WS-Addressing conveys endpoint addresses through all nodes in the end to end flow. WS-Security protects information intended to endpoints or intermediaries. Security Profile enhancements Security Profile integrated Security features driven by use cases Added support for SAML - Identity assertion in support of fine grained Access Control rules.
Requirements met by AWSP 2 Jim Brain - Aegon
Attachment Processing Insurance business processes commonly require image or related data in addition to XML business data Real time processing demands in-band attachment handling Data is commonly binary format. File can be non trivial in size
AWSP 1.X Attachment Handling SOAP 1.1 uses Base64Binary inline attachments The data is contained in the SOAP Information Set (InfoSet), but Utilizes only 64 ASCII characters to represent binary data each h3b bytes of fdata become 4 characters Therefore, by definition, each file is increased by 33%. Thus, a 3MB image becomes 4MB under SOAP 1.1.
SOAP with Attachments SOAP with Attachments (SwA) attempted to overcome the 33% concern: Binary data could be sent as MIME attachment Reference to MIME attachment was stored in XML InfoSet But, the data was no longer part of the XML message, it was outside the message
AWSP 1.X message
AWSP 2.0 MTOM Attachments Message Transmission Optimization Mechanism MTOM provides best of both worlds: Attachments are sent as binary data, just like in SwA (In fact, MTOM messages are backwards compatible) XML InfoSet includes binary data. Thus, MTOM allows the XML and binary data to be treated as one unit, even though it is sent separately over the network.
MTOM Example <?xml version='1.0' encoding='utf-8'?> <soapenv:envelope xmlns:soapenv="..."...> "... <xop:include href="cid:1.a91d6d2e3d7ac4d580@apache.org" xmlns:xop="http://www.w3.org/2004/08/xop/include"> </xop:include>... </soapenv:envelope> --MIMEBoundary4A7AE55984E7438034 content-type: type: application/octet-stream content-transfer-encoding: binary content-id: <1.A91D6D2E3D7AC4D580@apache.org> Binary Data... --MIMEBoundary4A7AE55984E7438034--
Addressing and Routing Options AWSP 1.X relies on SOAP routing and addressing mechanisms for correct operation SOAP URL and Action: HTTP header specifies endpoint information Errors and Replies can only be sent to original sender Client can provide limited information about itself
WS-Addressing WS-Addressing provides richer routing options for the ACORD implementer Source can be identified with more (and more consistent) detail. As noted previously, service granularity is enhanced. Replies and Fault information can be directed d to other endpoints Services can redirect clients to alternative endpoints on subsequent calls. Routing is independent of transfer technology.
Security Considerations In today s regulatory environment, information security is critical: SSL/TLS data security is often not enough True end-to-end security must be ensured Services must authenticate and authorize clients Support for complex security constructs like tokens, tickets, and certificates must be supported
WS-Security Security Advantages WS-Security Security creates consistency in service protection Open framework allows multiple security methodologies to be implemented Standard addresses industry security requirements more completely Allows easier security integration
A Plug an Play approach KiNam Kim, Kevin Kosienski Mass Mutual
Delivery Plan December 2009: AWSP 2.0 draft with Basic Profile, Addressing Profile, Fault handling and Attachment handling February 2010: AWSP 2.0 draft with Security Profile, including SAML April 2010: AWSP 2.0 Candidate Recommendation.
Going Forward AWSP 2 intention is to become the master for specific implementation guides AWSP 2 approach: tool box with guidance based on use cases. Your Use Cases are needed for AWSP validation and enrichment!
Two Blue Hill Plaza 3 rd Floor Pearl River, NY 10965 USA +1 845 620 1700 London Underwriting Centre Suite 1/3 3 Minster Court Mincing Lane London EC3R 7DD United Kingdom +44 (0)20 7617 6400