SOA Software Homepage
 

Standards Support

Click here to view a print-ready version of this page

SOAP and XML
Attachments
SOAP 1.1 Request Optional Response HTTP Binding
WS-Security
WS-Security Policy
WS-MetadataExchange
WS-Addressing
WS-Addressing 1.0 - WSDL Binding
WS-Routing
WS-Inspection
WS-ReliableMessaging
Web Services for Remote Portlets
Security Assertions Markup Language
RSS and Atom
XSLT
WS-Policy
UDDI
WS-I Attachments Profile
XPath
XML Encryption
XML Signature
WS-I Basic Profile
WS-I Basic Security Profile
Transparent Pass-through of Non-Mediated Messages

SOAP and XML
The Service Manager intermediaries (Agent, Delegate, and Network Director) are capable of receiving, routing and emitting SOAP messages conformant to the SOAP 1.1 or SOAP 1.2 specifications, relevant parts of the WS-I basic profiles (Simple SOAP Binding Profile Version 1.0, etc.), and non-disruptive to canonicalization transformations (Canonical XML 1.0, Exclusive XML Canonicalization Version 1.0, SOAP 1.2 Message Normalization) used in common message signature algorithms.

Non SOAP messages (aka XML-over-HTTP or plain-old XML [POX]) can also be routed (XML 1.0 and 1.1, XML Schema 1.0 and 1.1 are supported).

Attachments
The Service Manager intermediaries (Agent, Delegate, and Network Director) provide transparent pass-through of message attachments. Retransmission of mediated messages will emit transformed messages with identical or specification equivalent attachment descriptions, references, and attachment encodings. This also includes indirection models like Resource Representation SOAP Header Block et al.

SOAP 1.1 Request Optional Response HTTP Binding
The Network Director and Agent intermediaries provide out-of-the-box support for the SOAP 1.1 Request Optional Response HTTP Binding. If a SOAP 1.1 message arrives at either type of endpoint over an HTTP transport, and the SOAP envelope header contains a WS-Addressing header of type ReplyTo or From, and the header value is non-anonymous, the Network Director or Agent will follow the Optional Response HTTP Binding specification and return a 202 HTTP status code with no payload.

WS-Security
WS-Security 1.0 and 1.1 is supported in both Service Manager Policy Implementation and Enforcements Points (Agent, Delegate, and Network Director). The aspects of WS-Security that will be enforced and/or implemented at runtime are configured as policies in the Service Manager console. The configurable aspects include the following:

  • Encryption
  • Digital Signature
  • Timestamp
  • Username Token Profile
  • SAML Token Profile
  • X.509 Token Profile
  • Kerberos Token Profile

Supported Namespaces:

  • http://schemas.xmlsoap.org/ws/2002/07/secext
  • http://schemas.xmlsoap.org/ws/2002/04/secext
  • http://schemas.xmlsoap.org/ws/2003/06/secext
  • http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd

WS-Security Policy
Responses to WS-MetadataExchange requests for a dialect of WS-Policy will include WS-Security Policy assertions describing WS-Security capabilities (i.e. acceptable WS-Security token types, etc.).

Supported Namespaces:

  • http://schemas.xmlsoap.org/ws/2002/12/secext
  • http://specs.xmlsoap.org/ws/2005/07/securitypolicy/
  • http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512

WS-MetadataExchange
The Network Director intermediary can respond to WS-MetadataExchange requests for WS-Policy, WSIL, and WSDL dialects for any virtual or proxied service. The capbilities and metadata expressed in each of the dialect specific responses are those of the mediated, virtual service interface, regardless of MEX support at the original, proxied endpoint.

Supported Namespaces:

  • http://schemas.xmlsoap.org/ws/2004/09/mex

