Ted Neward explains his opinion regarding the current state of web services tools. This is the same topic that we covered a couple months back.
In general, it's good that we're seeing more and more agreement that directly exposing objects as web services is a less than stellar idea. I've written several articles about this in the past (e.g., this article and this article). As I've also mentioned before, it's deja vu all over again. A decade ago, people were trying to expose programming language objects directly as CORBA objects. Same basic idea, and just as wrong then with respect to CORBA as it is now with respect to Web Services.
On the minus side, in my experience, preaching about the correct way to do things back then wasn't 100% effective, and so I don't hold much hope for preaching about it these days either. The problem is that, as a toolkit provider like IONA, you can tell people until you're blue in the face that they shouldn't directly expose their objects as web services, and many of them will nod at you and tell you they agree with you, and then they'll turn around and demand that you provide tools to let them do just that!
On the plus side, in some cases, such a direct export is OK. If someone's done a reasonable job of abstracting a CORBA system, for example, then exposing it as a web service or set of web services can work just fine. I've seen several customers with such systems.
Since the customer is always right, if customers want a way to expose their objects directly as web services, that's what we give them. I'd say that's how a lot of toolkit vendors and suppliers feel. While providing such capabilities enables the customers who've already properly abstracted their underlying systems and objects to do what they want to do, it also enables those who don't understand the issues to do the things they shouldn't. There's no easy way around this. As long as toolkits and standards continue to target the development of web services in languages like Java, C++, and C#, this problem will continue to exist, due to the general mismatch of the abstractions involved.
Comments (5)
Tarak Modi talks about this as well in a posting about "Service-Oriented Architecture" in his Java Design blog at JavaWorld. The direct link is:
http://www.javaworld.com/weblogs/javadesign/archives/000130.html
Posted by Anonymous | June 17, 2004 10:43 AM
Posted on June 17, 2004 10:43
"As long as toolkits and standards continue to target the development of web services in languages like Java, C++, and C#, this problem will continue to exist, due to the general mismatch of the abstractions involved."
I agree. To push further, I think services should be made of low-level objects combined using an XML-oriented language (Ex. Xen, Xtatic, where XML types are used seriously). My company, Brixlogic, provides just that, and it's easy to use (visual).
What do you think?
Posted by Guillaume Lebleu | June 17, 2004 4:45 PM
Posted on June 17, 2004 16:45
In CORBA, I would typically get an object reference from the naming service and invoke some method on that specific object, right? However, and I may be naive here, with web services I thought I could invoke via XML description. For example I can present an XML document with a customer description and "processOrder" invocation to a registry broker and have the broker delegate the call to a service that satisfies the schema supporting the document. If you think about it, there is a very big difference there.
Posted by tester | June 18, 2004 2:39 PM
Posted on June 18, 2004 14:39
Some people (I'm not implying you're one of them, BTW) like to try to make this issue a black-and-white argument, but unfortunately for them it's gray in practice, and sweeping statements don't necessarily apply.
Yes, you could do a "processOrder" document-oriented request with web services, and that approach would differ from the typical way a number of CORBA services are designed. However, there are also numerous CORBA services that work just like your "processOrder" call. There are also services that are inherently synchronous, for example, validating someone's credit card for a particular charge, for which the straightforward CORBA approach works just fine.
What this means is that many existing CORBA objects/services are capable of being abstracted as web services -- which is what we're seeing with our customer base -- but that doesn't imply that *all* CORBA objects are suitable for treatment as web services. Any mapping from one technology to another is imperfect, and some things simply won't map.
You might want to read the following, which I wrote about three years ago, for more info:
http://www.cuj.com/documents/s=7990/cujcexp1910vinoski/
Posted by Steve Vinoski | June 19, 2004 12:30 PM
Posted on June 19, 2004 12:30
I tried to use COBRA, but I didn't manage to customize this application.
Well, the concept of web services is rather good, but still it has a lot of obstacles on its way for progress.
Helen
Posted by Helen | July 24, 2004 1:44 PM
Posted on July 24, 2004 13:44