WS- Specifications

WS-* Specifications

A tremendous amount of WS-* specifications exist. Really all it takes to create one is for some individuals or organizations to get together and declare one to the world in some fashion. A number of non-profit organizations work on specifications and release them to the public. Some of these organizations include the aforementioned http://www.WS-I.org, as well as OASIS (oasis-open.org), and the W3C (w3c.org).

The following is a review of some of the more notable specifications.

WS-Security

When Web Services were initially introduced, they were not massively adopted. They lacked the security model most companies required before they could begin building technologies within the enterprise.

The specification WS-Security was developed by Microsoft, IBM, and VeriSign. It works on three main areas to make Web Services secure-credential exchange, message integrity, and message confidentiality.

Credential Exchange

WS-Security enables two entities to exchange their security credentials within the message itself. WS- Security doesn't mention the type of credentials needed for an exchange; therefore, it allows any type of credentials to be used.

Message Integrity

Messages can be sent through multiple routers and, in effect, bounce from here to there before they reach their final destination. You must ensure that the messages are not tampered with in transport. As messages move from one SOAP router to another, malicious people can make can make additions or subtractions in the SOAP nodes, thereby destroying the integrity of the message. As SOAP routers become more prevalent, using WS-Security to check for message tampering will increase in popularity.

Message Confidentiality

Encryption is one of the more important functions to apply to your SOAP messages. When your messages are zipping across the virtual world they can be intercepted and opened for viewing by parties who shouldn't be looking at their contents.

For this reason, it is beneficial to somehow scramble the contents of a message. When it reaches the intended receiver, he can use your encryption key and descramble the message to read the contents.

WS-Addressing

The Web Service Addressing protocol is a SOAP-based protocol that is used to route SOAP packets from one point to another over HTTP, TCP, or some other transport protocols. It is especially designed to route the SOAP packet through several points before it reaches its final destination.

To accomplish this, the path for the SOAP message is specified in the SOAP header along with the SOAP message. Therefore, when a SOAP message is sent, the message path is also connected to this message.

For example, you want to get a message from point A to point D, but in order to do this, you must route the SOAP message through points B and C along the way.

Figure 21-4 shows how this might look visually.

Figure 21-4

In Figure 21-4, point A is the initial SOAP sender. This is where you place the WS-Addressing information into the SOAP header. Points B and C are the routing points, known as either the SOAP nodes or SOAP routers. When they receive a SOAP message with a WS-Addressing specification about the final destination, these two points forward this message onto the next point. Point D is the ultimate receiver of the SOAP message that is specified in the SOAP header.

Contained within the SOAP header itself is a forward message path, an optional reverse path, and the points through which the message must be routed. The entire message path can be described directly in the SOAP header, so there's no need to include it elsewhere. These paths can be created dynamically at runtime as well.

WS-Attachments

WS-Attachments is a specification that was developed by Microsoft and IBM to ease the difficulty of adding attachments to SOAP messages. This specification was published in June of 2002. SOAP is a great way of representing data as XML, but it can be difficult to include images and documents within this structure.

You can do so today with Web services, but you use significant overhead to serialize an image into an acceptable XML form such as base64 using DIME. The receiver also bears a tremendous cost in processor power when he attempts to deserialize the message on the other end.

In addition to this problem, it is difficult to represent other XML documents in the payload of the SOAP messages, especially if these XML documents or XML fragments don't conform to the encoding type used in the SOAP message itself.

For these problems, WS-Attachments was created and can be used to keep other objects such as images, documents, and XML fragments from being serialized into the body of the SOAP message. This substantially increases performance for these types of payloads.

WS-Coordination

As companies start developing a multitude of Web services within their enterprise, they realized that many Web services have relationships with one another. WS-Coordination has been developed to describe the relationships of Web services with one another.

WS-Coordination is meant to be expanded by other specifications that further define specific coordination types. For instance, WS-AtomicTransaction works with WS-Coordination to create a coordination type that deals with the transactioning of Web services.

WS-MetadataExchange

WS-MetadataExchange enables you to define what services can be found at a particular site by making pointer references to the documents of a Web service that define the Web service's interface.

Core Specifications

The WS-* list goes on and on. The following table looks at some of the present specifications in light detail (shown in alphabetical order).

Open table as spreadsheet