WS-Addressing
The Service Mangaer intermediaries (Delegate, Agent, and Network Director) allow for asynchronous dispatch and receipt via WS-Addressing. Dynamic routing and next-hop transmission is also supported, again via WS-Addressing. WS-Addressing headers are also used (or suppressed) in Message Exchange Pattern (MEP) mediation scenarios. The WS-Addressing infoset is realized concretely via the WS-A SOAP binding.

Supported Namespaces:

  • http://schemas.xmlsoap.org/ws/2003/03/addressing
  • http://schemas.xmlsoap.org/ws/2004/03/addressing
  • http://schemas.xmlsoap.org/ws/2004/08/addressing
  • http://www.w3.org/2004/12/addressing
  • http://www.w3.org/2005/02/addressing
  • http://www.w3.org/2005/03/addressing
  • http://www.w3.org/2005/08/addressing

WS-Addressing 1.0 - WSDL Binding
By default, WSDLs consumed through Service Manager’s Delegate, Agent and Network Director Intermediaries will not decorate the basic service description with WS-Addressing attachments or bindings. This is done in order to guarantee that the WSDL emitted by default is compatible with all SOAP stacks and toolkits out of the box. However, for enterprises using toolkits or stacks that are able to consume and generate code form WS-Addressing elements in the WSDL, Delegate, Agent and Network Director Intermediaries provides an “addHeaders” directive to force decoration of the WSDL with the WS-Addressing bindings. For stacks capable of consuming and emitting the operation bound WS-Addressing Action header, generic virtual endpoints are provided to enable simple configuration and loose coupling with concrete service implementations.

WS-Routing
For legacy systems and SOAP stacks that do not support WS-Addressing specification, the Network Director and Agent intermediaries provide routing and mediation for the legacy WS-Routing specification.

Supported Namespaces:

  • http://schemas.xmlsoap.org/ws/2002/04/rp
  • http://schemas.xmlsoap.org/rp/

WS-Inspection
For any virtual endpoint deployed in the Network Director or Agent intermediaries, an HTTP GET request to the virtual URL, appended with a “?wsil” or “?WSIL” query string, will return a WS-Inspection document for that service. Alternatively, the WSIL document can be retrieved via a WS-MetadataExchange request to the endpoint for the WS-Inspection dialect.

Supported Namespaces:

  • http://schemas.xmlsoap.org/ws/2001/10/inspection/

WS-ReliableMessaging
The service manager intermediaries (Network Director, Agent, and Delegate) can participate in a Web Services Reliable Messaging exchange either as a client or a receiver. Alternatively, the Network Director intermediary can bridge non-WS-RM reliable exchanges with WS-RM exchanges.

Furthermore, the Network Director intermediary can mediate between any two of the WS-RM specification versions listed below.

Configuration of the WS-RM capabilities is done via WS-RM policy assertions specifying the behavior of the exchange (i.e. delivery assurance, sequence expiry, etc.).

Supported Namespaces:

  • http://schemas.xmlsoap.org/ws/2003/03/rm
  • http://schemas.xmlsoap.org/ws/2004/03/rm
  • http://schemas.xmlsoap.org/ws/2004/08/rm
  • http://schemas.xmlsoap.org/ws/2005/02/rm
  • http://docs.oasis-open.org/ws-rx/wsrm/200602
  • http://docs.oasis-open.org/ws-rx/wsrm/200510
  • http://docs.oasis-open.org/ws-rx/wsrm/200608

Web Services for Remote Portlets
The Network Director intermediary can mediate WSRP services. Due to the nature of the WSRP operation Namespaces per deployment, WSRP services must be registered explicitly as remote portlet implementations. All mediation enhancements (MEP mediation, reliability, etc.) are still available, as the only delta is a taxonomic distinction within the registry. Both WSRP 1.0 and 2.0 compliant WSDLs can be registered.

Security Assertions Markup Language
The Network Director, Delegate, and Agent intermediaries support SAML 1.0 and 1.1. For receiving intermediaries, the following confirmation methods are supported: “Holder of Key” and “Sender Vouches” are supported, though PKI resources must be configured prior to enabling SAML Assertion support.

