RE: [ebxml-dev] Gartner and ebXML

["Vinoski, Stephen" <steve.vinoski@iona.com>]

Mike, great response. My comments are embedded below.

Michael Rawlins writes: 
> Steve,
> 
> Thanks for your consideration.   Your message implies that 
> you are part of 
> the W3C  Web Services Architecture Working Group,

Sort of. I was fairly active in the very beginning of the WSAWG, and in fact I proposed one of the first definitions that WSAWG considered for what a Web Service is, but my participation has dropped off over the past few months as I personally don't have the time (or the patience) for extensive work on standards. Our CTO, Eric Newcomer, has taken over the role of primary IONA WSAWG representative, and I serve as the alternate.

> and I 
> appreciate your 
> concern in getting comments from an outsider.  You confirm my 
> assessment 
> that this loose definition is the best that could be worked out in 
> consensus by a committee.  I'll answer your specific points in line.

Your phrase "consensus by committee" hits the nail on the head in this context IMO.

> At 01:50 AM 9/12/02 -0400, Vinoski, Stephen wrote:
> >Your criticism that some services are available only via IP 
> address and 
> >port and not via a URL is odd. Are you saying that no 
> protocol whatsoever 
> >is used to access such services? Giving you the benefit of 
> the doubt and 
> >assuming not, then you can write a URL in the following form 
> to access any 
> >such service: protocol://address:port/.
> 
> Forgive me for being a bit too general in this statement.  
> Sure, you need a 
> protocol and yes, anyone can write a URL to define a 
> protocol, address, and 
> port.  But, that's not the point of the debate as I 
> understand it.  Let me 
> give you a more concrete example.  For example I can direct all of my 
> procurement/payment related messages to the same address:port 
> over secure 
> http.  There are different business applications that handle order 
> acknowledgement and invoices, yet the messages (in a SOAP based ebXML 
> envelope) for both go to the same address and port.   The 
> argument goes 
> that for these two applications to be fully specific as web 
> services, they 
> have to have unique URLs. Therefore, they don't qualify as web 
> services.

There's been a huge debate about whether such things are Web Services or not in the W3C, and I don't really know whether it's ever been resolved. A lot of Web Services developers and toolkits today work on the principle that you direct all traffic to a particular address/port/URL and disambiguate the precise service being addresses by including extra information in the packet itself. This is what SOAPAction has been used for. However, there are definitely people who think this model is broken. Scan through the W3C archives at <http://lists.w3.org/Archives/Public/xml-dist-app/> for more info, for example. This issue is also part of a huge on-going debate about REST (see <http://internet.conveyor.com/RESTwiki/moin.cgi/>) and whether Web Services respect the existing Web architecture.

> In this model the message handling system 
> described the URL is 
> the web service.  On the other hand, the other model says 
> that because the 
> business applications expose their interfaces through the messaging 
> service, and that all of the other necessary details are 
> defined in their 
> ebXML CPA, that they qualify as web services.  That model leaves the 
> messaging service in a somewhat ambiguous status.  Is it a 
> service, too, or 
> is it just plumbing?   My point is that the W3C definition seems to 
> accommodate both models.  I think that borders on making it 
> too general to 
> be of much practical use.

I can understand your point. I suppose many would say that both should be accommodated because in the end they both support service advertising and accessibility.

> >If you have services accessible via Kermit running over 
> telnet -- your 
> >example, not mine -- why would they not be valid web 
> services? Are you 
> >implying that Web Services are accessible only via SOAP over HTTP?
> 
> No, I am carrying the open, unspecific nature of the definition to an 
> absurd extreme.  I think you would be laughed at if you told 
> the average IT 
> professional on the street that Kermit running over telnet 
> qualified as a 
> web service.

Well, the fear of being laughed at is why I made it clear that it was your example, not mine. ;-) Seriously, many feel that Web Services should not be limited to only SOAP over HTTP, and that acceptance of other solutions as well requires that we not judge the value of service only on the transports and protocols over which it's accessible. Though this explanation seems to contain a heavy dose of political correctness, it's got a good point to it, in that there's no such thing as a "one size fits all" solution. The Web itself supports more than just http, for example.