WS-*Specification	Description
WS-Acknowledgement	Ensures reliable messaging by enabling the receiver to send a "receipt" for the message. Similar to the WS-ReliableMessaging specification.
WS-ActiveProfile	Provides the means to apply a federated identity to the active requestor. This works in conjunction with the WS-Federation specification.
WS-Addressing	Provides the means to apply message-based routing. This specification is considered a replacement to the WS-Routing and WS-Referral specifications. A similar specification to WS-Addressing is the WS-Callback specification.
WS-Attachments	Provides the means of applying one or more binary objects to your message using DIME. Using DIME is now considered obsolete by most vendors because MTOM is the preferred way to move binary objects.
WS-AtomicTransaction	Provides the means to apply atomic transactions to your messaging. Atomic transactions are "all or nothing" transaction types. This specification works with the WS-Coordination specification and is meant to be a replacement to the WS-Transaction specification.
WS-Authorization	Provides the means for a Web service vendor to describe how their Web services manage authorization data and policies.
WS-BaseFaults	Provides a way to define an XML Schema type for base faults. Allows for commonality in how SOAP faults are represented.
WS-BaseNotification	Provides a means to allow for a publish/subscribe mechanism for messaging. WS-BaseNotification works as part of the WS- Notification family which many subspecifications depend upon.
WS-BPEL	Formally known as BPEL4WS (Business Process Execution Language for Web Services), this specification provides the mechanics to apply workflow to messaging. This specification is considered a replacement for XLANG and WSFL.
WS-BrokeredNotification	Provides a publish/subscribe mechanism for messaging. WS BrokeredNotification works as part of the WS-Notification family.
WS-BusinessActivity	Provides the means (along with WS-AtomicTransaction) to provide transactions to your messaging. WS-BusinessActivity types of transactions are meant to be longer-lived transactions and can perform other actions based upon any possible failure points.
WS-CAF	Also known as the Web Services Composite Application Framework, this specification is really a collection of three specifications: Web Service Context (WS-CTX), Web Service Coordination Framework (WS-CF), and Web Service Transaction Management (WS-TXM). The purpose of WS-CAF is to help in the sharing of information and the transactioning of messages for composite applications.
WS-Callback	Provides the means to dynamically specify where to send asynchronous responses after receiving a request. A similar specification is the WS-Addressing specification.
WS-CF	Known as the Web Service Coordination Framework, this specification provides the means to specify a software agent to handle context management. This specification is part of the WS-CAF set of specifications.
WS-Coordination	Provides a means to apply transactions to your services. This specification works with WS-AtomicTransaction and WS-BusinessActivity to specify the transactioning functionality.
WS-Choreography	Provides the means to work within a peer-to-peer environment with any number of participants.
WS-CTX	Known as the Web Service Context, this specification provides the means the means of managing, sharing, and accessing context information between Web services. This specification is part of the WS-CAF set of specifications.
DIME	Known as Direct Internet Message Encapsulation, DIME provides the means to encapsulate binary data into a series of records. This allows for these types of objects to be delivered in a more performant manner than otherwise. DIME is now considered obsolete now by many vendors because MTOM is more capable.
WS-Discovery	Provides the means to discover services through a multicast discovery protocol. Any service that wishes to be discovered simply sends an announcement when the service wishes to either join or leave a discovery pool.
WSDM	Known as Web Services Distributed Management, this specification allows for the provision of management information via standards.
WS-EndpointResolution	Enables you to select endpoints from a group of available endpoints. This specification is meant to work with server farms or mobile devices.
WS-Enumeration	Provides the means of enumerating a sequence of XML elements meant for traversing logs, message queues, or other linear information models.
WS-Eventing	Provides the capability to subscribe or accept subscriptions from event notification messages. This specification competes with the WS-Events specification.
WS-Events	Provides the means to publish/subscribe to events via services. This specification competes with the WS-Eventing specification.
WS-Federation	Provides a means to manage and broker the trust relationships between entities via messaging.
WSFL	Known as the Web Services Flow Language, this specification provides the means to apply workflow to services through either a usage pattern or interaction pattern. WS-BPEL is the replacement for WSFL.
WS-Inspection	Provides the means to inspect a site for a list of available services. This specification is replaced by the WS-MetadataExchange specification.
WS-Manageability	Provides all the administration tasks available from a service as services themselves. This specification is replaced by WS-Management.
WS-Management	Provides the means to manage services using messaging and events. This specification is a replacement of the WS-Manageability specification.
WS-MessageData	Provides the capability to incorporate a specific message meta-data header.
WS-MessageDelivery	Provides the capability to build transport-agnostic services that provide their endpoints in the messages themselves. This specification is a competing specification to WS-Addressing.
WS-MetadataExchange	Provides the means to retrieve policies and an interface definition document. This specification is replacement to WS-Inspection.
MTOM	Known as Message Transmission Optimization Mechanism, MTOM provides the means to encapsulate binary data using XML-binary Optimized Packaging (XOP). MTOM is considered the recommended way to encapsulate binary objects rather than the MIME or DIME specifications.
WS-Notification	Allows for a publish/subscribe mechanism for messaging. WS BaseNotification, WS-BrokeredNotification, and WS-Topics are part of the WS-Notification family of specifications.
WS-PassiveProfile	Provides the means for passive requestors (such as Web browsers) to supply identity using WS-Federation. When using this specification, the end-user is limited to the HTTP protocol.
WS-Policy	Provides the means to define a service's requirements, preferences, and capabilities.
WS-PolicyAssertions	Provides the means to apply a set of common message policy assertions that can be specified within a policy. This specification works in conjunction with the WS-Policy specification.
WS-PolicyAttachment	Provides the means to reference policies from WSDL documents, associate policies with deployed Web services, as well as UDDI entities.
WS-Privacy	Provides the means for organizations to supply their privacy statements.
WS-Provisioning	Provides the means to facilitate interoperability between provisioning systems.
WS-Referral	Provides the means to define routing behaviors of messages received. This specification is generally used in conjunction with WS-Routing and is replaced by the WS-Addressing specification.
WS-Reliability	Provides the means to supply guaranteed message delivery and order. This specification competes with the WS-ReliableMessaging specification.
WS-ReliableMessaging	Provides the means to supply guaranteed message delivery with regard to software components, system, or network failures. This specification completes with the WS-Reliability specification.
WS-ResourceFramework	Also known as WSRF, this is really a definition for a family of specifications such as WS-ResourceProperties, WS-ResourceLifetime, WS-BaseFaults, and WS-ServiceGroup. Each of these specifications is provided to allow for the access of stateful services.
WS-ResourceLifetime	Provides the timeframe in which services can destroy their acquired state. The possible options include immediate or scheduled.
WS-ResourceProperties	Provides the capability to query or change a stateful resource.
WS-Routing	Provides the capability to route messages through any number of intermediaries. This specification is usually used in conjunction with WS-Referral. This specification is considered obsolete by many vendors and has been replaced by WS-Addressing or WSMessageDelivery.
WS-SecureConversation	Provides the means to manage and authenticate message exchanges between parties using security context exchanges or session keys.
WS-Security	Provides the means to apply credentials to messages in order to make the message transport-agnostic.
WS-SecurityPolicy	Provides the capability for Web service vendors to supply their security policies via the WS-Security specification.
WS-ServiceGroup	Provides the capability to group stateful resources that might be applied to a domain-specific purpose.
WS-Topics	Provides the means to allow for the grouping of topics that are used in the publish/subscribe mechanism for messaging. This specification is used in the WS-Notification family of specifications.
WS-Transaction	Provides the means to supply coordination types when used in conjunction with the WS-Coordination specification. This specification is considered obsolete and is replaced by the WS-AtomicTransaction and WS-BusinessActivity specifications.
WS-TransmissionControl	Provides the means to ensure message reliability.
WS-Trust	Provides the means for entities to exchange tokens.
WS-TXM	Known as Web Services Transaction Management, this specification allows for transaction protocols to be applied to a coordination framework. This specification is part of the WS-CAF set of specifications.

In this long table, you see plenty of specifications. Many companies put out specifications to augment their messaging frameworks even though the functionality is already provided via other specifications. Many vendors try to achieve their goals within a specification that is in competition with other specifications.

Vendors spend so much of their time creating specifications because they want interoperability within their product frameworks. A globally accepted specification allows this to happen. Most of the specifications defined in the preceding table are not actually implemented in any of the vendors' technologies. Only a small handful have been actually implemented and made workable across two vendors' platforms.

The rest of this chapter covers some specific technologies that implement these specifications. First, you investigate Microsoft's Web Services Enhancements 3.0.