The evolution of Web Services Specifications.
Web services standardization started with the submission of the SOAP 1.1 specification to the W3C. Later, SOAP with Attachments, and WSDL were submitted to W3C. The adoption and use of the Web services specifications (SOAP and WSDL) have grown for the addition of extended specification supporting addressing, policy, security, transactions, and reliability communication, those are enterprise applications aspects. These extended features are also called "qualities of service".
Web services specifications progress toward standardization through different ways, such as platform vendors and technical committees. The specifications are created by group of vendors such as Microsoft and IBM in collaboration with BEA, Intel, SAP, Tibco, and Verisign; and later submitted to a standard body for the subsequently adoption such as W3C, OASIS and WS-I.
Standards body.
The World Wide Web Consortium (W3C) began the standardization of Web standards such HTTP, HTML, and XML. Actually the W3C is home to SOAP, WSDL, WS-Choreography, WS-Addressing, WS-Policy, XML Encryption, and XML Signature.
The Organization for the Advancement of Structured Information Standards (OASIS) originally started to promote interoperability across Structured Generic Markup Language implementations. Actually OASIS is home to UDDI, WS-Security, WS-BPEL, WS-Composite Application Framework, WS-Notification, WS-Reliability, Web Services Policy Language, Web Services Distributed Management, and Web Services Resource Framework.
Web Services Interoperability (WS-I) is a standards body which promotes Web Services interoperability across platforms, operating systems, and programming languages. WS-I produces specifications called profiles that provide a common interpretation of other specifications and provides testing tools to help Web services vendors ensure conformance to WS-I specifications. A profile is a set of guidelines for the use of Web services specifications beyond the core protocols. These guidelines are important for creating interoperable Web Services. Interoperability Profiles also resolve ambiguities in areas where the Web services specifications are not clear enough to ensure that all implementations process SOAP messages in the same way.
The maturity of Web Services Specifications.
The most common used standards in the Web Services world are:
- XML Schema: For message data typing and structuring. It allows defining a common vocabulary that the sending and receiving party may understand for achieving the message interchange goal.
- WSDL: For associating messages and message exchange patterns (logic interface) with service names and network addresses (endpoints acting as physical interface).
- WS-Addressing: For including endpoint addressing and reference properties associated with endpoints. Many of the other extended specifications require WS-Addressing support for defining endpoints and reference properties in communication patterns.
- WS-Policy: For associating quality of service requirements with a WSDL definition. WS-Policy is a framework that includes policy declarations for various aspects of security, transactions, and reliability.
- WS-Security: For providing message integrity, authentication and confidentiality, security token exchange, message session security, security policy expression, and security for a federation of services within a system.
- WS-MetadataExchange: For querying and discovering metadata associated with a Web service, including the ability to fetch a WSDL file and associated WS-Policy definitions.
The former extensions are pretty intuitive to design and implement, because Web Services basic specifications (SOAP and WSDL) have an inherently support composition of new features, meaning existing applications can be extended instead of being changed.
When invoking a service, it's important to understand not only the data types and structures to send but also the additional qualities of service provided (if any), such as security, reliability, or transactions. If one or more of these features are missing from the message, it may prevent successful message processing.
The SOAP message is the basic unit of communication between SOAP nodes. It consists of a SOAP envelope that contains zero or more SOAP headers and a mandatory SOAP body. The header element is a generic mechanism for adding extensible features to SOAP. Each child element of header is called a header block. SOAP defines several well-known attributes that you can use to indicate who should deal with a header block and whether processing of it is optional or mandatory. The SOAP body is the last element and contains the payload, in our case a PurchaseOrder entity (see Listing 1.). SOAP defines no built-in header blocks and only one payload, which is the Fault element used for reporting errors. The mustUnderstand attribute controls whether the introduction of new header block is a breaking or nonbreaking change. The Header element in SOAP provides an extensibility mechanism. Each of these elements is some form of extension to the base SOAP protocol.For example one element may have information about security and other one has information pertaining to an ongoing transaction. For some extensions it is important that the client and the server must follow the rules, for example the security extension. In this case each header element may be annotated with a mustUnderstand attribute. If this attribute has a value of true or 1 then the header is considered to be mandatory. If the recipient of the message does not recognize or otherwise understand the header then it must generate a SOAP fault message. Headers without a mustUnderstand attribute (or with a mustUnderstand attribute with a value of false or 0) are to be considered optional. In order to sign a message, a security token is required and in our example we say to our service's consumer to follow a secure communication. Although many different types of security tokens such as Username, X.509, SAML, are available, our example shows a simple Username Token with a password digest. (see Listing 1.)
SOAP is defined independently of the underlying messaging transport mechanism in use. It allows the use of many alternative transports for message exchange. You can defer selection of the appropriate mechanism until runtime, which gives Web service applications or support infrastructure the flexibility to determine the appropriate transport as the message is sent using the binding mechanism. In addition, the underlying transport might change as the message is routed between nodes. For example, the invocation of a Web service may be done using http protocol, and the response is sent using smtp (via mail) to client.
<
env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<env:Header>
<wsse:Security env:mustUnderstand="1">
<wsse:UsernameToken wsu:Id="MyToken" mustUnderstand="true">
<wsse:Username>MyUserName </wsse:Username>
<wsse:Password Type="#PasswordDigest">
weYI3nXd8LjMNVksCKFV8t3rgHh3Rw=="
</wsse:Password>
<wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>
<wsu:Created>2004-09-20T01:34:44Z</wsu:Created>
</wsse:UsernameToken>
<wsse:Security>
</env:Header>
<env:Body>
<po:PurchaseOrder>
...
</po:PurchaseOrder>
</env:Body>
</env:Envelope>
Listing 1.
Composeability in Web Services.
Each of the Web service specifications addresses one specific concern and has a value in its own right, independently of any other specification. Although the specifications are defined to work stand alone, they might be complement each other.
WebServiceBindingAttribute class and WS-I.
As we can see there are a lot of specifications' revisions and versions around the Web services, so the communication between them might be so difficult to achieve. Perhaps, one client using some lower specification than the service that is invoking might not consume all the features or might have problems in the communication. We need some way of standardization in the behavior of the Web services, nowadays this role is played by WS-I.
As the WS-I initiative offers non-proprietary Web Services specifications to promote interpretabilities between them, using the WebServiceBinding attribute in Microsoft.NET 2.0, it is possible to select what profiles, our web services claims to conform for the communication with other side. The ConformsTo property, which is an enumeration of possible WS-I profiles, is set any value. By default, Web Services generated using Visual Studio 2005 are assumed to conform to the WS-I basic profile 1.1.
This setting doesn't imply that the Web Services is truly compliant, for example, in basic profile 1.1 every method must have a unique name (overloading is not allowed), and in that case, ASP.NET runtime determine the basic profile 1.1 validations and reports those issues.
You may ignore the basic profiles 1.1 conformance setting the ConformsTo property to WsiProfiles.None or the EmitConformanceClaims property to false programmatically. It is possible to configure the application for the same purpose as shown in Listing 2.
<configuration>
<system.web>
<webServices>
<conformanceWarnings>
<remove name='BasicProfile1_1'/>
</conformanceWarnings>
</webServices>
</system.web>
</configuration>
Listing 2.
You can overload methods in the implementation of the Web Service, but if you want to follow the basic profiles conformances, you must assure that every method has a distinct name. Using the MessageName property of the WebMethod attribute, it is possible to resolve name conflict.
The listing 3 defines a hypothetical Web service as explanatory purpose which receives a PurchaseOrder business entity (see listing 4) in a message and creates a message with receipt AcceptedOrder (listing 5) business entity for sending it to the wire. It is possible to the WebServiceBinding attribute enforcing the use of the best practices defined by the Web Services Interoperability (WS-I) organization.
using
System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;
[WebService(Namespace = "http://www.john.com/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Service : System.Web.Services.WebService
{
public Service ()
{}
[WebMethod]
public AcceptedOrder EnterPurchaseOrder(PurchaseOrder poOrder)
{
AcceptedOrder acAcceptedOrder = new AcceptedOrder();
Random objRandom = new Random( System.DateTime.Now.Millisecond );
acAcceptedOrder.AcceptedId=objRandom.Next();
acAcceptedOrder.AllInfo = String.Format("CustomerName: {0} and DeliverAddress: {1}",poOrder.Customer,poOrder.DeliverAddress);
return acAcceptedOrder;
}
}
Listing 3.
public class PurchaseOrder
{
private int m_nPurchaseOrderNumber = 0;
private string m_strCustomer = null;
private string m_strDeliverAddress = null;
private float m_flCredit = 0;
public PurchaseOrder()
{}
public int PurchaseOrderNumber
{
get
{
return this.m_nPurchaseOrderNumber;
}
set
{
this.m_nPurchaseOrderNumber = value;
}
}
public string Customer
{
get
{
return this.m_strCustomer;
}
set
{
this.m_strCustomer = value;
}
}
public string DeliverAddress
{
get
{
return this.m_strDeliverAddress;
}
set
{
this.m_strDeliverAddress = value;
}
}
public float Credit
{
get
{
return this.m_flCredit;
}
set
{
this.m_flCredit = value;
}
}
}
Listing 4.
public class AcceptedOrder
{
private string m_strAllInfo=null;
private int m_nAcceptedId = 0;
public AcceptedOrder()
{
}
public string AllInfo
{
get
{
return this.m_strAllInfo;
}
set
{
this.m_strAllInfo = value;
}
}
public int AcceptedId
{
get
{
return this.m_nAcceptedId;
}
set
{
this.m_nAcceptedId = value;
}
}
}
Listing 5.
Microsoft.NET Web Services Enhancements 3.0
Microsoft.NET 2.0 now supports the Web Services Enhancements 3.0 (WSE 3.0). Web Services Enhancements for Microsoft .NET (WSE) is a .NET class library for building Web services using the latest Web services specifications, including WS-Security, WS-SecureConversation, WS-Trust, and WS-Addressing. WSE allows you to add these capabilities at design time using code or at deployment time through the use of a policy file. It is defined a framework that augments the basic Web service framework provided by the Microsoft.NET 2.0 class library for Web Services hosted by the namespace System.Web.Services. The following table lists the Web services architecture specifications associated with the underlying aspects that is supported by the Web Services Enhancements 3.0 for Microsoft .NET (WSE).
| Aspects |
Specification |
| Security |
Web Services Security: SOAP Message Security (WS-Security) 1.0 and 1.1 |
|
Web Services Secure Conversation Language (WS-SecureConversation) |
|
Web Services Security X.509 Certificate Token Profile |
|
Web Services Security UsernameToken Profile 1.0 |
|
Web Services Security Kerberos Token Profile 1.0 |
| Web Services Addressing |
WS-Addressing |
|
SOAP 1.1 |
|
SOAP 1.2 |
Conclusion
With this paper, I've been talking about the evolutions of Web Services specifications and how Microsoft is been implementing every version or revision.