Back in 2004 Microsoft encouraged distributed developers to base their work on ASP.NET Web Services (ASMX) architecture rather than .NET Remoting. From that moment I knew that .NET Remoting was moribund and should not be pursued for new development.
Some folks however preferred Remoting because it did not have the IIS overhead that ASMX did. I would say that unless not having IIS was a requirement, they were mistaken.
Clemens Vasters summarizes a Microsoft whitepaper that compares performance between the different MS technologies. The results? WCF is
- %25 - %50 faster than ASMX
- %25 faster than .NET Remoting
- %100 faster - %25 slower than .NET Enterprise Services (DCOM)
Those are impressive numbers. Unfortunately for the Remoting folks, there is an easy upgrade from ASMX but no upgrade from .NET Remoting.
Go WCF my friend!
In WS-Addressing, End Point References include the concept of Reference Properties and Reference Parameters. If I read Omri Gazitt's explanation of the difference between the two it seems to make sense. However, I then read Clemens Vasters post and get thoroughly confused. Can anyone decipher?
Dave Orchard has more explanations.
Hervey says the WSE team is working on three things:
- WS-I BP and Security Profile compliance tools
- WSE2 SP2 with updated Kerberos token and ... something else.
- WSE3 planning. There hoping for more regular drops this time 'round.
By the way, this leads me to question the conclusion of my last post. If they were able to deliver from an unfinished Kerberos spec, why couldn't they do SAML?
Another side note, a commenter on Hervey's post asks for properties rather than fields from generated proxies in WseWsdl2.exe.
Please note that you will get the desired behavior in the VS2005 Wsdl.exe. [See Yasser Shohoud post.)
According to Benjamin Mitchell's post from a TechEd Don Box Service Orientation presentation, we don't know when or if SAML will be directly supported:
WS-Security vs. SAML?
There are many different kinds of tokens that may be used, such as Username, X509 certificates and Kerberos tokens. Don said it was unlikely that a token type, like SAML will become the 'single token format to rule them all'. No definite answer on where the SAML support was. As I learnt on Saturday, trying to implement SAML support is a non-trivial exercise - it would be nice if there was a clear statement from Microsoft on when it will be supported in the platform (so that you don't have to share my dll in order for us to use it when we talk). I think it will be part of the identity management work in future.
Michele Leroux Bustamante's very philosophical post on the same talk elucidates the "Saturday" comment: She and Benjamin wrote a sample SAML implementation, So Benjamin ought to know.
Here's his post before the presentation.
Steve Mane has an excellent post comparing three strategies for user authentication and authorization. The three scenarios are:
- Client Managed
- Service Managed
- 3rd Party (Federated) Security
Each of these scenarios is compared against authentication and role-based authorization. His conclusion?
WSE2 is a big step forward in term of secure web services, but it’s not the endgame just yet. There’s a lot that can be done with WSE2 out of the box directly. Integrating with Windows domain authentication is a big step; it solves one part of the role-based security puzzle. If all your services can talk to the same NT credential store, you can auto-issue SCT’s to your heart’s content and at least have what I describe as “Option B” taken care of (with the added benefit of having a unified cross-service credential store). It’s not the general-case, interoperable solution that pan-enterprise web services need to succeed, but it’s a step in the right direction. The real solution lies in federating identities, and that’s something for which we’ll just have to wait.
He links to a post I just found recently that I want to blog more on later: the time-line for SAML, Liberty Alliance, and WS-Federation. I just wish it were yesterday!
Omri posts that Hervey and boys were busy while he was away at Eilat. WSE 2, including the latest updates to secure conversation and trust specs, should get it's first cut this week. This is really good news. One wonders if they get more work done when he's not there. :-) He's giving a sob story about how he missed work. I'm sure everyone's feeling real sorry for him...
Go boys!
In a recent post, Hervey Wilson explains how the WSE 2.0 team is enabling side-by-side execution of WSE 1.0 and WSE 2.0. One fallout is that the WSE 2.0 assembly is now Microsoft.Web.Services2. Importantly, the namespace is changed as well. Hello global-search-and-replace. If Microsoft plans to do this kind of thing often they should add a namespace rename refactoring feature to thier Whidbey VS.NET product.
Even if your not interested in WSE 2.0, this is a good primer on how to enable side-by-side execution in your own libraries. It would be nice if Microsoft could work up some guidelines on making libraries side-by-side ready.
Requirements
I have been developing a strategy for developing a forward-looking remote communications architecture built with current tools with a view toward emerging technologies and Indigo compatibility. My client is an ISV that sells a packaged product. Their architecture has these requirements:
- Scalable from one to three (N) physical tiers
- Support a client tier across the Internet
- Provides secure communications
- Supports multiple authentication schemes. Password, LDAP, and Windows must be supported.
- Supports custom authorization schemes
- Ensures reliable communications in LAN, WAN, and Internet environments
- Works in a symmetric server farm environment
- Supports automated deployment
- Supports heterogeneous clients (.NET/Java/etc.)
- Maintains session state
- Provides a migration path to the MessageBus (Indigo) architecture
Options
I see four options for implementing the communications architecture.
- WebMethod wrappers. The WSE 2.0 enhanced ASMX WebMethods call Core methods that provide the business functionality.
- WSE 2.0. Using the Web Services Enhancements 2.0 with ASMX.
- ASMX only. The ASP.NET Web Services architecture
- Remoting. The .NET Remoting architecture. It is implied that the remotable classes would be called directly in a single tier deployment.
Analysis
I feel that the WSE 2.0 option provides the best balance of features for the requirements. Below I list the advantages and disadvantages that the WSE 2.0 solution provides and some notes about the alternatives.
General
Advantages
Disadvantages
Alternatives
- WebMethod wrappers
- Must create two functions for every business service activity increasing development, testing and maintenance costs (+)
- ASMX only
- Has longer support cycle (+)
- Must define your own protocols for security, addressing, policy, and reliability (-)
- Remoting
- Must define your own protocols for security, addressing, policy, and reliability (-)
- Cannot interoperate with external systems (-)
- Microsoft discourages use of .NET Remoting except for cross-Application Domain uses (-)
Scalability
Advantages
Disadvantages
- Requires IIS or other web server in single tier installation. Some users may not wish to install IIS
- Requires IPC on single tier installation, which is slower
Alternatives
- WebMethod wrappers
- No marshaling in single tier deployment (+)
- Yields multiple exception propagation strategies, and yields multiple execution paths to test, and multiple configurations to deploy (-)
- Business Service code must execute under the credentials of the logged in user in a single tier deployment (-)
- ASMX only
- Not compatible with WS-Addressing (-)
- Remoting
- Don’t need to marshal exception information through SoapException (+)
- Business Service code must execute under the credentials of the logged in user in a single tier deployment (-)
- Does not support non-.NET clients (-)
Security
Advantages
- Complete. Provides authentication, authorization, integrity, non-repudiation, and encryption
- Emerging standards supported. WS-Security, WS-Trust, WS-SecureConversation, WS-SecurityPolicy
- Supports multiple credentials. Password, hashed password, Kerberos (For Windows authentication support), and x509 supported
- Application server code can run with permissions that do not need to be conferred to user, even in single tier deployment
- Heterogeneous clients gain access using the WS-Security standards. IBM’s WSTK and ETTK products provide this support for Java
Alternatives
- WebMethod wrappers
- Don’t need to marshal exception information through SoapException on standalone deployments (+)
- Can support additional, custom authentication schemes that share Core business methods (+)
- ASMX only
- Can use SSL for encryption (+)
- Can use integrated security features of IIS for Windows authentication (+)
- Must define your own password-protection scheme (-)
- Must define your own security/session tokens (-)
- Must define your own protocols for policy, addressing, and reliability (-)
- Remoting
- Must define your own protocols for password protection, policy, addressing, security, session management and reliability (-)
Where Are We?
There is some rework involved in moving to Indigo when it is delivered. However, a WSE 2.0 solution will provide the least change in terms of the contract, the architectural design. This means that other solutions will have to change structurally and, therefore, may affect the code base more than the changes necessary to move from WSE 2.0 to Indigo. Given this strong mitigating factor, I find WSE 2.0 provides the best solution for meeting the architectural requirements. How WSE 2.0 specifically addresses each requirement is summarized below.
Scalable from one to three (N) physical tiers
The extensible WS-SecureCommunications features in WSE 2.0 provides support for symmetric web farm scaling. The WS-Addressing support eases the transition to more complex topologies in the future, including SMTP and MQ-Series gateways. Using ASP.NET Web Services even on standalone systems reduces the testing and maintenance costs of supporting two logical stacks.
Supports a client tier across the Internet
The SOAP 1.2 support in WSE 2.0 operates inherently over standard Internet protocols; it specifically supports HTTP. The stateless nature of web services is compatible with the chunky communications necessary for Internet communications. Asynchronous communications strategies must be developed to maintain contact on long-running operations; however, this is a limitation of the HTTP protocol, not a specific communications strategy.
Provides secure communications
Whereas ASP.NET Web Services relies on windows integrated security or SSL to provide secure communications, WSE 2.0 and WS-Security provide a transport independent secure connection. Moreover, using SSL is a time consuming, error-prone, and costly process that requires the customer to acquire and install on the server an x509 certificate purchased from a certificate authority. The WS-SecureConversation support in WSE 2.0 eliminates this requirement. WS-SecureConversation provides a secure communications channel that can be bootstrapped from both hashed passwords and Kerberos making x509 certificates unnecessary and providing secure communications to external systems that may not have SSL support.
Supports multiple authentication schemes. Password, LDAP, and Windows must be supported
As discussed in the previous section WSE 2.0 provides support for multiple authentication schemes out of the box and is extensible. Because LDAP support requires clear text passwords be passed from the client to the server, SSL, shared-secret encryption, or client-side certificates need to be used to support this feature. Although LDAP integration is not specifically provided with WSE, the .NET Framework provides the classes in the System.DirectoryServcies to provide LDAP integration. Only WSE 2.0 provides an extensibility mechanism to incorporate custom authentication schemes.
Provides custom authorization scheme
Although the WSE 2.0 architecture defaults to integrated Windows security, the system provides an extensibility mechanism reminiscent of ASP.NET Forms authentication to allow custom authentication and authorization. Several examples are provided to explain how to perform custom authorization.
Ensures reliable communications in LAN, WAN, and Internet environments
None of the solutions provides reliable communications. That will have to wait until Indigo. There are two options to ensure reliable communications under the current architecture. The first is to design our own reliability protocol. The second is to implement the WS-ReliableMessaging protocol. Because WS-ReliableMessaging will be integral to the MessageBus (Indigo) architecture, I recommend the latter. Regardless, communications that require reliability, financial transactions, for example, must use established reliable messaging patterns, such as idempotence and stability, to succeed.
Works in a symmetric server farm environment
Any of the communications architecture options can support a application server farm environment as long as session state is shared across the nodes. Typically this is accomplished through a shared database. None of the solutions explicitly provide shared session state. However, WSE 2.0 does provide a session token that can hold some session state and, more importantly, can be used as a key to session information. The other solutions require a custom solution.
Supports automated deployment
Aside from the manual configuration of Web Server certificates, each of the communications options can be configured programmatically.
Supports heterogeneous clients (.NET/Java/etc.)
There are many platforms that can interoperate on HTTP+SOAP and WSDL, so both the ASMX only and the WSE 2.0 solutions interoperate. However WSE 2.0 support a much broader range of clients due to its support of WS-SecureConversation and WS-Addressing. In this area, .NET Remoting fails completely, since Remoting requires that the same .NET Type be present on both sides of the wire.
Maintains session state
None of the solutions maintain server-side session state. However, WSE 2.0 incorporates the maintenance of a secured session token that is used between the client and the server. This token can contain session information. In addition the token can be used as a key by the service to maintain session state.
Provides a migration path to the MessageBus (Indigo) architecture
Microsoft has promised plug-compatibility between ASP.NET Web Services, Remoting and Indigo. Then, why not go with these solutions? First, this compatibility is only guaranteed if you have not used any of the extensibility features of the technologies. For Remoting, using such an extensibility mechanism is required to add security features. Secondly, Indigo and WSE 2.0 have built-in security protocols that do not exist in either of the older technologies. Although the code could remain compatible when executed on the Indigo platform, because the actual interface must change when using the new standards, the code base will have to be written anyhow. Using WSE 2.0, one does not need to change the contract, the protocols or the interfaces used.
Recommendation
Given this analysis, I recommend that WSE 2.0 be adopted. The current Technical Preview provides a sufficient development environment until the final product ships in the second quarter. Because change is inevitable, both to WSE 2.0 RTM and to Indigo, I recommend that interaction with WSE 2.0 be encapsulated by shared methods that can be updated when new functionality when releases are available. The Technical Preview has proven to be relatively stable, as