> >UDDI is not necessary for Web Services. UDDI is just one of many 
> >mechanisms for discovery. A sender merely needs a way to 
> discover how to 
> >contact the receiver. It could do this for example by 
> prompting for a URI 
> >if it had to -- no UDDI needed.
> 
> Fine by me.  But you have to acknowledge that there is a 
> popular viewpoint 
> that defines web services as a combination of at least XML, SOAP, and 
> UDDI.  Some people also include WSDL as a necessary part of 
> the mix.  Yes, 
> I know, you are trying to define an architecture and not talk 
> in terms of 
> specific implementation technologies.

Precisely. I'm quite aware of the popular viewpoint, but given that I've been working on real-world distributed systems for about the past 13 years, I tend not to pay much attention to how InfoWorld happens to define them this month.

> >I'm a firm believer that criticism should always be accompanied by 
> >proposals for improvement. Please share with us your 
> definition of web 
> >services, and explain why your definition is better than 
> what the W3C is 
> >currently using.
> 
> No offense intended, but my definition of web services is that it is 
> primarily a marketing concept and not an architecture.

No offense taken. In fact, I might agree with you. (Unlike many in our industry, I'm not a rabid religious fanatic when it comes to such things.)

> As 
> such it can be 
> pretty much whatever serves the interests of someone trying 
> to sell technology.

Yes, unfortunately, you are correct in this regard. There's been way too much hype and way too little progress on clarification. I personally feel there are some big vendors out there who are intentionally muddying the waters in the standards efforts so as to keep Web Services developments from wiping out their existing cash cows. Or maybe I'm just paranoid.

> That said, I do have respect for people trying to do serious 
> architecture 
> using various IP based protocols and XML based languages for 
> messaging.  I 
> just think that the term "web services" has become so 
> polluted that its 
> going to be even harder to make sense of than client-server 
> was in the 
> 80s.  My preference would be to do away with the term for any 
> serious work, 
> but of course I don't expect that to happen.

Agreed. In one of my recent "Toward Integration" columns that I write for the IEEE Internet Computing magazine, I commented that "Web Services" was not an accurate name, and that a more realistic name would be "Internet Services," which would never fly because it's not as marketable.

> Your W3C group does have a serious challenge in trying to define an 
> architecture for what started out as a rather nebulous 
> concept, and in 
> trying to define it in true architectural terms without talking about 
> specific implementation technologies.   As such, I appreciate the 
> difficulty in coming up with a good, consensus definition.  I 
> would put on 
> my thinking cap and try to come up with something better, but 
> I really 
> don't have much interest in this concept at the very high, 
> general level at 
> which you seem to be working.

Well, given that I don't participate in the WSAWG myself anymore, I can't fault you for that!

> I do have one specific suggestion though.  The blurb about 
> "capable of 
> being defined, described, and discovered by XML artifacts" 
> could really use 
> some work.  XML artifacts don't discover anything.  People 
> and applications 
> working on their behalf, perhaps *using* XML artifacts, discover 
> things.  XML artifacts don't do anything, they just sit there 
> or get moved 
> around by something else.  Perhaps what is really intended here is 
> something along the lines of changing:
> 
> "interfaces and binding are capable of being defined, described and 
> discovered by XML artifacts"
> 
> to
> 
> "interfaces and binding are defined and described by XML documents"
> 
> This, I think, is really all that needs to be said.  If you 
> water it down 
> with "capable of", then you're really not saying much of 
> anything.   You 
> could get stricter and say something like:
> 
> "interfaces and binding are defined and described by 
> documents that are 
> compliant with XML based standard languages"
> 
> That implies that the interfaces and bindings are described 
> by something 
> like WSDL (or ebXML CPA), but without naming the specific 
> technology.  But, 
> I expect that there will be folks who object to that 
> stringent a definition.
> 
> In either case, you don't really have to say anything about the 
> application's interfaces and bindings *being* discovered.  
> The capability 
> to be discovered is implied by the application's interfaces 
> and bindings 
> being described by a standard XML based language.
> 
> Thanks for your interest - I hope this helps.

Yes, your suggestion is indeed a good one. I never liked that part of that definition either, for many of the same reasons you mention. However, I don't know if suggestions for improvements like these will ever be adopted, because last I knew nobody wanted to reopen the discussion and risk having to spend months in committee writing a whole new definition from scratch. However, given that I haven't been attending any WSAWG meetings lately, I could very well be wrong, and maybe this has been improved.

--steve

Steve Vinoski
Chief Architect, VP Platform Technologies, IONA Fellow 	
IONA Technologies
<http://www.iona.com/hyplan/vinoski/>