James Gosling hits out at SOAP stating "SOAP is an overhyped rehash of RPC that will evolve into a semichaotic system of integrated services"

The article can be found at:
http://www.infoworld.com/articles/hn/xml/01/10/29/011029hngoslingtalk.xml

What? Web Services are not the answer to every problem in computing?

And about time too that some one 'official' says that web services are not about exposing a bean as a WSDL service.

The current web service offerings from vendors are just the tip of the ice-berg as far as what we'll end up with. Vendors like SilverStream with their up and coming software stack seem to have been the first vendor to come out and say what it'll be like. The serverside also ran my service broker article which was also an early attempt (beginning of this year) to characterise what is to come from all the main vendors in 2002 and onwards.

It's an integration technology for defining services that can be composed from existing applications whether they be J2EE, .Net or Legacy applications. Composite services are equally supported where a new service is defined using existing services combined using flow technology. These composite services should allow services implemented using different platforms to be assembled in to a new service. These services in turn could be exposed using a variety of middlewares, COM, Corba, RMI, RMI/IIOP, JMS, SOAP etc.

Web Services DON'T suit J2EE more than .Net and vice versa. It's not about a specific technology platform, it's about integration. The next time you see an 'expert' try to say J2EE is 'better' than .Net for Web Services then just switch off, they don't get it. It's absolutely not about legacy platforms whether that is J2EE or .Net

Which platform is better for building/assembling 'web' services is largely a function of the available tooling rather than the platform it-self plus how many protocols it can expose it's deployed services using.

The web in 'web services' doesn't refer to the internet, it refers to the cob web of applications/services lying around companies or their partners that need to be integrated together to provide better value or more integrated services layered on top with this new form of middleware, the service broker.

It has as much, if not more, to do with companies integrating internal applications for creating an e-application or building a portal on top of as with the internet or B2B type integration.

Billy

<quote>It's an integration technology for defining services that can be composed from existing applications whether they be J2EE, .Net or Legacy applications.</quote>

True, that's how web services are being sold today. However, it is easier said than done. I would like to compare this notion of "integration technology" to the "glue technology" or middleware to which we attributed the same set of benefits. Rewind the film to early 1990s, where vendors/evangelists used to say - take CORBA/COM and some asynchrnous messaging - and there you have the greatest thing on the face of the earth to integrate all "enterprise assets lying around uncared for and unintegrated" and so on. Sorry for being sarcastic - that's not my point.

My point is that, integration is still (and will always be) difficult when we consider apps built with disperate technologies, programming models, architectures, etc. To hilight this point, consider a large legacy app that implements some complex business logic as a batch executed daily. Can we integrate such an app with a fancy-looking mobile phone that these vendors would love to demonstrate in conferences? No way - the problem is not with the glue (I include web services here), but with the nature of the app itself. It just can't be integrated - just because the architecture does not suit this kind of integration.

I would like to add something more. When first conceived (if I understand and interpret history correctly), CORBA was meant for integration - but most of the vendors/architects made it into a component technology, using which one can build distributed components. Then came J2EE, which was more explicit about it being a distributed component technology. So what was started as an integration technology became a component technology.

The same thing will happen (or has it happenned already?) to web services. We'll have tools and higher level component/object abstractions to build web services. Slowly, we'll talk about web services design patterns, and so on.

The reason I post this prediction is to hilight the point that web services is not a replacement for whatever existed before. It just complements others, so that we can solve certain segment of problems in a different way. There is no silver bullet for all the integration problems. There has never been, and there can never be.

Subbu

I think you're right about webservices transmogrifying to a component system. It's already happening, and why shouldn't it? A service is addressible, has actions, and (hidden) attributes, and you deal with them through well defined contracts. Sounds like JavaBeans or COM.

IDE's will emerge that solidify this programming model.

Anything that is an "official" component today will be accessible as a service tomorrow, in very pedestrian ways. VB programmers will use these services.

Billy

I liked your article a lot. But I can't say I agree with you on the web in web services referring to a 'cob web of applications/services lying around companies or their partners' The web in web services refers to the internet and means (or at least implies) invocation across the internet. James Gosling is right about SOAP, in that the hype surrounding it, is in no way commensurate with its importance.

Services inside the enterprise will be far more important than outside (i.e. web services). And we need Service Brokers and similar infrastructure to enable service based applications and service based developed. These are the interesting and hard problems. In comparison, SOAP enabling services (to create web services) is a trivial problem.

BTW, people seem to be confusing the article being crap, with what Gosling said being crap. The former is obviously true; the latter may or may not be true. I personally doubt it is.

Phil Bradley

Gosling bursts the Web services bubble

Doh! What did Gosling say? "The killer app in this Web services world is synergy," and "A market, not a product"? Synergy? A Market? Man, I've never heard so much pie 'n the sky prattle from the father of Java. All he had to do is add a few more managementease phrases like - the real challenge of Web Services is to give customers "traction" so that they can "break away" from the competition. The only thing Gosling has provided is great fodder for the next "Office Space" movie. I'm sorry Gosling, stick to low-level language design. Leave the trite metaphors to those like John Chambers. We'll all respect you more as an Engineer. =)

Folks,

I think Gosling deserves little more respect than this.

I don't know how many of you followed a few very long threads on the DistributedCoalition.org mailing lists. Check the archives of July/Aug this year.

The point is that the similarities between web services and RPC-based architectures are far too many. At the very basic level, whatever advantages are attributed to web services can be (and were) achieved using RPC-based architectures. I'm not going into the details here - please refer to the archives of the above group. Of course, things are done differently, but that's because the underlying protocols are different. Again, newer protocols have the advantage of benefiting from the successes and failures of older protocols.

The fact that debates on web services vs some XYZ are taking place so often proves this point.
Subbu

The customer can count on us to globally enhance professional opportunities through web services so that we may endeavor to synergistically facilitate corporate information.

Of course they are = they help developers to aggregate impactful paradigms, strategize transparent networks and maximize their core competencies while at the same time leveraging best practices and streamlining team synergies.

What about enhancing shareholder value ?
Should that be done side to side as James G suggests , or is more of an up and down thrusting approach ?

You have to use an iPlanet for that shareholder value thing :-) (you know, specially integrated into your OS)

My version of web services is one-liners, HttpClient,
and JSPs

no XML parsing, mind you.

..and for that multi-legged Octopus recommended by
Wrox Press--just use Dynamic Java to script it,
what is all this XML crap anyway..

J2EE needs a progammable API so we can use dynamic Java
for all these descriptors. This ought to be a JSR,
but I just don't have time.

> for all these descriptors. This ought to be a JSR,
> but I just don't have time.

You could take the DTDs for the descriptor docs and point something like Castor at them and end up with an object model.

<quote>
You could take the DTDs for the descriptor docs and point something like Castor at them and end up with an object model.
</quote>

Castor needs schemas, it doesn't work widh DTD's as far as I can tell, and J2EE uses DTD's all over the place (I'm hoping they will switch to schemas at some point).

--
Cedric

There are many other reasons I'd opt for dynamic Java over
XML, but ignoring those for the moment, yes
you could convert some stuff to a schema using
XMLSpy so you could again see all the relationships between
things as a model, unfortunately there seems
to be a problem with the distro.

java.lang.NoClassDefFoundError: org/xml/sax/SAXException

If you try to add
some libraries from elsewhere, for example both
the WebLogic 6.1 distribution or the TopLink 3.0.3
disto, you still get some problems:

org.xml.sax.SAXException: The following namespace "https://www.w3.org/2000/10/XMLSchema" is no longer supported. Please update to W3C XML Schema Recommendation.

With the older WebLogic 5.1 libraries I get:

java.lang.NoClassDefFoundError:
org/apache/xml/serialize/XMLSerializer

Castor sounds promising, we could see the relationships
between everything in a visual model again, but is
this worth pursuing any further...don't know. Does
Rose help at all with this...Together 3.2 doesn't maybe
Together 5.5...Sun Forte? Time to move on...

I can't see much in that article which "hits out at SOAP"...

Plus, it doesn't exactly square with the announcement on the Java site:

http://java.sun.com/features/2001/10/sun1.html


Robbie

One, it will take more than James Gosling to rid the W3C and OASIS of the work, concepts, plans, and dreams of Web services.

Two, the title disagrees with at Mr. Goslings own example. The very idea that you can put patient and test records "in only once" requires a very sophisticated set of cooperative registered services (a.k.a. Web services) that are observant of information rights.

Such a set would require a great deal of work in terms of enabling services to contract with each other, create time limited agreements, and negotiate for information rights between various role players who include: patients, doctors, hospitals, patients, staff, service organizations that conduct tests, patients, various government organizations: the FDA who regulates treatment and the CDC epidemiological data, insurance companies who authorize tests and patients if I didn't mention them.

The two cent question is "Who gets to look at what records when?"

There is no two cent answer. I don't think mere end-to-end platform platform and equipment integration with applications that are only internally smart is the entire solution, but that James has actually made a strong case in favor of Web services.

The most important part of the article is when Gosling states:

"[Web services] is really all about exposing the services that people have already been building, but exposing them to people who perhaps may use them in unplanned ways,"

The "unplanned ways" may be a massive understatement. Computers automatically finding one another and "doing business" together is a problematic proposition. Anyone with a background in EDI can tell you this.

By the way, the consultant BS ala "aggregate impactful paradigms" is hilarious. One of the worst parts of my job is dealing with consultants (such as Anderson) who come in and spread that crap around the building.

<quote>The "unplanned ways" may be a massive understatement. Computers automatically finding one another and "doing business" together is a problematic proposition. Anyone with a background in EDI can tell you this. </quote>

I hope the developer community realizes this fast enough. I tend to think that "business via dynamic discovery" is a fundamentally flawed idea. There is more to business than just discovery. I think it would take somemore time for reality to sink in.

Subbu

Subbu,
could you riff a little more on your "fundamentally flawed"?
my understanding of business amounts to "making money
is a different problem every time"...
-R

Even when you REALLY want to do business with an outside firm AND you work directly with them, there are ALWAYS many tripwires on the path. Real business transactions are complex and the chances for unexpected and unintended results are very high. No specification, whether it is UDDI, WSDL, or anything else will change this. The Web Services hype is a marketing creation.

I think it is an evil plot designed primarily to hypnotize CIOs.

Deep smooth voice from a software salesman - "BUY OUR SOFTWARE - YOU CAN BUILD WEB SERVICES WITH IT."

True. If you look at the origin of web services, one of the ideas was that, just as an individual with a web browser 'dynamically' discovers a web site selling the cheapest spice girls CD & makes a purchase, businesses too can perform procurement transactions by dynamically discovering suitable suppliers matching a set of attributes. But in reality, businesses don't work that way, and may not do so for a while, due to the complexity of legal ,human & risk factors involved in business decisions.

<Quotes>
&#8220;When first conceived (if I understand and interpret history correctly), CORBA was meant for integration - but most of the vendors/architects made it into a component technology, using which one can build distributed components&#8221;

&#8220;The "unplanned ways" may be a massive understatement. Computers automatically finding one another and "doing business" together is a problematic proposition. Anyone with a background in EDI can tell you this.&#8221;

&#8220;I tend to think that "business via dynamic discovery" is a fundamentally flawed idea. There is more to business than just discovery. I think it would take somemore time for reality to sink in.&#8221;
</Quotes>

In relation to all the above quotes , I would like to ask a question in this forum. A colleague of mine , PHD-math turned programmer mentioned to me that the problem of integrating two systems is not programmable ( like the dynamic discovery of web services ) because , it is related to the central theorem in computer science, i.e the halting theorem ( I am not a computer scientist and I am not sure I am naming the theorem correctly), which apparently roughly states the following :

   &#8220; There is no way in advance ( in principle or theoretically) to tell if a program will halt without testing to see if it actually does &#8220;

which means this dynamic discovery will need baby sitters (support) all the way just like all the previous ones!!. May be it will infinitesimally approach automated "integratability :)" , except the support people will need to push the plug harder to correct loose ends.

Okay, guys - I'm going to stick my neck out here.

There's deployment and then there's IT strategy - and they are often in tension with one another.

The problem with a technology like RPCs is that it tends to couple things more or less tightly. Yes, it is easier to deploy right now than XML / SOAP sorts of layers. Speaking as an implementer, that's useful. But speaking as an architect it is iffy and as a once-senior-executive it's a mess!

I have, in fact, architected 6 and 7 layer, enterprise integration systems that are up and running. They actively incorporate legacy applications that will take years to replace, while allowing those companies to change the way they are doing business out in the real world. Furthermore, because we architected in a series of "inefficient" translation and messaging layers, those clients have already been able to unplug key off-the-shelf software packages and replace them with others, without disrupting the rest of the integrated computing environment.

Was that easy or transparent? Of course not. But was it successful? Absolutely! Mucking around at the RPC level would have made that a mess - we're talking about a hundred+ applications, approximately 25,000 business rules (it was a financial services co. w/ different regulations in every state), 9 major call centers distributed across N. America and a huge distributed relational db/data warehouse underlying the object-based upper layers of the architecture.

Sometimes it's not about ease of implementing. Sometimes it's about migrating from the systems already in place to new ones without breaking things along the way.

Robin

I'd like to take a different angle on this SOAP discussion.
I agree SOAP is overhyped but I think that SOAP and other technologies are a good step in the right direction. Here's why: Writing applications with web browser front ends sucks! Don't get me wrong, writing these types of applications with J2EE is what I do all day. But the shortcomings of HTTP/HTML/JavaScript reminds me of the bad old days when dumb termninals were popular. My point is, that SOAP or simular technologies could provide the benefits of exchanging information on the web without all the baggage of having to dumb down our user interfaces to work with the major web browsers. The problem is not just about technology, its more about about having standards for information and content exchange. I'm not actually advocating that we go back to the days of fat clients that have to be downloaded and installed before using, and I am not saying that we ditch the browser concept. I think that better browsers, free from outdated and kludged standards will emerge. Further, these "browsers" should not be the stand alone islands that they are today. We should be able to integrate rich content and browser-like components into our server-side, network, and desktop applications.

Anyhow, thanks for reading my IMHO.

Rob Finneran

Can we say: Java Web Start?

Instead of wasting time in building new Browsers etc, let's spend time streamlining Java Web Start. It allows you to build an application and then WITH NO CHANGES(!!) make it available over http!! It will still be the complete Java App you had locally!

The only major problems with it right now are:
1. If they don't have the JRE, Web Start will install it. (Over a 56K modem this is hell. There needs to be a way to streamline this. Maybe to only download the JRE classes your app needs?)

2. They need Web Start installed before it will work
(again, a big slow download for a 56K)

What makes me feel bad about web services is SOAP itself.
SOAP revert us to the API war times, when everyone used to publish their own APIs for everything (over its proprietary communication protocols).

The Industry acceptation of SOAP has many causes, one of them is the need of proprietary binary code, for which API are made. Lay a set of internal features over the SOAP interface and you have something to sell very different than interoperability.

Among the programmers, the reason to embrace SOAP may be related with the compulsory need to work with arcane things like model templates and object proxy metaphors or something which have two or three complicated words rather to speak directly the client business language.

XML itself has better mechanisms for standardization which are underused in SOAP. The notion of document generation and interchange is the cause of the Web succes.

I know I´m a minory here, even maybe you don´t understand me for other reasons than my poor English...My opinion is that what the industry need is the definition of different kinds of XML documents to interchange using HTTP, not APIs anymore.

Alberto,

<quote> My opinion is that what the industry need is the definition of different kinds of XML documents to interchange using HTTP, not APIs anymore </quote>

This opinion makes sense to me. One idea is to (continue to?) work out a text-based protocol for the exchange of XML business documents that could run over other text-based protocols like HTTP and SMTP. Also, one point not mentioned yet is that almost all B2B transactions are best performed asynchronously so this new protocol should have some asynch. semantics built into it. XML events could be sent to channels or queues with many important services such as searching for certain events. I am probably describing something that already exists.

What also really is needed in my opinion(and this might be what SOAP is aiming for) is a standard XML synchronous service that allows browsers, arbritrary clients to request, search, and modify data behind an XML server.

I also like the notion of adding deferred synchronicity which for example was common in CORBA with callbacks.

I think one thing people should understand is that SOAP is just a protocol for Web Services and far from being the whole story. We were doing web services at HP E-Speak before SOAP existed. The notion of being able to advertise and discover services in the internet model is powerful but is not the silver bullet. There is still the stuff going on the LAN (or with HTTP-like interface to the LAN), like J2EE. What I see as being important is to define a coherent interface between these two because the models are very different. Security becomes a completely different game on the internet for example. I feel we must separate these concerns in the future architectures. Having applications throwing SOAP messages around from every angle will be a mess as Gosling is saying.

To illustrate what I was saying about the differences that arise in internet model, this is a paper concerning transactions in web services -

https://www.w3.org/2001/03/WSWS-popa/paper50

Probably got this thread a bit late. Yeah, I find this all very funny indeed. Poor Sun, those wicked nasty Microsoft cronnies and their deceptive .NET platform which looks like Java. Man, don't you just love this industry? They're always be jobs out there recession or not lads. Hey computer industry keep on inventing this crap! Who the man? But yeah, I agree with your article here. Hypothetically, say, in the morning, we decided to get rid of HTML and HTTP, Java, .NET, web services, keep decent XML related stuff and resurrect X-Windows, no web browsers, no Java, no VBScript and no ActiveX etc. I mean we got faster intranets and the internet is a little more developed now. All we have again is X-Windows where the DISPLAY environment variable is the URL. You just point your URL at the X-Windows application running on the remote machine (by means of clicking on a local link in a locally running hypertext browser control or something fancy) and viola the remote application brings into action on your side and hey if its a trusted site, the basic X GUI stuff is cached. Isn't Tim Berners Lee working on redesigning the internet or something, some new concept called Curl or something? Anyhow what the hell do I know? Nomatter what the latest hottest technology is, its always there for a while and something else replaces it sooner or latter, Java had its day, then it was datamining and then something else and now its web services.

Hey Phil Bradley, is that you man? Remember the Informix days?

Has anyone evaluated Web Service Integration, against Java Connector Architecture ?

Saj

(If anyone knows sajid tagari please let him know)
hi sajid tagari formerly (I think) of BEA weblogic company,
this is craig soens-hughes from sybase/vizzavi/vodaphone
nightmare project --- get in touch !
cheers,
craigjava at hotmail dot com
home 0207 794 6140

P.S. If anyone knows sajid tagari please let him know