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 judged by the lack of issues in the WSE newsgroup. As a technology, WSE 2.0 is already receiving a lot of support. A feature-rich and solid Technical Preview was released in October 2003 and a public newsgroup is available. Microsoft has published a book on the technology and DevelopMentor has developed coursework. Also, Microsoft has been keeping us up to date with the project’s progress.
Resources
Web Services Enhancements (WSE) Homepage
http://msdn.microsoft.com/webservices/building/wse/default.aspx
WSE Newsgroup
http://msdn.microsoft.com/newsgroups/default.aspx?so=1&pg=1&dg=microsoft.public.dotnet.framework.webservices.enhancements
WSE Team Weblogs
Hervey Wilson, Development Lead
http://www.dynamic-cast.com/
Rebecca Dias, Product Manager
http://blogs.msdn.com/rdias
Omri Gazitt, Program Manager
http://www.gazitt.com/OhmBlog/
Community Weblogs
John Bristowe, MVP
http://www.bristowe.com/blog/
Christian Weyer, MVP
http://weblogs.asp.net/cweyer/
Understanding Web Services Specifications and the WSE, Microsoft Press
http://www.microsoft.com/mspress/books/companion/6708.asp
Essential WSA: Programming Web Services with WSE, DevelopMentor
http://www.develop.com/training/course.aspx?id=185
In Karsten Januszewski's response to my analysis of Pat Helland's Software Oriented Enterprise presentation on web service reliability, he mentioned that my analysis was reminiscent of Eric Schmidt's 2001 article on designing reliable communications. It's good that I've caught up to three years ago! Well, if Johnny's come lately, hopefully he's not coming slowly. I've been doing my homework on the veritable flood of information on the new web services standards and hope to post some useful tidbits of what I've found.
What's obvious is that critical mass has been building on the web services specifications that Microsoft and IBM are spearheading. Although the specifications are many, they are designed to be composable and well-factored. I sense from the participants, a momentum toward a whole that is larger than the sum of the parts. The recent The .NET Show episode with John Shewchuk showed to me a belief among the participant of the Web Services standardization effort that we are being ushered into a new era of interoperation and, with it, productivity increases. Hopefully it's enough to offset the jobs lost to outsourcing.