.NET

Dec. 3, 2010, 6:02 a.m.
posted by angryuser

Web Service Policy



Web Service Policy

An idea closely related to what WSDL provides with the <binding> section and the extension elements is Web service policy. In short, a Web service client needs much more information than merely what is found by default in a WSDL; that is, the client needs more information than the transport and protocol. This information can change even at runtime! Other pieces will be known at design time, but for reasons of factoring may not be included in the WSDL document.

For example, a vertical industry body (say, Car Makers of Oregon) may create a WSDL document that defines the industry-wide service definition for business-to-business and other interoperation. Each instance of this service may have its own specific security requirements that the industry body chose not to define, because of feelings that doing so would be overly demanding and restrictive.

There isn't a way to factor a WSDL to allow this kind of thing. Each service could define its own WSDL that looked very much like the industry WSDL, but that would be a hacky way of doing this. Instead, it makes a lot of sense to allow clients to query each specific service instance for their policy information, such as credentials and encryption needs.

This kind of metadata is also useful for policy items other than security information. For example, it could determine the routing path as reflected in WS-Referral, or it could even determine which transport to use.

The WSDL First! Movement

The WSDL First! movement is about changing the way people build Web services. We have amazing tool support today for writing a service as if it were an object that is to be remoted, and then automatically generating a WSDL document that defines the methods exposed, and the types those methods need.

However, this generation of WSDL is a bold lie. It's a lie to say to developers, "We are exposing your object," when in fact we are exposing a message-receiving port. It's a lie to say that a type is a struct when in fact it is a complexType as defined in schema.

WSDL defines types in terms of XML Schema, but the CLR type system is not a one-to-one match with XML Schema. Worse, WSDL defines a loosely coupled messaging interface, not the tightly coupled object-oriented system found in COM, the CLR, and Java.

The WSDL First! movement attempts to address this dichotomy by saying that developers of distributed systems should not think in terms of remoting objects, but instead should think in terms of messages passed to ports. Now, we can give developers awesome support for handling these messages and sending them.

What WSDL Does

WSDL forces a clean separation between data (as found in messages), the abstract definition of a set of message-sending operations, and the particular binding information needed to format and send a message correctly. This, in fact, is what is happening with any interoperable system. When a J2EE system sends a message to a .NET system, it's sending a message as defined in WSDL to a port exposed by .NET. The programming model of these systems makes it seem as though an object's methods are being exposed, but that is not the case.

Simply put:

  • Expose ports that listen for messages with the appropiate technology.

  • These messages are built from XML Schema defined types.

WSDL First! makes this reality obvious to service developers. With this reality in mind, as opposed to slick but false models, developers can create more robust and complete systems.

Tool Support

WSDL First! doesn't mean using the actual angle brackets and QNames that WSDL writing requires. Instead, it means using tools that help you to build WSDL files. It means using tools that help developers visually and textually model their services, and then generating the WSDL from that modeling, as opposed to generating the WSDL from the implementation. Of course, it's also possible to generate skeleton code from this modeling process.

Here is the key distinction: WSDL First! means thinking about the abstract wire format, not letting implementation dictate that format. WSDL as the actual document format is something that can be hidden from developers. It's the idea that counts. Great tools can make it happen.

The Competitive Advantage

When service developers and Web service tools vendors can execute on the WSDL First! movement with better tools and better overall support for the developer experience outlined above, then we'll have a key winning advantage against competitors.

If you stick to imagining WSDL as "just some weird XML document" that describes implementation details, then you will basically reengineer DCOM and CORBA into XML without gaining any new advantage for the distributed applications developer. Worse, your competitors will seize this chance to define this world, and steal customers with a superior development model.

     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows