Like so many of the "this will solve all your problems" technologies of the past, CORBA came riding in on the usual fanfare of "yes, finally, this is really the one!"
What I find fascinating is that you almost never hear those same people say, "Oops, we messed up." I've always wondered what happened to all those people who were predicting the apocalypse for Y2K. These people had paid to hear some speaker tell them that "there were chips in everything, so all the trucks, water pumps and electrical stations will stop working at midnight on Y2K." These same people would never listen to me, who had programmed embedded systems and so knew that many of those systems didn't even know or care what time it was.
The one or two people I knew who went around trumpeting the impending disaster were not apologetic or reflective on January 1, 2000. They simply moved on and found something else to predict doom about.
I remember when the OMG (the body that created CORBA) first started. To be a member you had to be a corporation and pony up a large fee each year. And CORBA itself always made me feel stupid, like I must be missing some essential epiphany that would unlock its complexity. A part of me, which I've learned to trust over the years, kept telling me not to bother learning the complex details of CORBA, and the only time I ever actually created a CORBA client, it was in Python, so it was actually easy.
So I found this article to be quite an interesting analysis of CORBA's history, and of committee-driven specifications in general.
After the author has analyzed the rise and fall of CORBA, he proceeds on page 4 to consider lessons we might have learned from the CORBA experience. I would summarize his analysis to say that:
A standards body should formalize existing practice, rather than inventing new practice without experience.
I spent roughly 8 years on the C++ Standards Committee, and I remember that this was one of the initial goals of that committee. Although invention did happen, it was relatively small and careful compared to CORBA and other standards which were created from scratch, without experiments or implementations to ground it in reality. (And before you complain about the complexity of C++, virtually all the issues of the messiness of the language can be tracked back to "backwards compatibility with C," which has always been both the boon and the bane of C++.)
Another example: the original EJB design was based on a purely theoretical model of the way "enterprise software" would be built, and the roles and tasks of the people involved in that process. It turns out that these roles never actually happened, and so the design of EJB -- intended to make those roles easy -- added so much unnecessary complexity that, after an unpleasantly long time, it was completely redesigned in EJB3, based on actual practices observed in libraries like Hibernate and Spring.
I found the most interesting quote in the article to be this one, on page 4:
"Web services, the current silver bullet of middleware, uses a process much like the OMG's and, by many accounts, also suffers from infighting, fragmentation, lack of architectural coherence, design by committee, and feature bloat. It seems inevitable that Web services will enact a history quite similar to CORBA's."
Web services have definitely given me that funny "hmm, maybe not" feeling. And my experiences programming against the Fedex and USPS computers (see previous weblog entries) don't inspire me with confidence, because if SOAP or whatever is so great, why don't they provide it? (And I will point out, again, the irony of every web services article and book using Fedex as an example of why we want web services.)
Web services do seem closer to things we actually want to do that CORBA did, but the complexity of SOAP, for example (and its apparent decline in the world before it has even gotten out of the starting gate), is not particularly promising.
And the clincher is all the over-the-top fanfare that web services rode in on. When the marketing people are more excited about a technology than the techies are, chances are it sounds better than it is.
Of course, the fundamental idea of web services is a good one. We really do want to be able to extract useful information from a remote site. That's happening, and it will continue to happen. But it must be simple, because even if programmers are smart and can figure things out, the CORBA experienced proves that we don't want everything to be as complex as it can possibly be.
Programming is all about abstraction, and the abstraction here is the remote procedure call. I want to be able to write some kind of simple function call, and get some information and maybe produce some kind of side effect on the remote computer. If the underlying mechanism happens to ship data back and forth using XML, or uses an XML-RPC, SOAP, or JSON setup to make the call, that's fine -- but I'm solving a real problem here and I don't want to have to spend my time figuring that stuff out, or even needing to think about it.
The system that provides remote procedure calls, spans the space of calls that need to be made, and that keeps it simple to implement and use on both the client and the server, will be the one that wins. At least I hope so, and in the flattened world of the internet, I think it has a better chance now than it ever did in the past.
Webservices give you language independence, and I think it has fulfilled that promise. In terms of easy of implementation (server or client), I think that this only hinges on whether there is a library for using webservices that is simple to use, and does not require you to know about the underlying XML definitions(WSDL or SOAP). I think that there are libraries that come close to this(axis tools for Java, activestate's webservice wrapper for python, for example). The Java version is great because it benefits from typing, you know what structures you need to pass in and get back. For python and other dynamic languages you need to rely on documentation extracted from the WSDL to know what to pass in, and reflection to know what you get back, but, IMO this is entirely possible.
> Webservices give you language independence, and I think it > has fulfilled that promise.
But that's exactly what CORBA does! I think that was the point of the ACM article. If all you have to do is achieve your stated design goals, then we could consider a lot more projects to be successful. But as the ACM article points out, when you have a committee producing a standard, one of the often unstated design goals is "come up with something that everyone on the committee agrees with, or can at least tolerate," and this becomes "design by speculation" rather than what it should be, which is "design by need."
> In terms of easy of > implementation (server or client), I think that this only > hinges on whether there is a library for using webservices > that is simple to use, and does not require you to know > about the underlying XML definitions(WSDL or SOAP).
But my point is that, if web services are so great, why haven't we seen massive adoption? The Python article above was written in 2001, for example. How long have we been hearing about how great web services are, and how they will revolutionize everything, and yet when I go to the USPS, or to the most common example given for Web services, Fedex, what do I find? Some variant of RESTful XML.
I suppose if we redefine web services to be "any service provided through the web, regardless of technology," then from the standpoint of USPS and Fedex (and probably UPS, but I haven't looked at their protocol), it's a success. But if SOAP is the official high-level interface of the formal Web Services spec (is it? I don't know), then I don't see evidence of widespread adoption after this many years of Web Services hype.
> But if SOAP is the official high-level interface of the > formal Web Services spec (is it? I don't know), then I > don't see evidence of widespread adoption after this many > years of Web Services hype.
Whether or not it's the 'official' interface, if you go to the W3 Web Services page, there's a lot of talk about SOAP and WSDL, but nothing of REST (or anything else for that matter).
IMO, in the minds of the average developer, the term "web service" is synonymous with SOAP/WSDL... unfortunately. I'm constantly getting caught out in discussions; because for me, web service means any service delivered over the web (be it SOAP, XMLRPC -- or in my case, preferably REST), whereas usually the people I'm talking to are usually thinking only in terms of SOAP.
Bruce, have you looked at JTRS? It's a software radio standard that the military has mandated for all future military radios.
It's kind of a plug-and-play technology that is supposed to allow you to change the kind of radio you use by swapping cards, etc.
Inside a JTRS radio the different parts interact with each other using CORBA. The thought of something like CORBA playing an internal role in an embedded system seems amazing to me (maybe I have too much experience writing embedded applications in assembly to appreciate it).
> The thought of something like CORBA > playing an internal role in an embedded system seems > amazing to me (maybe I have too much experience writing > embedded applications in assembly to appreciate it).
My first programming projects were embedded systems in assembly and C, so it's hard for me to imagine, as well. But that was a long time ago, when memory was very pricey.
> <p>The system that provides remote procedure calls, spans > the space of calls that need to be made, and that keeps it > simple to implement and use on both the client and the > server, will be the one that wins. At least I hope so, and > in the flattened world of the internet, I think it has a > better chance now than it ever did in the past.
One of the things that I've grown to love about Java and the Jini platform inparticular is my ability to keep my programming abstractions as RMI modeled method calls. With the JERI stack in Jini 2.0 and later, I can plug in an appropriate invocation layer to talk to something else.
I could plug in a web services layer for SOAP, a REST layer or something else. In the end, I'm usually talking to Java on the other end, so its possible to just use the power of Java mobile code and exploit its power.
The important thing about Jini is that all of this is a defined part of the platform, already there. There aren't evolving standards with more money to spend to get software that meets those standards.
And yes, security including both mutual authentication and authorization is part of the delivered goods.
Jini has recently been released by Sun as an ALV2 licensed opensource system. Thus, the door has opened for a whole new wave of distributed systems revolution.
As the architect of my small company's service api (our core product), web services are very much real for me. Marshaling is tedious and I don't want to force my clients to hand code their proxies. Very basic usage of SOAP provides a pragmatic solution since proxies can be automatically generated from WSDL. Look ma, no XML! (very basic = literal/wrapped, no Exceptions, everything in the soap body, no name spaces, no uddi, etc). This type of implementation is not even in the same ballpark as CORBA, and is only possible because of the loosely coupled, layered nature of the WS-* specs (pssst, just ignore 90% of them).
XML-RPC is fine for small things, but quickly causes code bloat with all the hand rolled DTO Mappers (and verbose marshaling exception handlers -- ugh!).
Why isn't SOAP more prevalent? Maybe because folks on both ends of the wire get overwhelmed by how theoretically complex one could make a SOAP service, don't see how practically simple it can really be, tire trying to understand all of it, then seek mental REST in the complete absence of type mapping -- meanwhile incurring all the Mapper typing.
One argument that I often hear in support of SOAP is that tools make working with SOAP much easier. As someone who grew up on vi and Emacs, I was always suspicious of that argument, at last until I saw things like Web service annotations in Java EE 5, which are a sort of tool that almost completely automates working with SOAP, even if your tool of choice is, say, vi. (A while back, we published a short tutorial here on Artima about using JAX-RPC to expose a POJO as a Web service (Three Minutes to a Web Service, http://www.artima.com/lejava/articles/threeminutes.html).
Such APIs, annotations, etc., are the level at which most developers will interact with Web services, and most language environments now support a large array of such APIs/tools. In fact, this type of simplification is the path EJB 3 (and Java EE 5) took: Most of the Java EE 5 stack's functionality, even inner workings, are similar to earlier versions, but annotations and the persistence model, for instance, provide a more palatable facade on top of that infrastructure.
What is more interesting is that folks relying on such tools tend to forget that remote and local method invocations are very, very different kind of things, and that simply wrapping a remote call as though it was a local call can lead to all sorts of reliability issues that can plague an application. That's really not SOAP's fault, though.
> Very basic usage of > SOAP provides a pragmatic solution since proxies can be > automatically generated from WSDL. Look ma, no XML! > (very basic = literal/wrapped, no Exceptions, everything > g in the soap body, no name spaces, no uddi, etc). This > type of implementation is not even in the same ballpark as > CORBA, and is only possible because of the loosely > coupled, layered nature of the WS-* specs (pssst, just > ignore 90% of them). >
"All developers get first-class support for writing XML web service client applications. No messing with the plumbing: You can expose your APIs as .NET interoperable web services with a simple annotation."
Maybe this will make Web services more common. However, my impression from looking around for server-side web services libraries is that this is not the first library to make it easy to create and expose web services.
So my question still remains: "after this many years of web services hype, why don't we see them everywhere?" (That is, WSDL/SOAP Web Services).
> > Jini has recently been released by Sun as an ALV2 > licensed > > opensource system. Thus, the door has opened for a > whole > > new wave of distributed systems revolution. > > Are you saying that Jini -- a Java-only solution -- will > cause a revolution where WSDL/SOAP Web Services -- a > language-independent solution -- has not (or not yet)?
While the Jini platform is a Java based environment, that does not keep it from talking to other platforms. The Jini Extensible Remote Invocation (JERI) stack allows you to plug in whatever kind of invocation layer or endpoint you need.
Jini as a web services platform is no different than Java as a web services platform. What you get with Jini is the ability to make more choices in deployment and security and have more tools for distributed computing available to you.
Web services is a mediation mechanism or a programming language neutralization mechanism. Using web services with Java makes your Java program web services centric. If you include proper layers of abstraction to remove such bindings, you are going to end up recreating all the features of the Jini platform from a plugable SPI/API perspective.
If you choose to use Jini as the platform for your SOA, it doesn't keep you from talking web services to such entities that need that. But, if you just use Java EE 5/EJB3.x, then you don't have all the features of Jini for optmization of your system to better manage versioning and evolution through the use of mobile code.
Every choice you make has features and limitations. I think there are far more features available when you choose Jini as the underlying infrastructure for you Java based SOA.
> I just saw this for Java SE6: > http://java.sun.com/developer/technicalArticles/J2SE/Deskto > p/mustang/beta2.html > > "All developers get first-class support for writing XML > web service client applications. No messing with the > plumbing: You can expose your APIs as .NET interoperable > web services with a simple annotation." > > Maybe this will make Web services more common. However, my > impression from looking around for server-side web > services libraries is that this is not the first library > to make it easy to create and expose web services. > > So my question still remains: "after this many years of > web services hype, why don't we see them everywhere?" > (That is, WSDL/SOAP Web Services).
Perhaps because this feature will make it easy to write trivial webservices that do things like add numbers. I've never seen a production webservice that didn't send and recieve data that was significantly more complex. Also, I've never been to the planet where developers create service specifications based on how a tool interprets their source code.
Over and over again I see these "solutions" created by people who appear to have no real-world experience with the issues they attempt to address. To me, this is just a 'pet store' feature. Great for demos targeted at pointy-haired bosses but not much else.
> Perhaps because this feature will make it easy to write > trivial webservices that do things like add numbers. ... > Over and over again I see these "solutions" created by > people who appear to have no real-world experience with > the issues they attempt to address. To me, this is just a > 'pet store' feature. Great for demos targeted at > pointy-haired bosses but not much else.
I've been suspicious of SOA etc. from the beginning. Such things depend on client coders trusting the black boxes. We all (mostly) believe that a simple test of foo.add(2,3) will confirm our trust. Otherwise, the meaning of object/function/method is something we have to agree on. We can only do that if we can see the gears.
If state changes only at "the other guy's end", well, that might be acceptable. But if "the other guy's end" changes state where I have culpability? Ah doan tink so.
Flat View: This topic has 22 replies
on 2 pages