It has been eight years now since SOAP and WSDL (Web Service Description Language) were introduced as standards to facilitate communication and data exchange between heterogeneous systems. Since then, a flurry of protocols, collectively named WS*, have also been introduced as extensions to SOAP (and in some cases WSDL) to facilitate specific communication requirements and scenarios. The categories of WS* are broad, and it has reached a point where the sheer number of standards is so great that despite a core set being implemented in many platforms, many in the web service community are confused about which standards they should care about, when and why. Furthermore, concerns over interoperability prevail, as each standard traverses its lifecycle of development, early adoption, ratification and update.
With this article it is my intention to summarize the WS* protocols you hear about the most, while also emphasizing the most relevant standards you'll use today in terms of their actual implementation among web service platforms (with a focus on Java and .NET), their level of adoption and readiness, and their applicability to specific integration scenarios with .NET. If you are new to web services or to the WS* protocols, or you are having difficulty keeping up with the pace of change in this area, this article should help you to get your arms around the protocols that you hear the most about, and their purpose. I'll also talk briefly about the phases of interoperability around these advanced standards.
Revisiting SOAP+WSDL
SOAP was first introduced in 1999 - a short specification that describes how to format messages between applications, leveraging XML at its core to promote interoperability. If you think about it, the SOAP protocol really only describes a wrapper around a message: where to place headers, where to place the message payload, how to indicate the intention of the request (or, the "action") - the basic requirements that enable platforms to process SOAP messages to perform work. This is great, but the extracted header and body elements still need to be understood if they are to be converted into platform-specific runtime types. That's where WSDL comes in. WSDL describes the Url where a service can be reached, the supported operations (actions) at that location, and the format for messages and related type definitions described by XSD Schema. While the message is framed in SOAP, WSDL describes the application-specific messaging requirements.
It turns out that WSDL (Web Services Description Language) combined with SOAP is what really improved developer productivity for developing systems that share data. Though there were many interoperability issues early on, today, platform support for SOAP and WSDL, and for XML serialization of types, make it possible to develop and host web services on any platform, produce a WSDL that describes messaging requirements, and generate client code to invoke operations with little effort. You might say "you had me at SOAP" because it solved a problem not addressed by POX ("plain old XML") approaches - a programmatically discoverable description and tools to help with code generation.
Why WS*?
The actual contents of message headers and body elements are not defined by the SOAP specification. An application can fully customize what headers it requires, and what data the body should include to do meaningful work at a particular operation. Certain common needs are shared, however, across business implementations of SOAP -message routing and addressing, dealing with large message payloads, and providing secure and reliable communication at the forefront. That's where WS* protocols come in.
WS* refers to a seemingly forever growing set of standard protocols based on the SOAP specification and developed with wide industry backing. Their purpose is to facilitate common messaging requirements between systems. For example, at some point it became obvious that a standard was needed for sending a username and password credential, among others, since developers everywhere were creating custom SOAP headers that basically did the same thing. Thus, WS-Security was born. It also because quickly apparent that a specification was needed to reduce the overhead of sending and processing binary data, thus several incarnations of optimized binary transfer evolved until the community settled on MTOM. By forming standards around these and other common scenarios vendors can produce tooling to facilitate development around them - and improve developer productivity for more than just simple message exchange.
Figure 1: Core categories for web service protocols.
Figure 1 illustrates some of the major categories under which web service-related protocols fit. Organized this way, it may not look so daunting, but when you expand the list of standards within each category it is easy to become a little overwhelmed. In the sections to follow, I'm going to provide an overview of the current state of key standards from each category. I'll discuss their ratification status, their main purpose and value, and their applicability in today's Java platforms and in WCF.
NOTE: I will only refer to WCF as the .NET platform relevant to this discussion, since it Microsoft's WS* implementation. There are numerous implementations of WS* on the Java side, so for the purpose of this article, I will generalize in terms of standards adoption among platforms.
Transport Protocols
Transport protocols are required to facilitate message delivery, of course. The SOAP Protocol Binding Framework (http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew) describes how any protocol binding can be defined to support message transfer. The two officially documented bindings are:
- HTTP: http://www.w3.org/TR/2007/REC-soap12-part2-20070427/#soapinhttp
- SMTP: http://www.w3.org/TR/soap12-email
One normally thinks of SOAP messages as being transferred over HTTP or HTTPS, and this is certainly the most common scenario for interoperability between Java and .NET. In fact the nature of SOAP and WS* enable you to expose services over any protocol, even beyond those described in official bindings such as TCP, named pipes, UDP and even custom protocols. Platforms like Microsoft's Windows Communication Foundation (WCF) use SOAP messaging over these and more protocols, since the platform is based on this common messaging format. Of course implementations over non-HTTP are not interoperable.
Protocol bindings describe how to transfer messages over a particular protocol, including how to map appropriate addressing information to protocol headers. In fact, WS-Addressing removes the coupling of addressing headers from the transport protocol - describing an alternative for addressing semantics that is completely encapsulated in the message payload.
As far as traditional platform support for web services, you'll typically use HTTP or HTTPS where interoperability is concerned.
XML Standards
XML and XSD Schema are of course at the heart of SOAP, WSDL and WS* - making it possible to document messaging requirements. XML Digital Signature and XML Encryption are standards related to securing parts of an XML document (or, a SOAP message) thus are appropriately leveraged by WS-Security protocols. What's important about this last point is that when WS-Security was introduced, it did not reinvent the wheel in order to achieve message security around credentials and other message parts - it leveraged specifications that already had digital signature and encryption libraries to protect XML documents.
Messaging-Related Protocols
There are several protocols that support general messaging features - starting with SOAP as the overarching message format. Most platforms today support both SOAP 1.1 and SOAP 1.2 formats - the latter of which standardizes on document literal message format (schema-based, as opposed to encoded). SOAP 1.2 is usually the default setting for platforms today. However, if you are exposing services that must be backward compatible with legacy clients you may need to explicitly configure the service to serialize messages using SOAP 1.1.
WS-Addressing: W3C Recommendation, August 2005
As I mentioned earlier, WS-Addressing decouples addressing and routing from the transport layer. This allows you to send SOAP messages across multiple hops, over any protocol, in a consistent manner. It also provides a standard way to describe web service endpoints for asynchronous operations and publish/subscribe patterns. WS-Addressing is a core dependency of many other WS* protocols which stack on top. Most platforms today can support WS-Addressing protocol - in fact web services most often support SOAP 1.2 with WS-Addressing.
Generally, you will not see addressing headers, they will just "happen" as you expose or consume web services with platforms that support the protocol. However, since some platforms also supported non-ratified releases of WS-Addressing it may sometimes be necessary to configure your clients or services to support an older version in the spirit of interop.
WS-Transfer: W3C Submission, September 2006
WS-Transfer supports CRUD operations against resources via SOAP messaging - decoupling these actions from HTTP verbs to provide a transport-independent implementation of REST. I wouldn't go so far as to suggest WS-Transfer as an alternative to a RESTful architecture over HTTP, since the addressing semantics are completely different, but this protocol can be useful for services that are centered around access to resources, as opposed to operations. You might, for example, look at implementing this specification as part of your web service offering if your services focus on CRUD operations.
Most implementations of WS-Transfer today are proprietary in nature - that is, the specification itself is not an integral part of any web service platform - but it is easy enough to follow the specification and implement your own.
WS-Enumeration: W3C Submission, March 2006
WS-Enumeration defines a protocol for traversing a large result set, like a forward-only, read-only cursor into a data set. Like WS-Transfer, this specification is not an integral part of any platform, but it is easy to implement the specification if this pattern of access makes sense.
WS-EventNotification
WS-EventNotification describes how to support distributed events and notifications, as in publish and subscribe scenarios, independent of transport protocol. It is a work-in-progress that represents the unification of other competing specifications: WS-Notification and WS-Eventing. WS-Notification and related standards (WS-BaseNotification, WS-BrokeredNotification, and WS-Topics) became an approved OASIS standard as of October 2006 (http://www.research.ibm.com/journal/sj/444/niblett.html). WS-Eventing became a W3C Submission in March 2006 (http://www.w3.org/Submission/WS-Eventing), a simpler approach to notification infrastructure than that described by WS-Notification.
The unification of these standards (discussed here) illustrates that even when a specification has been ratified, as WS-Notification was by OASIS, it is still possible to move toward industry agreement on a standard so that platforms can be interoperable. So long as there are competing standards for a particular purpose, which does happen from time to time, it dilutes the implementation across platform vendors, making interoperability difficult.Wide interoperability will not be achieved for notification until WS-EventNotification has reached a state of (near) ratification. There are, however, a few implementations of WS-Notification and WS-Eventing with mild adoption.
MTOM: W3C Recommendation, January 2005
MTOM (Message Transmission Optimization Mechanism) describes how to transfer binary data as part of a SOAP message in a more efficient manner. This specification represents an evolution from SwA (SOAP with Attachments) and DIME (Direct Internet Message Encapsulation). MIME encoding is the foundation for all of these protocols - the goal being to remove the bloat and parsing overhead associated with base64-encoded binary data embedded in the SOAP message (the XML infoset). MTOM, however, builds on this by leveraging XOP (XML-Binary Optimized Packaging) to reference the extracted binary content from the SOAP envelope, so that the message receiver can reconstitute the binary data into the correct location of the XML infoset. Put another way, binary data can be referenced by a particular element in the SOAP body, which usually means it is evaluated as a parameter to an operation.
SwA only reached W3C Note status in June 2004, but WS-I incorporated this standard into the Basic Attachments Profile and thus there are many platforms that implement this specification. DIME was also implemented in many platforms, specifically by Java platforms that wanted to achieve interoperability with .NET and Web Services Enhancements (WSE) (pre-WCF) which did not support SwA. Both SwA and DIME are considered obsolete today, and MTOM having been two years ratified at this point has wide platform adoption and a successful interoperability story.
You shouldn't need to look at the details of an MTOM implementation, rather just configure clients and services in your platform of choice to enable the protocol for messages that might include binary content.
Security Protocols
Security protocols were among the first to begin stabilizing across platforms when WS* began to evolve. Initial drivers were based on the need to standardize on how credentials were serialized, so that individual implementations didn't have to reinvent the wheel. Additional security scenarios quickly surfaced specifically related to message protection on the wire, secure sessions and identity federation.
Transport vs. Message Security
To protect messages during transfer they should be digitally signed to ensure integrity, and encrypted to ensure privacy. This can be achieved at the transport level, or using message security. Although not all scenarios for employing security protocols leverage message security, it is a suggested approach. When transport security is employed, messages are only protected from point-to-point as shown here:
By comparison, message security passes credentials in the SOAP envelope and applies OASIS SOAP Message Security to sign and encrypt message parts. One of the most important aspects of message security is that it uses interoperable standards to secure message transfer, and since message security protects the message independent of transport it is possible to protect messages all the way through to the ultimate message receiver (or, target application) providing end-to-end security as shown here:
This makes it possible to pass messages through a content-based router, or management intermediary (for example) without exposing sensitive information.
It is always considered more secure to use message security. What you have to ask yourself is whether there will be unnecessary liability or risk associated with messages that land at an intermediary of some sort, and are not protected when passed to downstream services. Usually, the intermediary is part of the trust domain of downstream services, but other message routes are possible.
WS-Security: OASIS Standard, March 2004, updated February 2006
WS-Security is an open format for signing and encrypting message parts (leveraging XML Digital Signature and XML Encryption protocols), for supplying credentials in the form of security tokens, and for securely passing those tokens in a message. The roadmap began back in 2002, but as of the middle of 2004 version 1.0 was ratified by OASIS, with an update (version 1.1) in February 2006. The core standards in this group comprise WS-Security Core (SOAP Message Security) and several token profiles including UserName Token Profile, X.509 Token Profile, Kerberos Token Profile, and SAML Token Profile. The token profiles enable serializing credentials in a consistent manner across platforms, certainly one of the driving forces behind the adoption of WS-Security in the first place.
Given that WS-Security has evolved since 2002, it should be no surprise that most of the interoperability problems that plague early adopters in this space have been worked out. For example, early on even passing a simple UserName token was a challenge between platforms. Now, agreement on the format has aged long enough that the more recent versions of web service platforms are successfully agreeing on the implementation. The same types of challenges have existed with other aspects of the specification, only to eventually resolve for the most common scenarios. Among the most common scenarios for implementing WS-Security today are:
- UserName token over transport security: This is probably the most popular way to secure services today, because it is considered by many as "good enough security" for their implementation needs.
- UserName token over message security: This is used in scenarios where it is desirable to secure messages that might pass through some form of intermediary such as a router. Message security can reduce liability in these scenarios - and in my opinion should be used wherever possible.
- Mutual certificate authentication: This is commonly used in business partner scenarios where the caller is identified by an X.509 certificate, in lieu of a username and password. In some cases an X.509 certificate is used to prove the originating partner, while a UserName token is also provided to identify the specific user making calls to the service, for authorization and audit trail purposes.
Kerberos token authentication is also important for Intranet scenarios, but is not typically used for web services exposed outside the firewall. SAML is also very commonly used in scenarios that involve federation, which I'll discuss shortly.
You'll find that Java and WCF platforms interoperate quite well for these common scenarios for WS-Security, using SSL or message security for signing and encryption.
WS-SecureConversation: OASIS Standard, March 2007
WS-SecureConversation is a specification that describes the concept of a secure session that reduces the overhead of multiple call exchanges. A security context token (SCT) is generated through an initial exchange between caller and service using the WS-SecureConversation protocol, and this token is used to authenticate subsequent message exchanges (similar to an SSL handshake). A secure session identifier generated during this exchange is also used to correlate messages within the session.
This protocol is very important standard for improving the performance of one-shot message security, where credentials are passed with each call, and authenticated for each call. By creating a shared session key through negotiation, the key size used to sign and encrypt messages becomes smaller (using a symmetric key instead of an asymmetric key), which also reduces processing overhead.
Although WS-SecureConversation has only recently been ratified it has been implemented in multiple Java platforms and in WCF - thus interoperability can be achieved today for this protocol. That being said, if you want your web services to reach a wide audience today you should expose alternate configurations with and without WS-SecureConversation so as not to limit the number of client platforms that can communicate with your services. Introducing sessions also has implications on load-balancing, since it implies that the web service platform must cache the secure session identifier and associate it with an authenticated caller. The location where the platform caches this information may determine if callers must be directed back to the same server machine within a secure session.
WS-SecureConversation is listed under the OASIS Committee, WS-SX: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx.
WS-Trust: OASIS Standard, March 2007
WS-Trust is an interoperable protocol that supports the issuance, renewal, and exchange of security tokens. The protocol is used to issue security context tokens, as described by the WS-SecureConversation protocol, but it is also the key to a federated security model. In a federated security model WS-Trust supports the delegation of authentication or authorization activities such that a centralized service, called a token issuer or a Security Token Service (STS), is responsible for issuing a security token that will be accepted by application services. Although any token format can in theory be issued by an STS, SAML tokens are quite popular since they are a richly interoperable XML token format that can be used to identify the caller and even describe their rights to application features.
Figure 2 illustrates a simple scenario where application services request callers to present SAML tokens issued by a particular, trusted STS. In this case, a UserName Token is presented to the STS and a SAML token returned that can be used to authenticate to application services. The WS-Trust Issue() operation is responsible for authenticating the caller and if successful generate a token that can be used by application services. The token is digitally signed by the STS, so that application services can verify it came from a trusted source and was not tampered with en route. For this scenario, usually application services and trusted STS are owned by the same organization.
Figure 2: A simple token issuance scenario using WS-Trust.
Federated identity models based on WS-Trust make it possible to build application services that authorize calls independent of a particular type of credential. Instead of including logic at the service to authenticate UserName token for Internet partners and Kerberos tokens for internal users - the service requests a trusted SAML token for both cases and leaves credential support and authentication to the trusted STS. If the STS later adds support for different credentials, it has no effect on application services since they continue to rely on a SAML token. An STS can also request SAML tokens that describe the rights an authenticated caller has in the context of a particular service and operation - thus delegating authorization to the STS.
Any platform can implement an interoperable WS-Trust endpoint by following the guidelines of the protocol, in order to support token issuance - but you are unlikely to build your own from scratch. Rather, to implement a simple token issuance model you can use one of the community implementations of an STS - written for Java or WCF platforms - and modify it to meet your specific needs. This will save you significant effort. For and enterprise quality result, you will most likely choose a product implementation such as Ping Identity's PingTrust or Microsoft's ADFS (Active Directory Federation Services) - the latter of which will support federation over web services in its next release. Using either approach, interoperability will depend on many factors including the WS-Trust implementation, the token formats supported by the STS for authentication, and the token formats that can be issued by the STS.
WS-Trust is currently listed under the OASIS Committee WS-SX: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx.
WS-Federation: Public Draft, December 2006
WS-Federation is a specification that builds on WS-Security, WS-SecureConversation, and WS-Trust to support federation of identity across trust domains, and to support mapping identities in support of single sign-on and sign-off.
There are two profiles for WS-Federation:
- Passive Requestor Profile: This profile is currently supported by products such as PingFederate and ADFS, to enable browser-based Single Sign-On (SSO) and identity federation.
- Active Requestor Profile: This profile is currently supported by PingTrust, and will be supported by ADFS in future, to support identity federation over web services.
WS-Federation solves a similar problem to SAML (Security Assertion Markup Language) 2.0, but is composable with other WS* protocols - for example those related to reliable messaging and transactions. Thus, when you look to incorporate enterprise level federation into your solution, you'll have to pay attention to which protocols are implemented by the participants in your domain. Products like PingFederate and PingTrust support both SAML 2.0 and WS-Federation; Liberty Alliance supports SAML 2.0; and ADFS and Windows Live ID support only WS-Federation.
The public draft of WS-Federation has recently been accepted as input to the OASIS WSFED Technical Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsfed. Under this committee, SAML 2.0 and WS-Federation standards hope to converge.
Reliable Messaging Protocols
Reliable messaging protocols are designed to improve application reliability in the following manner:
- Messages can be guaranteed to be delivered exactly once and in order, withstanding transient hiccups in network connectivity.
- These delivery assurances are not tied to a particular protocol, thus reliability is possible for HTTP protocol, for example.
- End-to-end reliability is supported so that message delivery is reliable over multiple hops.
- Reliability is based on the entire SOAP message, not just on individual IP packets.
Figure 3 illustrates a high level view of how reliable messaging can work across platforms. The idea is that platforms at both the client (initiator) and service (receiver) keep a buffer for outgoing and incoming messages, and for the duration of the "reliable session" await acknowledgements of message receipts before removing the message from the buffer. Messages that are not acknowledged within some configurable timeout are resent for some configurable number of retries...to help overcome intermittent hiccups in network connectivity.
Figure 3: A high level view of reliable messaging.
WS-Reliability: OASIS Standard, November 2004
WS-Reliability protocol was approved very early on by OASIS, before many other WS*. It describes how to achieve reliable messaging but without consideration for transactions, secure sessions, and other WS* protocols. Still, a few platforms do support this specification.
WS-ReliableMessaging: OASIS Standard, November 2004
WS-ReliableMessaging protocol has more industry backing than WS-Reliability, and does consider the WS* protocol stack. Many platforms implement this specification, despite the fact that it is not yet ratified. In fact, the WS-RX OASIS subcommittee (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-rx) is will work to have the two standards converge to reduce confusion.
Although message-based reliability is obviously desirable, given that platform support is still fairly new, for wide reach you'll want to expose services with and without support for WS-ReliableMessaging. In addition, like with secure sessions, reliable messaging implies a session that may require affinity to a particular server machine where the session is cached.
Transaction-Related Protocols
WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity are interoperable protocols that support distributed transactions across platform boundaries. The set of protocols were ratified as OASIS standards as of March 2007. WS-Coordination defines a protocol for registering participants in a coordination context, and passing that coordination context across boundaries. WS-AtomicTransaction and WS-BusinessActivity represent implementations of such a coordination context. WS-AtomicTransaction facilitates message-based two-phase commit (2PC) protocol, while WS-BusinessActivity facilitates long running transactions that may involve compensating transactions.
A handful of platforms already support WS-Coordination with WS-AtomicTransaction - making it possible to distribute transactions across platforms, over HTTP protocol and potentially through firewalls.
Today you are more likely to consider implementing services that support transactions when you own all of the participants in the transaction or have a strong trust relationship with all parties (platform aside). To allow your services to be enlisted in a transaction controlled by a lesser-known client puts your services at risk of participating in in-doubt transactions, and resource locking. Use careful thought before enabling transaction support in your web services exposed to the Internet.
These transactions protocols are listed under the OASIS Committee, WS-TX: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx.
Metadata Protocols
Without a way to describe the requirements of a web service - its operations, its message formats, and its support for WS* protocols - it would be impossible for platforms to provide the tooling necessary to increase developer productivity and improve overall consistency reliability of implementations. In fact, it is this tooling that really makes interoperability a realistic goal. WSDL makes this possible for application messaging without WS*. WS-Policy and WS-MetadataExchange add to WSDL in support of WS*.
WS-Policy: W3C Member Submission, April 2006.
WS-Policy describes extended protocol capabilities and requirements for a service, for WS* features such as MTOM, security, reliable messaging and transactions. In addition, WS-Policy describes how to include these policy assertions in the WSDL document either directly, or as an attachment as described in WS-PolicyAttachment. WS-Policy is to WS* what WSDL is to standard SOAP messaging.
The idea behind WS-Policy is that platforms will eventually expose WS-Policy assertions as part of WSDL to describe support for WS* features. Thus, a specific set of policy assertions must be agreed upon that will describe each feature. There are a few such examples already in existence:
- WS-SecurityPolicy: Describes token, message protection and other security features supported by a service, described in this document.
- WS-ReliableMessaging Policy: Describes WS-ReliableMessaging feature support for a service, described in this document.
- WS-AtomicTransaction Policy: Describes WS-AtomicTransaction feature support for a service, described in the WS-AtomicTransaction specification here.
WS-Policy is an extensible standard that allows for custom assertions to be created as well, if you were to define custom protocols for your services. The point is that WS-Policy is extensible, and can be used as the foundation for describing any and all WS* features that should be discoverable. Anything documented in WSDL, including policy assertions, can be leveraged to generate code and configuration for clients - thus improving developer productivity. Today, WS-Policy is not yet ratified, and there isn't wide support for WS-Policy among platforms. WCF does use this extensively to facilitate metadata exchange and proxy generation, and projects like Sun's Tango are have demonstrated interoperability with WS-Policy produced by WCF.
WS-MetadataExchange: Public Draft, August 2006
WS-MetadataExchange protocol supports discovery of WSDL documents, WS-Policy settings and message and type schema associated with a particular service. SvcUtil uses this protocol to generate WSDL documents from a service description. This makes it possible for tools to programmatically discover requirements to generate proxies and configuration, but it also facilitates requesting specific sections of the WSDL, including policy sections or operation details. This protocol is important to other WS* implementations such as those related to federated security, which sometimes requires dynamic discovery of the required credentials to log in to an STS, for example.
WS* Interoperability
From 1999 when SOAP was first introduced, to today, I think most could agree that the interoperability story between platforms doing "plain old SOAP" has come a long way. Generally speaking (that means "almost all of the time") compatibility exists because most of the common issues have been worked out regarding generating and interpreting WSDL consistently, and the interpretation of serialized types described by schema by XML parsers.
For each WS* protocol a similar evolution exists from early adoption and testing; to initial release; to vendor implementation; to implementation stability. While standards like MTOM, WS-Addressing and WS-Security have reached implementation stability for the most part, other more recent standards like WS-Trust, WS-ReliableMessaging, and WS-AtomicTransaction are still in relatively early phases of vendor implementation.
Wide adoption of this long list of standards will not be reached until the vendor implementations and tools are at the point where developers need not tweak the configuration or XML to achieve interoperability, but those who participate in the early adoption phase help to make this a reality through stabilization of real-world use cases. History has already proven that eventually, WS* tooling can work to the point where developers can produce services and generate client code without reading each 65-page specification to understand the XML behind the standards employed. It is a function of how badly you want or need to employ the WS* feature, as to whether you are willing to adopt standards before they are ratified, and in their early implementation.
In this article I focused on the WS* protocols that specifically enable distributed messaging across platform boundaries - addressing, large message support, security, reliable messaging, transactions, and metadata exchange among the more relevant. Hopefully this gives you an idea of the purpose for each of these standards, and a high-level perspective on their state of adoption.
Author
Michele Leroux Bustamante is Chief Architect of IDesign Inc., Microsoft Regional Director for San Diego, Microsoft MVP for Connected Systems and a BEA Technical Director. At IDesign Michele provides training, mentoring and high-end architecture consulting services focusing on Web services, scalable and secure architecture design for .NET, interoperability and globalization architecture. She is a member of the International .NET Speakers Association (INETA), a frequent conference presenter, conference chair for SD West, and is frequently published in several major technology journals. Michele is also on the board of directors for IASA (International Association of Software Architects), and a Program Advisor to UCSD Extension. Her latest book is Learning WCF (O'Reilly 2007) - see her book blog here. Reach her at mlb@idesign.net, or visit www.idesign.net and her main blog at www.dasblonde.net.