Usually, when companies hear that Microsoft has released a version of something, the first question asked is: "Does that mean their proprietary version or their implementation of the standards?" After taking a look at Microsoft's Web Services Enhancements (WSE) 1.0, I think you'll see that Microsoft understands and appreciates the importance of making their Web services tools interoperable and standards based. Instead of reviewing the WSE release specifically, let's look at the history of the standards and the architectural issues that arise when you consider utilising them.
Microsoft Web Services architectureThe most important thing for .Net architects to recognise is that the question isn't whether Microsoft will move deep Web services support into their platforms and tools. The question is really, "How fast can they do it?" Microsoft (along with IBM, BEA, and other platform providers) recognises the value of allowing systems to talk at the services level in a multipoint fashion. This is a value that cannot be recognised until standards exist beyond SOAP, XML, and UDDI -- standards that define how these systems interact. These additional standards will be implemented by adding metadata to the existing Web services standards, typically by extending the SOAP header with information specific to the services required. One of the biggest potential problems with this approach is the processing overhead required to decompose the SOAP header and act on all of the service requests. No one wants to see a secure, transacted, routable "Hello World" message that takes up 1 GB on the wire, but while the standards are evolving, you should expect some processing pain. Microsoft views their Web Services architecture as a set of design principles that they will use when implementing their versions of new Web services standards. These principles imply that Microsoft tools and technologies should allow architects to design Web services that are:
- Modular and composable -- Made up of individual elements that are combined into a unified service; can be factored to either stand alone or work together.
- General purpose -- Don't know or care where they're running or who called them.
- Standards based -- Should neither know nor care whether they're running on a single vendor's platform or platforms from multiple vendors.
- Federated -- No central point of administration, control, or failure, which allows partners to work together without having to explicitly trust each other. (In the words of one architect, "It's like working with your mother-in-law.")
The WS-I standards include twelve specifications, which can generally be broken down into three major categories: security, transactions, and reliable messaging. WSE implements SOAP header support for the first two of these major categories, allowing Web services from different vendors to share security and transaction context between calls. For example, under WSE's implementation, a Web service called from a Microsoft platform could pass the security context of the caller to a Web service running on an IBM WebSphere platform. If that same conversation involved multiple actions that are part of the same transaction, the transaction context may be passed as well. Let's take a more detailed look at some of the most important specifications:
- WS-Routing is designed to make the network virtual by routing messages across intermediate SOAP notes. You can think of WS-Routing as DNS for SOAP.
- WS-Referral allows for dynamic routing strategies by including information in the SOAP header about potential routing points.
- WS-Security (implemented in WSE) defines mechanisms for message-level security, including how to exchange credentials and verifying message integrity and confidentiality.
- WS-Attachments defines an abstract model for adding attachments to a SOAP envelope.
- WS-Coordination defines how multiple Web services can work together to accomplish a unit of work using a common context element.
- WS-Transactions (implemented in WSE) defines protocols that add end-to-end transactional behavior for two-phase commits (2PC) and long-running business services that require compensating transactions.
If taken to the logical extreme, the ability to securely connect, coordinate, and reliably route two transactional systems would allow two companies to create a virtual glass house between their systems using a VPN and 2PC support implemented as SOAP messages, regardless of their underlying computing platforms. And if each of those companies has another two or three integrated partners, and each of those partners have two or three partners, and so on, you've created a new, private Internet of sorts designed to pass messages rather than browse pages. Designing applications for this environment is radically different than creating ASP.Net Web sites or Windows Forms applications. It requires an understanding of not only the basic SOAP and XML standards, but also the tools and technologies that implement extensions such as WSE. As a .Net architect, you should take the time to download, install, and test new technologies such as WSE to be able to design systems that take advantage of them.
For a weekly round-up of the enterprise IT news, sign up for the
Enterpise newsletter. Find out what's where in the new Tech Update with our
Guided Tour. Tell us what you think in the
Enterprise Mailroom.
Enterpise newsletter. Find out what's where in the new Tech Update with our
Guided Tour. Tell us what you think in the
Enterprise Mailroom.
Related stories
Post your comment
In order to post a comment you need to be registered and logged in.
You can also log in with Facebook. Log in or create your ZDNet UK account below
By signing up for this service, you indicate that you agree to our Terms and Conditions and have read and understood our Privacy Policy. Questions about membership? Find the answers in the Community FAQ
