Web services' dirty little secret


News: Web services' dirty little secret

  1. Web services' dirty little secret (11 messages)

    Frank Moss, CEO of Bowstreet, gets to the heart of Web Services, and discusses things that maybe the big guys don't want you to hear:

    "Do you remember the last time these guys [Microsoft, IBM, SUN, BEA] were all singing the same tune? They were trying to tell us that client/server applications would level the playing field and make computing cheap, easy and open."

    This article can be found at:

    Has he got it right?

    Threaded Messages (11)

  2. Web services' dirty little secret[ Go to top ]

    I don't get a lot of Frank Moss's criticism here... let me be very clear that I *understand* his skepticism because regardles of how ubiquitous a Web Service is, it eventually has to connect with some sort of App Server.

    But when he says that Web Services are not portable, what does he mean?? First, please define the term "portable" --- there are many different viewpoints on it, every one of them correct. For example, one company may find that Web Services are 100% portable because they have several applications with the same entry-parameters. Thus, a Web Service that encapsulates and implements these parameters can be juggled among these applications. Portable, right? Well, not exactly -- to another vendor, they may completely agree with Frank Moss's assessments because they want to "magically" drop a Web Service anywhere on any machine and PRESTO -- instant Web Site! Get real -- the year is 2002 and there are no Starship Enterprises out there yet.

    I find ~some~ of Frank Moss's comments overly simplistic and unfairly critical. Web Services have come accompanied by a lot of ridiculous hype, I agree, but for Frank Moss to go to the other extreme and claim that Web Services represents nothing unusual is also a fallacy. Web Services have given us yet another helpful layer of indirection. The fact that this extra layer doesn't solve the world's problems doesn't make this technology a candidate for a "Tar-and-feather" display down Main street.

    The last paragraph of this article is the only one that is clear and emotion-free. Sorry we didn't get to meet the Klingons this time around Frank, maybe with the next conspiracy-laden innovation, we will.

  3. Web services' dirty little secret[ Go to top ]

    Web services are about interoperability, not about solving all of the problems such as vendor lock-in, cross-platform portability, <insert complaint here>[1...n].

    In fact, what web services is really composed of is simply allow a vendor-neutral contract to be exposed, the implementation details to be written in whatever vendor-specific technologies the developers wish, and allow communication using a vendor-neutral protocol. If portability is of concern, write your web services implementations in Java.

    Of course, all of this means that you're tied to the implementation technology, but you are free to change this at will; as long as you abide by the same contract, that is.

    What was Frank expecting from web services? To bypass any implementation whatsoever, and allow WSDL to describe the business logic and implementation of the web service's contract? A bit unrealistic if you ask me.
  4. Web services' dirty little secret[ Go to top ]

    "In fact, what web services is really composed of is simply allow a vendor-neutral contract to be exposed, the implementation details to be written in whatever vendor-specific technologies the developers wish, and allow communication using a vendor-neutral protocol. If portability is of concern, write your web services implementations in Java."

    Precisely correct. I see Web Services as an enormous step forward in one narrow but important respect. Web Services specify a contract which can be used to connect virtually anything to virtually anything. They also can leverage the ability of XML to express complex data structures and the power of XML tools to parse XML documents to build remote applications. The rest (UDDI) of it is hype, but the core is plenty useful.
  5. What a silly piece - Frank Moss' company has a vested interest in pitching that the major vendors are going to lock you in - that's the only way he keeps his company afloat now that all competitive advantage has been taken away from Bowstreet.

    "What I see emerging is a new layer of vendor-neutral software that sits on top of the Web services platforms from all the major players--the "Web services automation" layer. This layer will address both pain points. One, it will let companies bust out of the wet cement of traditional application development by automatically assembling any vendor's Web services when they're needed. With this approach, developers will code, modify and maintain one application instead of 1,000."

    Shocking! That's exactly what Bowstreet makes! Wow!

    Why don't Frank just cut to the chase and print a press release from Bowstreet saying "IBM, BEA, Sun and Microsoft suck because they're taking business away from Bowstreet."
  6. What Frank Moss is saying is true but kind of obvious. All web services give you is an interface that anyone can call. How you actually architect the implementation is a completely different matter, if you write your service implementation initially in motorola assembler you will have problems porting to different systems, but we knew that anyway.

    The implementation level is where things haven't really changed. If you want to be portable and cross platform you use Java. If you want to be vendor neutral you don't use vendor specific APIs, or at least carefully isolate any calls you do make.

    Using open interfaces doesn't shield you from passing proprietory data across those interfaces so you still get locked - anyone can call your web service, but only Windows XP service pack 5 will present meaningful information to the web service for example. Again, all you have to do is think a little about the situation to figure these things out.

    What do web services get you? They let you extend your application across the internet by opening up the interfaces to consumers and let other people provide alternative implementations IF YOU LET THEM. So by promoting web services the large companies create opportunites for growth and they're also able to offer proprietory services with open interfaces which as Frank Moss explained still allows them to lock you in.

    The other thing web services get you is easier system integration, but at present only if you're not particularly interested in transactions, sessions or security.

    Perhaps the article was for people who thought web services were the herald of a new era where everything was open, and large corporations no longer made a profit?


  7. Frank is right that the "bigs" want to lock us in. But doesn't Bowstreet want to do the same? Its a proprietary IDE + runtime for building websites; there's no standards for porting an application built in Bowstreet to another application framework. Sure, you can run it on multiple app servers or OS's, but any application framework (not owned by an app server) worth its salt does that! So whats the point.

    Frank claims that the new "web automation" server will:

    "One, it will let companies bust out of the wet cement of traditional application development by automatically assembling any vendor's Web services when they're needed. With this approach, developers will code, modify and maintain one application instead of 1,000.

    "Second, the Web services automation layer will be entirely portable to any major application server so that customers will be forever liberated from the stack on which the Web services applications were created. "

    ...Whats this stuff about the "wet cement" of traditional application development. I guess Bowstreet think that if something isn't built in an IDE using XML scriptlets it cannot be modified. This is the ONLY claim Bowstreet has ever made to justify their existence. This needs way more evidence before its believable. But I guess their idea is they're bringing sw development a level up in the abstraction layer above coding in Java, C++, C#, VB, etc. Hm...

    the other claim is just app server portability, big deal.

    This article seems like sour grapes.
  8. I think he is making a valid point despite the sour grapes tone of the article.

    He is arguing that the integrated stack vendors (IBM, SUN, Oracle, BEA) are all following the Microsoft playbook and unecessarily tieing their products within their stack to lock in customers and exclude competitors. True, but hardly news. His main point is - don't think anything has changed with web services! The result will be the same as Windows - elimination of innovative small to medium size vendors. And monolithic one size fits all technology. We shall see!

    My reply to Frank Moss is - educate you customers and prospects on the significance of standards. Feed them hard questions to throw at reps from the gang of 4 above. Like 'You say you are standards compliant. Why does that matter?' Its pretty hard to make an answer without mentioning interoperability or portability.
  9. What this guy does not understand is that Webservices are not geared towards simplifying the development process. Nor are they geared towards writing an application using say IBM's Webservices implementation and deploying it on say .NET. WebServices are about application-to-application inter-operability. In otherwords, applications developed on J2EE platform (running on for instance solaris) being able to exchange data with those running on Windows under .NET without hardwired binding in code. This is what WebServices are about. No one is claiming that their WebServices will deploy and run on another's platform because that is not the intention.

    I would suggest to the writer to first get a handle on what issues/problems WebServices are designed to solve before writing such nonsense.
  10. <
    I'm sorry but you are wrong! Service based √°pplications' dramatically simplify application development and open up a whole new prospect of quickly and easily assembling business functions from finer grained services.

    Web services will quickly obselete conventional applications, in the sense of a monolithic piece of software from a single source.

    Conventional applications will be surrounded with web service wrappers and become web service producers. They are just not designed to be web service consumers and no obvious way to make them so, short of major rewrites. By which time no one will be buying conventional applications.

  11. Web services' dirty little secret[ Go to top ]

    Everybody's going to have their own opinion on this, and I'm not trying to defend any one opinion or the article itself, but I did want to point out a divergence between what the article attempts to say and what is being debated here.

    It seems that some of the replies are debating whether web services have anything to do with portability or the article's point of vendor tie-in... Given the title of the article, I can see where the confusion may come from...

    It also seems that to get published these days, articles have to say something about web services, since that's all the tech rags are willing to talk about (my opinion only :-).

    Anyway, while the article does mention web services in the title and a couple times in the text, it is not really about web services at all. It's about the fact that some vendors are using J2EE and WebServices marketing/sales-speak to try and convince customers that their stuff is all standard, build once run anywhere... If you really stuck to the standards, that should be the case. That is one of the promises of J2EE after all (build a standard J2EE web based app on one J2EE compliant app server, it should run on all of them). And what the article appears to be pointing out is that these vendors are touting the standards and portability, but then handcuffing customers with a proprietary app infrastructure that will only run on their platform (sort of like Windows apps that used internal undocumented stuff that their customers apps couldn't or shouldn't use?...)... Sure you can build a cool, standards (J2EE and WebServices) based app on the J2EE FooServer using the FooApp Portal Developer, but then it'll ONLY ever run on FooServer... To someone willing to tie themselves to the FooServer platform forever that's ok, but there are many that want the standards/portability benefit that J2EE should be providing, and thus the ability to deploy their App based EARs/WARs on any J2EE compliant appserver.

    There are vendors (not to defend any particular one :-) that do stick to the standards, rather than handcuff you to proprietary server APIs that the J2EE "Compliant" appservers provide in addition to their J2EE-ness. These solutions should thus be able to support all the leading J2EE AppServers. Build your app on one, and then if your company has a change of heart and decides they will standardize (internally) on BarServer instead of FooServer for deployments, then your J2EE based Application (whether it uses web services or not) should be able to run on both.

    So, this article is really about the Application infrastructure solutions and whether the claims of standards adherence really buy you (the customer of those Web App Solutions) anything or whether it's no better than being proprietary because it's locking you in to that vendor's server anyway if you believe their marketing "J2EE / Web Services Standards" claims and handcuff yourselves to that AppServer forever...
  12. Web services' dirty little secret[ Go to top ]


       I agree with the theme of your remark, that this article is not entirely about portability of Web Services and the practical uses of this technology.
       This article is about Frank Moss adding to the flibbildy-floo out there regarding Web Services -- every new technology will see the Devil's Advocate position rise up, and Frank gets the goat hooves for this one.
       This article mentions two reasons why Web Services does not live up to the hype as Frank Moss sees it. Reason #1 is "...First, the portal servers and application frameworks of the big vendors pour the "wet cement" of hardwired programming all over Web services..." and reason #2 is "...The second dirty little secret is that the applications that customers will create with these portal servers and application frameworks are forever tied to the rest of the stack on top of which they were created...".
       Notice how both reasons are saying exactly the same thing, and as a matter of fact, I couldn't agree more --- Web Services need to go further before becoming 100% pure portable code modules, able to incorporate the 100% pure portable EJB code modules ( not yet! ) to which they are extending.
       The bottom line is that too many people are pointing out the obvious. Yes, nothing is portable yet. Yes, it would be nice if it were. No, Web Services is not portable either.
       So why is this article acting as if it has this grand epiphany to bequeth upon the ignorant masses? Achieving true portability has absolutely NOTHING to do with these super-cool technologies that keep coming out; we are not going to suddenly say "Hey, this technology forces us to become 100% portable! Great!". In order to reach Frank Moss's nirvana of a standards-based technological society, we need to turn off the computer and sit down with our listening caps on and talk to each other. Apparently this has been tried before, but a rather big company keeps foiling the process...