RSS and Atom
The Network Director intermediary provides a number of mediation services for feed and syndication formats. Consumption and delivery support, as well as aggregation of items from multiple sources can occur across and between multiple standards (i.e. RSS 0.94 items and Atom 0.3 items can be aggregated into a single logical feed and re-transmitted as Atom 1.0).

Along with email and WS-Eventing subscriptions, alerts and notifications can also be created and consumed in any of the syndication formats listed below.

Supported Formats:

  • RSS 0.9
  • RSS 0.92
  • RSS 0.93
  • RSS 0.94
  • RSS 1.0
  • RSS 2.0
  • Atom 0.3
  • Atom 1.0

XSLT
The Service Manager Policy Enforcement Points (Agent and Network Director Intermediaries) support transformations over the entire message.

Policies are re-evaluated post transformation in case the message content change meets new policy enforcement criteria.

Both XSLT 1.0 and 1.1 style sheets are supported by the Service Manager XSLT engine.

WS-Policy
Service Manager Policy Enforcement Points (Agent and Network Director Intermediaries) provide two means of generating consumable WS-Policy serializations. The first is via WS-MetadataExchange requests - for any virtual or proxied service, sending a WS-Policy dialect request to the service endpoint will return the WS-Policy assertions germane to that service interface.  The second means is consuming applicable WS-Policy attachments in the WSDL served up from the intermediary. 

Supported Namespaces

  • http://schemas.xmlsoap.org/ws/2004/09/policy
  • http://www.w3.org/2006/07/ws-policy

UDDI
Service Manager deploys with a UDDI v2 and v3 (3.02) compatible registry. All services managed by Service Manager are stored in the registry. Customers can categorize and search those services using customer-defined categorization schemes.

WS-I Attachments Profile
All Service Manager Policy Enforcement Points (Agent and Network Director Intermediaries) can process messages that contain attachments as defined by the WS-I Attachments Profile. Service Manager can also validate that created or imported WSDL documents conform to the WS-I Attachments Profile.

XPath
All Service Manager Policy Enforcement Points (Agent and Network Director Intermediaries) can process messages that contain attachments as defined by the WS-I Attachments Profile. Service Manager can also validate that created or imported WSDL documents conform to the WS-I Attachments Profile.

XML Encryption
All Service Manager Policy Implementation and Policy Enforcement Points (Delegate, Agent and Network Director Intermediaries) can encrypt and decrypt message content based on the XML Encryption specification. The configuration of the use of XML Encryption is specified through policies. This support is independent of WS-Security.

XML Signature
All Service Manager Policy Implementation and Policy Enforcement Points (Delegate, Agent and Network Director Intermediaries) can sign message content and verify message signatures based on the XML Signature specification. The configuration of the use of XML Signature is specified through policies. This support is independent of WS-Security.

WS-I Basic Profile
All Service Manager Policy Implementation and Policy Enforcement Points (Delegate, Agent and Network Director Intermediaries) can process messages that conform to the WS-I Basic Profile versions 1.0 and 1.1. Any message, such as a fault message that is generated by a Policy Implementation or Policy Enforcement point will conform to the WS-I Basic Profile. Service Manager can also validate that created or imported WSDL documents conform to the WS-I Basic Profile.

WS-I Basic Security Profile
Service Manager provides a flexible policy model for securing SOAP messages using WS-Security. These policies can be assembled to ensure compliance with the Core WS-I Basic Security Profile as well as the following related profiles:

  • Username Token
  • X.509 Certificate Token
  • Kerberos Token
  • SAML Token

Transparent Pass-through of Non-Mediated Messages
In situations where a dialect or specification is not explicitly understood by the intermediary, then the message model will be passed through without interference. For instance, while Service Manager Intermediaries do not provide domain specific transformations (other than the enveloping and metadata message aspects) for specifications such as WS-DM, ebXML, etc.