January 2004 - Posts
True, how true this is. E.g., I like that my car has an airbag and ABS.
Clemens has to fight the very same problems I and other colleagues are experiencing when trying not only to sell a vision, but to make clear to people and customers why they need the things we talk about and when ... lot of work still for us.
'Hard' times.
This week I had two talks at the .NET Day in Vienna (with Bill Gates giving the closing keynote). One was about J2EE and .NET interoperability and the second one was on some solutions to common problems with ASMX-based Web services.
Download the samples here - it is essentially an update of the samples showed at TechEd 2003 in Barcelona, to be honest.
The W3C posted an updated version of the Web Services Architecture document. In official W3C terms, it is an editors' copy that has no official standing.
This document defines the Web Services Architecture. It identifies the functional components and defines the relationships among those components to effect the desired properties of the overall architecture.
[...]
Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. This document (WSA) is intended to provide a common definition of a Web service, and define its place within a larger Web services framework to guide the community. The WSA provides a conceptual model and a context for understanding Web services and the relationships between the components of this model.
The architecture does not attempt to specify how Web services are implemented, and imposes no restriction on how Web services might be combined. The WSA describes both the minimal characteristics that are common to all Web services, and a number of characteristics that are needed by many, but not all, Web services.
The Web services architecture is an interoperability architecture: it identifies those global elements of the global Web services network that are required in order to ensure interoperability between Web services.
Casey Chesnut and John Bristowe - two Web services and WSE brothers in mind - have started some effort around implementing WS-Eventing for various .NET areas:
Cool.
From the Shadowfax team over at gotdotnet.com:
The latest build of Shadowfax is now available ! BUILD: 1-23-2004
It now includes not only the main the Service-oriented reference architecture piece, but also the new reference implementation application (Global Bank). We have also posted new documentation to support the application - and look forward to your feedback & comments online.
Jeff Schneider asked in one of the comments on my last post about "Oracle's new Web services Designer - good idea, but ..." what I mean by message contract. Sorry for not being clear enough on this. Let me give a try here.
Normally everybody only talks about the contract which is the service contract, the one and only, right? In the meantime I tend to see it from another angle. I guess we should start with a possible definition of what exactly is meant by the term contract.
Contracts define the complete interaction between services. In that sense, a contract is the 'business protocol' all involved services rely on. A service designer (human, in this case ;-)) defines all messages and their format, including possible message sequences for reflection in a contract. But a contract also defines protocols, authentication mechanisms and the like. Effectively, contracts allow service interfaces to communicate with each other.
Sounds good so far? Makes sense? Hm ...
With the above definition we are able to further seperate the global term contract into a message contract and a service contract. A message contract would hold all the required information about the message payload itself. In terms of a technology mapping into SOAP 1.x this means that a message contract would be materialized on the wire in the <SOAP:Body> element. Of course, in order to describe this contract we would then use WXS (W3C XML Schema) in order to set up the 'types' (well, these are not the types we are used to from classical OO - for more and deeper information and a superb explanation of that distinction read Steve Maine's MUST READ blog entry on this very topic, including Don's comment). But stop. When saying that a message contract describes how the message itself looks like on the wire we also need to consider describing the message function, not only the message content alone. This can be done by using WSDL.
In contrast, a service contract is a contract that describes what a service is capable of - in terms of "I can do this for you". It is more about describing the infrastructional means needed to communicate with the service which are independent of the message. Again, when mapping into SOAP we will see this information put into the <SOAP:Header>. Originally these requirements were all described in WSDL. E.g., if you leverage a mechanism to authenticate your users with every service call you do, then you put that data and information orthognal to your message into an appropriate section in your service's WSDL that describes the SOAP Headers. Does WSDL really support this? A lot of people think so ...
Isn't there a bit more to this story? By using WSDL you actually cannot express a service's wishes. It is solely a means for describing a syntax. A communication partner cannot know without further knowledge what is meant by the SOAP Header element to use. But doesn't a service not only have to say "I can do this" and express the syntax of the elements that have to carry that information, but also it needs to be able to say "Hey, I really prefer if you would send me this" and even "C'mon - no! I really want you to send this or that!"? Yep. And this is where the whole policy thing comes into play. Policy and the related WS-Policy specs enable a service designer (or even an administrator) to describe policy assertions like capabilities, preferences, and requirements. And it seems like the responsibilities get mixed (WSDL vs. policy) ... Well, here we go.
Now I am in a dilemma ... the whole thing with WSE, e.g., is that the message contract is described via WXS and WSDL, OK. And the service contract is solely described via the appropriate policy descriptions. Now, is there a missing link? Or put another way: is WSDL responsible for describing the whole <SOAP:Envelope> on the wire? I think this was the original idea behind it (the other day). But with the advent of policy this has changed dramatically. This leads very quickly to the never ending story (at least for me) about "runtime" vs. "design time" contracts. What is needed at design time and was not?
Suppose you provide me a WSDL. I take that WSDL and put it into my 'engine'. Perfect. Then I write an application to call your service. Kawoom! Error and exceptions all over. Why? Because there is a security constraint on your service that tells a consumer to digitally sign the messages sent to the service. OK, I did not know that! ... So a viable solution is to send the WSDL and the policy information to me in order to use it. Well ... and here we go again: then I really need both at design time for my service client, don't I?
Maybe the explanation to all of this is just as easy as: hey, don't worry about it. You really only need the appropriate runtime to handle this for you. Hm ... see my side note below.
Comments?
Side note: yes, there is a missing piece in the WSA story pending: WS-MetaDataExchange. It is not yet here (although the current build of Indigo is using it extensively; just sniff), so let's talk about the status quo.
The wonderful Douglas Purdy just published a snippet of his schema versioning solution. But this is just a sneak preview - nothing real for now. Expect more to come ...
Rather that a long entry, I think I am going to tease everyone before I show the final story (although you should bear in mind that there never is a final story at Microsoft -- we are always re-examining things and looking for ways to reduce the enviable downsides to any solution).
Has anybody already seen the Web services Designer in Oracle's latest edition of JDeveloper? They call it 10g ...
Well, there is an online demo of its features which looks quite pretty and interesting - at the first sight. But then they still take exclusively (as far as I can tell from the demo video) the OO-only approach to designing Web services by leveraging UML diagrams as the base. And it should be obvious by now that I really have slight problems in the meantime with this way of doing it. We need to reflect the need for modling messages, message contracts, and services contracts.
Side note: they are generating RPC-style Web services by default. At least in this demo. :-(
Alas, good idea Oracle - but please add a schema and contract-based design feature to it. Then they will love you!
Aaron Skonnard of MSDN Magazine XML Files column fame blogs [RSS]. Welcome.
More Posts
Next page »