Michael Nascimento Santos's Blog

Stop the hype about webservices!

I know, I have never been really aggressive in any of my posts. The problem is that, even though there are some wise people - I am not wise, I am just reasonable - telling people they are doing bad things, they keep on doing it. I ought to speak out, then. I have no choice. I can't see people doing something so irrational and still remain silently. Sorry folks, if this entry offends you, but this time it is necessary. It is for your own good. It's like taking medicine that tastes horrible; you don't like it, but it is for your own good.

So, what are webservices for? No, I am _not_ talking about technical definitions here. The real question is: what are webservices meant to be used for? That's hard to answer. So, I'll explain to you what most are missing by answering the simpler question, in my opinion: what are webservices not meant for? Let's go for a couple of examples:

• Webservices are generally not the right technology for integrating two systems written in Java. Yep, that is a fact. If that is what you are using webservices for, you probably should forget about it. It is very likely you are just wasting time: CPU time and development time; you are also wasting network bandwidth. Why do you insist on using webservices for that? If two people can speak English fluently but are very bad at Japanese, so bad that if they see anything in Japanese they have to translate it to English word by word in order to understand it and if this process takes a considerable amount of time, do you really think they should talk in Japanese, even knowing they will never improve their ability to speak in Japanese by doing so? It may surprise you that most people using web services are, in effect, doing just this double translation every day. If you are one of those, please, explain it to me. I don't get it. So, maybe you intend to keep your systems loosely coupled. I understand that. But let me ask you some questions:
  1. Should they be loosely coupled in first place? Sometimes two systems are so tightly coupled that they should be just one system, to begin with. This usually happens in big companies, where political reasons force two groups to buy two solutions from two different vendors to solve two parts of the same indivisible problem that cannot be addressed separately. A sad reality, though.
  2. Doesn't plain old RMI solve your problem? Think about it and tell me why it does not. If you come up with a good answer that is not "RMI limits me to using Java" and that cannot be applied to webservices, maybe you have a point.
• Webservices are generally not the right technology for integrating two systems for which there are better forms of integration. I am totally in favour of maintainability. I am not telling you to use plain sockets for anything not extremely simple. Have you ever heard of RMI/IIOP? J2EE containers support it; so, you have intrinsic support for CORBA in J2EE. Generally, the "other side" also supports it. It has been there for a very long time, its implementations are very stable, its a binary protocol. Why not using CORBA? Just because it isn't hype?

In my own experience - and what my friends have been telling me just proves me I am not wrong -, XML processing takes from 25% to 95% of the total processing time for most usages people are making of it. It is perfectly ok to use XML for configuration; it is generally parsed while your application is starting up, so, there is no real overhead to the end user if it's correctly implemented. But people are using XML - not just webservices - for a lot of reasons; they are using it for generating HTML when JSPs, Velocity or whatever would be faster and simpler by far. Then, they say: "it is easier, because designers don't have to deal with Java". Is it really a good reason? Let me see: you have to convert all your objects to XML - a slow marshalling operation, in most cases -, then someone has to write XSL - if it is the designer who writes it, I am sure s/he would get JSP, JSTL and Velocity; if it is the developer, s/he has to constantly rewrite it as page design/flow changes - and a big bloated XSLT processor has to run - don't tell me that just because now you can compile xsl it is better than plain old Java code. Are there any advantages if you are using Java in both ends? Don't tell me about future uses; future uses may require overhead. I am talking about the system you are writing right now.

There are some situations where using webservices might be wise; if you are integrating with .NET, they might be a good choice - note that they might; it does not automatically mean they are the only technology for the job. There are some other uses, which I am not going to talk about here - as I said, this post is about when not to use webservices. There are some binary formats for webservices, but as far as I could use them and heard people talking about them, the only impression I get is they are still slower than RMI. Webservices might be a good choice for situations where you don't know in what language your clients will be written. Even in such cases, it won't hurt if you expose some plain old interfaces and maybe RMI interfaces too. In fact, a lot of systems will perform better. No, there is no maintainance nightmare here because RMI interfaces and WSDL should be automatically generated. Period.

If you are still concerned about loosely coupling, think: What really makes systems loosely coupled? Interfaces. That is it. Integrate your systems using interfaces and provide them for whomever wants to call your code. If you are using EJBs, use local interfaces until something forces you to use remote interfaces. Use business delegates to access them and make each of their methods throw a CommunicationException and have a factory for building their instances. Why? If your backend implementation uses local interfaces, CommunicationExceptions will never be thrown, but your code will have to handle them. When - if necessary - you change to remote calls, your system will keep working, because it was ready for handling those exceptions! Then, if you have to use webservices because someone decided your backend should be written in .NET, you are still safe! Isn't that great? I'll give you one more tip: if you design your systems using naming conventions and standards, you may be able to implement all your factories and business delegates using dynamic proxies! It'll take less than 100 lines of code and your architecture will be prepared for future changes!

To sum up, If you are going to use webservices, think before doing so; it is very likely there are better options.

Comments

• Web services provide flexibility for businesses
  Web services are primarilly for businesses to interact with other businesses.

  Your company may be Javaholics, and your current business partners may be Javaholics, but would you really want to build a solution that is tightly coupled to how your current and future partners choose to implement their solutions?

  My company exchanges information with hundreds of schools and lenders with remarkably varying levels of IT skills. We have to interact with systems from a variety of vendors and numerous home-grown solutions. It's not a nightmare, but it's not pretty either.

  This is the environment where web services belong. Agree on the interface, and we don't care how you implement your back end (Some of ours is really COBOL).

  Posted by: johnreynolds on January 09, 2004 at 08:19 AM

• Re: Web services provide flexibility for businesses
  Ok, that is a point. But tell me why CORBA is not an option; or why Java clients must invoke your system using the slowest possible option.
  I never said shouldn't use webservices; the point is most people are using it for the wrong reason. Even COBOL has support for CORBA; it is not an excuse!
  The wizard that generates a CORBA compliant code is as easy as the one that generates webservices stuff. Why I should I go for the slower option?
  Webservices are definitely a choice when you don't know at all what you have at the other side. But they are so easy to generate nowadays you should only develop them when there is evidence they are needed.

  Posted by: mister__m on January 09, 2004 at 08:24 AM

• Re: Web services provide flexibility for businesses
  BTW, I've deployed webservices in production a couple of times: in the first one, the webservice consumer was a .NET application (why are Microsoft guys so stubborn they cannot provide decent support for CORBA??). In the other situation, there was already another system that relied heavily on webservices. We needed to call lots of services there and to implement a webservice as a "callback" mechanism (like a listener). I had to "register" myself by calling one of their webservices, giving them, as a parameter, my "listener webservice" URL. I have done tons of things after, but none really required webservices (and most didn't need remote EJBs also).
  The point is: stop the hype! Use it when you need it! Don't pretend webservices are "the" way to integrate two systems and that they are going to save the world!

  Posted by: mister__m on January 09, 2004 at 08:31 AM

• Re: Web services provide flexibility for businesses
  I don't think ranting and using excession exclamation points is going to achieve much. You have to remember that developers are not the people who create the hype, it is the marketeers, who I doubt are reading your blog.

  Posted by: jbjk on January 09, 2004 at 08:43 AM

• Re: Web services provide flexibility for businesses
  I know developers don't create the hype, but most of them follow it. Some marketeers are technical folks who use falacies, incomplete information and other strategies to convince others. I'd say that if I ask developers today what is the best technology for integration they'll say: "It's definetely webservices!" instead of saying: "it depends; there are many options with different applicabilities".
  About ranting, I don't think I did it; I recognised there are situations where webservices are the best - or the only - solution for a problem. Others have tried to expose their strong opinions against webservices without success; at least I hope people will read this and think about it.
  I am pretty sure that most people wouldn't think of anything else but webservices and sockets when it comes to integrate two systems, one of them not written in Java (and they'd choose webservices, for sure). I'm just trying to open their eyes so they can see that generally, there are other (much better) options out there.

  Posted by: mister__m on January 09, 2004 at 08:52 AM

• The hype is receding, the information is rising
  I totally agree that web services were overhyped. I also agree that the real costs of XML processing need to be weighed against the benefits on an application by application basis. The point about the most efficient communication is in the native language of the parties is well taken. Still, I think you're missing some important points that at least need to be considered and which XML/Webservices can provide useful perspective.

  First, do you really want to model your system as distributed *objects*? Maybe that's a "well, duhhh!!!" question for most Java developers, for whom "" when - if necessary - you change to remote calls, your system will keep working" is a compelling story. But keep in mind the situations in which a distributed object architecture is not well suited; see esepcially http://research.sun.com/techrep/1994/abstract-29.html and http://weblogs.cs.cornell.edu/AllThingsDistributed/archives/000343.html

  Second, can you really and truly assume that the rest of a distributed system is written in Java or supports CORBA? Maybe a lot of people really can, but I bet a lot of others are going to suffer serious career damage from decisions that lead to "Can't do that boss, the company we just acquired/partnered with/sold stuff to has to rewrite their code to support RMI or CORBA before we can integrate" conversations down the road.

  Third, there really is something beyond the hype about "service oriented architectures" "loose coupling", "integration via document exchanges." and so on, and XML and the Web services technologies support these approaches much better than native Java does. You're right in insisting that this not be a blind "the hypemeisters lead, I MUST follow" choice; these architectural decisions should be made on the basis of engineering analysis and not ideology or conformity. But make sure that the engineering criteria you use are the ones that matter: XML processing overhead doesn't matter much in an underutilized server, or in a world where Moore's Law means that it's often cheaper to buy more hardware than more development effort. Likewise, loose coupling doesn't help if the value you add comes from deep integration with a particular platform (e.g., OS X Just Works better for end users because it is more tightly coupled to the hardware than Windows is, I bet). But these have to be concious choices, not default assumptions that the easy path is the best path.

  Posted by: mchampion on January 09, 2004 at 10:40 AM

• Re: The hype is receding, the information is rising
  > Still, I think you're missing some important
  > points that at least need to be considered
  > and which XML/Webservices can provide
  > useful perspective.

  Don't think so; I've said webservices have their applicability more than one time. Also, notice I emphasized 2 common cases: java 2 java and java 2 language supporting corba; i never said it was not suited for all the programming languages or environments (especially the ones Microsoft created). I've even stated it is a real option for .NET integration. As I said, this blog entry is about when _not_ to use webservices; I never said I'd enumerate possible good reasons for doing so, although I mentioned a couple of them.

  But let's answer questions:

  > First, do you really want to model your
  > system as distributed *objects*?

  That was one of the first questions I asked. Look for it in my blog, when I talk about Java to Java integration.

  > But keep in mind the situations in which a
  > distributed object architecture is not well
  > suited; see esepcially
  > http://research.sun.com/techrep/1994/abstract-29.html and
  http://weblogs.cs.cornell.edu/AllThingsDistributed/archives/000343.html

  Of course there are situations when it is not suitable. But there is absolutely _nothing_ that can be done with webservices that cannot be done otherwise. I'm not saying, though, that you should ignore webservices. They have their value. For my technique about switching from a local to a remote mode just by changing interfaces to work, you need to:

  - Always programming thinking it _is already_ remote. This means you have to keep in mind there might be latency, that if you call many service methods - yeah, I'm talking about service oriented architectures here but not about webservices; they don't need to be kept together - you make experience performance problems etc. If you model everything in a way that you keep the number of iteractions between your code and the service layer minimum - by implementing your service layer as a facade to what it really does - and if you assume you can't modify input parameters in your service implementation - something that will probably be true when you change to remote mode -, you'll be, in general, safe. I've done it sometimes and it worked beautifully.
  Webservices, as they are being used by most developers, can be viewed, in a simplistic way, as glorified stateless session beans. There is no difference between them, except that they are slower by far. However, I know you can use webservices in different ways; most of the other are using them as a glorified message integration scheme. Really, think about it. That's the only real use most people are making of them. I am sorry to admit it. They do have other applicabilities, but most folks are using them when they should be using Stateless Session Beans and/or messaging technologies, such as JMS/MQ. So, if you have a different scenario - .NET, for example - then they may be useful, or if you have a different use case that requires them.

  > Second, can you really and truly assume
  > that the rest of a distributed system is
  > written in Java or supports CORBA?

  If those are the requirements, yes. If that's what the costumer needs, or has today, yes. XP folks keep telling you: do the simplest thing that could possibly work. So, if someone says these are the only integration platforms, what is the simplest answer?

  > Maybe a lot of people really can, but I bet a
  > lot of others are going to suffer serious
  > career damage from decisions that lead
  > to "Can't do that boss, the company we just
  > acquired/partnered with/sold stuff to has to
  > rewrite their code to support RMI or CORBA
  > before we can integrate" conversations
  > down the road.

  If they offer webservices, you can call them. This doesn't mean you should base your entire architecture on webservices because someone might. What if it was the opposite? Would you fire .NET employees if they said:

  "Can't do that boss, the company we just acquired/partnered with/sold stuff to has to rewrite their code to support webservices before we can integrate"?

  Don't think so. And also, notice: it's sooooo easy to generate webservices from existing Java code that you shouldn't worry about it. If you defined a consistent architecture, a next-next-finish wizard will do the hard "integration" job. It is all about designing interfaces properly, as I said.

  > Third, there really is something beyond the
  > hype about "service oriented
  > architectures" "loose coupling", "integration
  > via document exchanges."

  Service oriented architectures and loose coupling are good things and are not tied to webservices. You can tightly couple applications and not having real services at all with webservices, as well as you can have both things without them. About document exchanges, assynchronous and synchronous messages have been there for ages.

  > XML and the Web services technologies
  > support these approaches much better
  > than native Java does

  Prove it. And tell me why integration via document exchanges is so good. Really. I don't mean to offend you; if I did, that's probably because I'm not a native speaker (that is pretty obvious, I guess).

  > XML processing overhead doesn't matter
  > much in an underutilized server, or in a
  > world where Moore's Law means that it's
  > often cheaper to buy more hardware than
  > more development effort.

  I've recently seen machines reaching 100% of CPU consumption to handle _one_ request. These were good machines. Believe me. Of course, you need to profile your code before saying it's going to be so bad in your case.

  To sum up:

  - Webservices are useful, but they bring us nothing really new. Really;
  - They must be used in some situations, such as when you have to integrate with .NET or a platform that does not support CORBA or other options;
  - If all you have to do is Java to Java or Java to CORBA compliant integration, forget about webservices unless your company is rich or you're trying to learn how to use the "new hot technology" :-D
  - SOA and loose coupling are great; design with these in mind and remember: they have nothing to do with webservices;
  - XML processing still hurts a lot; don't minimize its overhead;
  - Webservices interfaces for a whole system can be automatically generated in a couple of hours or days if it was properly designed;
  - You must know how webservices work and you must have a deep understanding of both your problem and your current platforms before deciding which tecnology is the best for you.

  Again, I didn't mean to offend you, but I don't know if I did not. In case I did, I apologise to you in advance.

  Thanks,
  Michael

  Posted by: mister__m on January 09, 2004 at 11:40 AM

• Confusion about services and web services
  It seems to me that you're talking about web services being inappropriate as a goal in and of themselves - while not complaining about SOA. That's sort of good, sort of bad. SOA is a great idea. Web Services... well, I'm not a fan of th hype becase people start focusing on the transport layer (i.e., the Web port, SOAP) and ignore the real bite - which is in the services themselves.

  For myself, I don't care how a service is invoked. Done right, it doesn't matter. XML-RPC? Fine. SOAP? Dandy. RMI? Done. EJB? No problemo. Focus on those, though, and I start getting the screaming meemies - as you seem to have done.

  Posted by: epesh on January 09, 2004 at 03:15 PM

• Re: Confusion about services and web services
  I don't care while I'm writing code that is calling a remote object, but I do when it is time to define how this remote object will be implemented.

  I love SOA; it's just great. If you design your application to expose services, then, it should be ridiculous to implement a webservice if needed. I am glad that you'll able to see the difference between them.

  My point is: why my services have to be accessed using the worst existing technology for doing it? For most things people are doing, webservices are the worst technology. They may not always be a bad choice, though, as I already pointed out.

  Posted by: mister__m on January 09, 2004 at 03:21 PM

• Re: The hype is receding, the information is rising
  > Webservices are useful, but they bring us
  > nothing really new. Really;

  Yes. The only thing new is the support of roughly the same technology by *all* enterprise vendors, but the ideas themselves could have been implemented with CORBA, SGML, etc. 15 years ago.

  > They must be used in some situations,
  > such as when you have to integrate with .
  > NET or a platform that does not support
  > CORBA or other options;

  We agree.

  > If all you have to do is Java to Java or Java
  > to CORBA compliant integration, forget
  > about webservices unless your company is
  > rich or you're trying to learn how to use the
  > "new hot technology" :-D

  Fair enough, but I guess I'm a bit less certain that you can KNOW in advance that you will ONLY have to deal with Java or CORBA apps on the other side. I guess I'd rather say to the boss "sorry, you need to buy more hardware to get this platform-neutral solution to work well" than "sorry, we're dead beacause we chose a the wrong platform given the business realities."

  > SOA and loose coupling are great; design
  > with these in mind and remember: they
  > have nothing to do with webservices;

  Welll, I won't agree to *nothing* to do with webservices, but I acknowledge that "support these approaches much better than native Java does" is an overstatement. It's a bit like saying you can't do OOP in C; of course you can, but it's a lot more natural in Java. It's a bit more natural to do SOA in SOAP than CORBA, more natural to do distributed objects in CORBA than XML.

  > XML processing still hurts a lot; don't
  > minimize its overhead;

  Well, I'm undecided on this. I keep meaning to write an article about this, but I can never quite decide what *I* really believe. There was a W3C workshop in September on this subject, and it turned into Sun+a bunch of little companies saying "XML has a LOT of overhead, we need to take this seriously" and MS, IBM, BEA on the other side saying "no problem that a bit of hardware and maybe better parsers can't fix." I'm trying to be openminded, but this is *definitely* something that designers have to consider more carefully than the XML/webservices hype has led us to believe.

  > Webservices interfaces for a whole system
  > can be automatically generated in a couple
  > of hours or days if it was properly designed;

  Good point! I hadn't considered that. One positive benefit of the webservices hype is the availability of good tools. A lot of us seem to be saying "design with SOA in mind, implement with whatever transport-level technology works best."

  > You must know how webservices work and
  > you must have a deep understanding of
  > both your problem and your current
  > platforms before deciding which tecnology
  > is the best for you.

  Absolutely. That is the bottom line in all these discussions. Maybe in my typical environment XML is typically the right choice, in yours it may typically be the wrong choice, but it is something to decide, not assume, based on real understanding of the alternatives.

  
  > Again, I didn't mean to offend you

  Not at all! Thanks for the informative reply.

  Posted by: mchampion on January 09, 2004 at 04:48 PM

• Re: The hype is receding, the information is rising
  > Yes. The only thing new is the support of
  > roughly the same technology by *all*
  > enterprise vendors, but the ideas
  > themselves could have been implemented
  > with CORBA, SGML, etc. 15 years ago.

  The problem is Microsoft brought COM to the world and then they scrolled up CORBA. They are only commited to standards if they can take advantage of that - not if users can. So, blame Microsoft for CORBA not being "the integration miracle".

  > Fair enough, but I guess I'm a bit less
  > certain that you can KNOW in advance that
  > you will ONLY have to deal with Java or
  > CORBA apps on the other side.

  It's simple: always make a generic interface available for everything that should be exposed and only make a remote available if _needed_. It is _very_ simple to make RMI, CORBA or webservices stuff available if you comply with some rules from the start.

  > I guess I'd rather say to the boss "sorry, you
  > need to buy more hardware to get this
  > platform-neutral solution to work well"
  > than "sorry, we're dead beacause we chose
  > a the wrong platform given the business
  > realities."

  I'd rather say: "it's working 3 times faster than if we had a machine two times more powerful. And let tell you more: if we ever need to support clients who can only consume webservices, it'll take a couple of days to get this ready!". I think it sounds better :-D

  > Welll, I won't agree to *nothing* to do with
  > webservices.

  I meant it as in: one thing does not implies the other. Bad sentence, though :-D

  > It's a bit like saying you can't do OOP in C; of
  > course you can, but it's a lot more natural in
  > Java. It's a bit more natural to do SOA in
  > SOAP than CORBA, more natural to do
  > distributed objects in CORBA than XML.

  Sorry, but I can't disagree more. Implementing OOP in C without greating a whole new language or weird and unnatural constructions is very unlikely, not to say impossible (I always expect things are possible :-P); I can implement SOA naturally in pure Java, RMI, EJB, CORBA and others and I honestly can't understand why you say it is not natural. Could you please give an example?

  > Sun+a bunch of little companies
  > saying "XML has a LOT of overhead, we
  > need to take this seriously" and MS, IBM,
  > BEA on the other side saying "no problem
  > that a bit of hardware and maybe better
  > parsers can't fix."

  My only comment about that, for commercial reasons: why BEA said such a thing? They are among the most rational people on the market :-D

  > One positive benefit of the webservices
  > hype is the availability of good tools. A lot of
  > us seem to be saying "design with SOA in
  > mind, implement with whatever transport-
  > level technology works best."

  That is the point. And, as webservices hardly ever work best, don't use them until they are needed. :-D

  > Absolutely. That is the bottom line in all
  > these discussions. Maybe in my typical
  > environment XML is typically the right
  > choice, in yours it may typically be the wrong
  > choice, but it is something to decide, not
  > assume, based on real understanding of
  > the alternatives.

  That is it. But, from your comment, I hope .NET clients are a reality for you or that you have a _very good_ for using XML :-D

  > > Again, I didn't mean to offend you

  > Not at all! Thanks for the informative reply.

  I am always worried about this stuff. I'll be waiting for your comment about SOA not being natural to implement in other distributed technologies.

  Cheers,
  Michael

  Posted by: mister__m on January 09, 2004 at 05:11 PM

• Re: Web services provide flexibility for businesses
  I totally agree with Michael. Not only I think Web Service is too much hyped, but also I think XML itself is somewhat too.

  The idea of XML is to create a data format for COMPUTER SYSTEMs to interexchange data. We all know computer handle binaries, so why use a format that is all text? You can argue plain ASCII text can ensure compatibility among different kinds of systems from PC to old mainframes, then why those text Tags? The only explaination is XML must also be readable by HUMAN BEINGS. But do we really need to read any XML data when they are transfering among machines? I only make intermediate data readable to me when I need to debug my program. I surely don't want my production data being transferred in debug mode.

  I was working on a messaging middleware. We were using XML-RPC as communication protocol amoing client apps and server. Client could be written by Java, C/C++, VB, Delphi on both Windows or Unix platforms. Seams like XML-RPC( similiar to SOAP as you know) was a good choice for us. But while the project went on, I encountered some critical problems:
  First of all, performance problem. Messages must be going accross network in XML format, the encoding/decoding/transmition overhead made the communcation slower than normal JMS/MQ/CORBA based systems.
  The second problem was XML-RPC is built upon HTTP which is stateless communication protocol and every time a remote call is invoked, a new socket connection must be established. That slows down the speed a lot too.
  The third problem was since need to build a new connection on each call, socket was not released right away( at least on Windows ), so if messages are sent too frequently(more than a few hundreds per second), no more socket connection can be made, and communication just failed.
  I never tried it on WebService platform, but as far as I understand, web Service is based-on SOAP for communication and SOAP is similiar to XML-RPC, I guess it will create the same problem as we had. Because of those problems we changed our communication layer to plain socket. With a dedicated socket connection, all the problems above were easily gone.

  We all know WebService was build above HTTP. And HTTP was not designed for system integration at all. So why do build a new technology on something we know that is not suitable to resolve our problem?

  If you argue about Moors law, I agree CPU are running faster, 1000M network is getting popular, but what about those WIFI connections and devices? Actually, as a matter if a fact, I do like the idea of WBXML than XML. I think WBXML is more compact, take similiar CPU power as XML but canbe transfered much faster than it. And WBXML is extactly the thing I would like to use for communication among any systems, not only for wireless connections.

  Finally I have to say, my English is even worse :) So, hopefully, I expressed my points clear here.

  Li

  Posted by: li_ma on January 09, 2004 at 05:44 PM

• They are popular because they are messy
  Hi, Michael; interesting article. I think the main reason web services have become so popular--apart from the massive marketing effort on Microsoft's part, primarily--is that they are a great big hack.

  Companies have spent a lot of money in the last ten years or so to retool themselves for the so-called internet age. Ten years ago your average large corporation was not set up, from an IT perspective, to interface with the outside world at all. Now pretty much any Fortune 500 company you go to has an IT architecture that includes firewalls, demilitarized zones, web servers, application servers and the like. One of the things to fall out of all this frenetic hard work was today's effective corporate firewall standards: port 80 is the only port open, in or out, in the whole enterprise--and, on the flip side, you can always count on port 80 being open and the IT infrastructure in general set up to do HTTP. Like anything else that has solidified in the corporate muck, that's not going to change anytime soon.

  Enter web services. You use the same port that's already open and monitored, you can take advantage of the same HTTP security tools that the company probably already has, the same firewall settings, the same document-centric paradigm that the web already has caused to be solidly entrenched in your average large company. You just kind of put all of these things to slightly hackish uses.

  Anytime something smells like a hack, it is going to get popular, because hacks are easy and by definition solve a problem with a minimum of fuss (hmm, smells a bit like XP, which is really a formalized way to hack something out as fast as possible, trading design up front for hardheaded testing). Web services, much as I dislike them from a purist standpoint, let me exchange information with another company regardless of firewall settings, language, little-or-big-endianness, or platform. They are moderately fat, truly ugly, slightly foul-smelling, and get the job done.

  Also, notice that apart from the basic implementation of web services, most companies are not availing themselves of anything other than the hackish side of things: UDDI is not the panacea it was promised to be, WSDL is only used insofar as it is absolutely necessary, etc. Companies use web services because they make firewall punching and information delivery possible without forcing either side of the pipe to change.

  What I'd like to see is some kind of formalization (or marketing effort) of the other way to punch through firewalls: a combination of SSH and HTTPS proxy servers. Make that as plug-and-play as web services' ability to shove a bunch of extra information down the port 80 pipe, and you've got something more powerful, and just as hackish (in a good way).

  Cheers,
  Laird

  Posted by: ljnelson on January 10, 2004 at 07:43 AM

• Just another tool for the toolbox
  I think more and more people are starting to realize that web services are over-hyped. However, they are just the newest entry to in the field of over-hyped technology. In the end, web services (minus UDDI and others that aren't really being used widely) is nothing more than a new RPC protocol. As an RPC protocol, I think it has value, especially given the massive standardization and interoperability discussions that are ongoing. Is it the most efficient? No. Is it set to become a "lowest common denominator" communication mechanism? Yes. It is good to have such a lowest common denominator. True, it is going to be abused by people who really don't know what they are doing, but as a communication protocol, I am happy to have it as an option in my toolbox.

  Just because we can't protect some people from using the tool for the wrong thing doesn't mean that we shouldn't count it in our inventory of tools to consider when trying to solve a problem.

  
  As an aside, I think it will be funny someday when the original meaning for SOAP (Simple Object Access Protocol) is lost and some genius realizes that it can also spell "Service Oriented Architecture Protocol". (I mean, frankly, the acronym doesn't really apply anymore: Its not simple and its really not "object based"... That just leaves "AP"... not a very catchy acronym) For myself, I know that this sort of thing is exactly what the techno-idiot decision makers at my company would latch on to as they try to make sense of the multi-million dollar technology investments employed from the 90s for achieving a "distributed architecture" - ie. hub and spoke, adaptive architecture, etc.

  Posted by: tlaurenzo on January 10, 2004 at 09:10 AM

• What are web services for?

  First, I am not a web services afficianado. I have never built a web service for a production application.

  Often when people say that web services are just a copy of CORBA, and that CORBA can do the same job, they do not understand entirely how these technologies are different.

  I do not blame anyone for not knowing the difference because most of the vendors do not seem to promote the real benefits of web services. The first thing you are going to see is how to bind an object to be come a web service (in otherwords the RPC stuff).

  Justly, the uses of web services are very limited in this space, unless you are going to integrate between Java and .NET. The realization is that while web services can be used to do RPC, the real benefits are elsewhere.

  The talk often turns to SOAs at this point, and it is a good example. A SOA could use a message bus between (web) services, which removes the concept of 'remote object interface' out of the equation. There are just messages, sources and sinks. This is a good solution if you want decoupled services that can be reused without creating awkward dependencies.

  Web services are a good solution for such a message based system because you now standardize on message formats and structures instead of objects and object interfaces. XML is good for describing the messages. XML is also good because it allows added level of flexibility for the messages: systems can still talk to each other even if the message format changes (e.g. new message elements are added). This is not true with CORBA: if you change the interface you have to recompile all clients! Now imagine that you have many systems that have to interact. Which solution is superior?

  It always comes up that the difference between web services and CORBA (or some other) is the granularity: WS work on the service level, CORBA works with objects. If this is true, then why would you ever even try to model web services as objects and object interfaces? IMHO that is not the right ticket for web services at all. But if you truely model them as services and use them in right context, you have a superior solution which is far more flexible and durable than anything that CORBA can offer.

  Just my 2c.

  Posted by: tvaananen on January 10, 2004 at 09:57 AM

• Re: The hype is receding, the information is rising
  > I'll be waiting for your comment about SOA not
  > being natural to implement in other distributed
  > technologies.

  I don't want to try to argue the point since I don't have solid experience with CORBA or RMI. You may be right, and in any event the important point is to stress the service abstraction, not the technology that could be used to implement an SOA.
  
  Here's a link to my attempt to define these things as part of the work of the W3C Web Services Architecture group. http://lists.w3.org/Archives/Public/www-ws-arch/2004Jan/0035.html
  (feel free to join that discussion, it's on a public mailing list, so as to set us straight on CORBA and/or distributed objects).

  Here's my reasoning, which may be flawed or based on faulty assumptions: Exposing some code as a "service" implies that the tasks implemented by the service are at a fairly high degree of granularity, for example "customer X wants to buy book Y', and not "construct a customer object, load it with data corresponding to customer id X; constuct a order object; instantiate it with data from the customer object and the SKU Y, invoke the executePurchase() method ...". Likewise, a service is typically decoupled from the implementation (e.g., the service requester doesn't need to share a detailed interface definition or type system with the service provider, just know what information to put in the request). Likewise, a service requester is likely to be asynchronously connected to the service provider; it's going to expect a notification sometime that the order was successfully processed, not block while waiting for confirmation of anything but that the request was received.

  I see your point that it is possible, and may even be best practice in the CORBA world to model remote objects at a high granularity, using interfaces that are "typesystem decoupled" between the requester and provider, and can be invoked asynchronously. I know that this is very natural in the XML world, and the webservices people are learning this lesson after flirting with more tightly coupled RPC-style interfaces.

  So, I won't argue that this is not natural to implement in other distributed technologies [although I assumed this previously] but I will argue that it works very well using XML and Web technologies, albeit with some performance overhead.

  Posted by: mchampion on January 10, 2004 at 10:59 AM

• Re: The hype is receding, the information is rising
  I'm glad we are know discussing SOA and how webservices, CORBA, RMI and other technologies can be used to implement it. SOA, as I said, is great, but definetely does not imply webservices. As I said before, it's all about design.

  About two years ago, I saw a .NET application which would make 10 webservices invocations just to get more details about a product. The sad part: the guys wrote both the client and the server and a simple COM invocation would do it all. Sad, but true.

  That's what happens when you use a platform that tell you: we are the only to support webservices! We embrace them and encourage their use; don't use COM anymore; the future is about webservices. I am sure webservices are going to be part of the future, but they'll not be _the_ future. Even COBOL will be around for a God-knows-how-long period. I hope people start to undestand most of them don't need to use webservices in any application they write for their companies. There are some people that may need them to expose services to the external world and very few developers need to use them daily for integration. I am not saying you should never use them in the same company, though; I am just saying most of the time you can safely ignore their existence.

  I think we share the same point of view: you should think very carefully about your architecture and your requirements. That is what is going to determine whether you need webservices, CORBA, RMI, JMS, plain old local Java or not. Don't worry about today's hypel tomorrow it'll be different :-D

  Posted by: mister__m on January 10, 2004 at 12:45 PM

• Re: They are popular because they are messy
  Your thoughts are very consistent and meaningful, thanks for joining this discussion. I am just sorry to say small companies, with very simple IT infrastructure, that write all their applications, are using webservices for communicating their own systems who usually reside either on the same machine or in machines very close to each other! The most astonishing thing is that, in most cases, both applications are J2EE based! For God's sake, this insanity must stop! That's why I felt compelled to write this piece.

  RMI/HTTP has being around for a very long time and is feasible in a variety of occasions - not all. Webservices are not to be used as an enhanced RPC or messaging technology; they are about exposing services or, maybe more especifically, decoupling the way services are implemented from what they do. They are suitable in a lot of occasions. I'm not against webservices; I'm against the hype. If they are used properly, they can add great value to you.

  I am not saying you shouldn't consider using them if you have firewalls and some limitating network factors. If latency is high enough, the time it takes to unmarshall and marshall things again may be insignificant; the only problem, then, is CPU consumption. Depending on your specific needs, they can be the best solution for your problem. But people should not think of them as an easy way to bypass the firewall or, otherwise, they may bring down their entire network.

  Posted by: mister__m on January 10, 2004 at 12:54 PM

• Re: Just another tool for the toolbox
  > In the end, web services (minus UDDI and
  > others that aren't really being used widely)
  > is nothing more than a new RPC protocol.

  That's a common misconception and that's why most people are doing bad things with webservices; they are not meant to be used as just a RPC protocol. Otherwise, you're using the slowest technology for the job - that's exactly what most people are using them for.

  > as a communication protocol, I am happy to
  > have it as an option in my toolbox.

  SOAP and REST can be very useful in certain situations. It's good to understand when to use each of these technologies and how they compare to existing solutions.

  > Just because we can't protect some people
  > from using the tool for the wrong thing
  > doesn't mean that we shouldn't count it in
  > our inventory of tools to consider when
  > trying to solve a problem.

  Totally agree. That's why I am working in a JSR - 207 - that is related to webservices :-D

  Webservices are neither bad nor evil. The problem is how they are being used. I doubt most Java programmers would need to use them if Microsoft wasn't over-hyping it. Now, there are some .NET applications implemented by big companies that really entirely on them.

  I like your analogy. Tools can be very productive if know how and when to use them. Otherwise, you may hurt yourself and others so badly you'll regret forever...

  Posted by: mister__m on January 10, 2004 at 01:05 PM

• Re: What are web services for?
  > Often when people say that web services
  > are just a copy of CORBA, and that CORBA
  > can do the same job, they do not
  > understand entirely how these technologies
  > are different.

  > Justly, the uses of web services are very
  > limited in this space, unless you are going
  > to integrate between Java and .NET. The
  > realization is that while web services can be
  > used to do RPC, the real benefits are
  > elsewhere.

  Exactly. I couldn't agree more. CORBA is about distributed objects and RPC; webservices are not about that, although they are a very good choice if you are willing to build the slowest possible RPC implementation :-D Microsoft seems to encourage this :-D

  > A SOA could use a message bus between
  > (web) services, which removes the concept
  > of 'remote object interface' out of the
  > equation. There are just messages,
  > sources and sinks. This is a good solution
  > if you want decoupled services that can be
  > reused without creating awkward
  > dependencies.

  It may be a good solution, but if you have Java in both ends, good interfaces, stateless session beans, JMS and/or MDBs are generally a better way of achieving the same results.

  > This is not true with CORBA: if you change
  > the interface you have to recompile all
  > clients!

  Never tried it with CORBA, but with RMI, the result is the same you would get with webservices: if you change your client to require different things, you have to change the server application; if it's the other way, your client will just ignore the changes.

  > Now imagine that you have many systems
  > that have to interact. Which solution is
  > superior?

  It depends on what you are changing and how it impacts the current operation you're trying to achieve. In some situations, there is absolutely no difference; in others, XML will, indeed, add more flexibility. We shouldn't take it as a general truth, though.

  > It always comes up that the difference
  > between web services and CORBA (or
  > some other) is the granularity: WS work on
  > the service level, CORBA works with
  > objects.

  I totally agree. The problem is developers are using it as just some glorified RPC.

  > If this is true, then why would you ever even
  > try to model web services as objects and
  > object interfaces?
  > IMHO that is not the right ticket for web
  > services at all. But if you truely model them
  > as services and use them in right context,
  > you have a superior solution which is far
  > more flexible and durable than anything that
  > CORBA can offer.

  An interface is a contract about what you expect to get from the caller, what you will do and what you will return. Objects are not services, but services can be implemented as objects. So, if you design interfaces for services and implement them with stateless session beans, MDBs, RMI, CORBA, POJOs or webservices, you are safe if you chose the technology for the right reason.

  Webservices are more flexible when XML parsing time and resource consumption is not relevant to your problem and you want to be even more decoupled from the implementation or to exchange _messages_ with a different system. Then, I agree they are more flexible. The problem is this does not describe how it's being used nowadays.

  Posted by: mister__m on January 10, 2004 at 01:23 PM

• Re: Web services provide flexibility for businesses
  Well, maybe the marketeers create the hype, but I hope in your company technical people still decide the right technology to adopt.

  I feel this discussion is interesting and that we could easily had substituted the words "web services" with the word "EJB". Stop the hype about EJB. Why I feel there are so little situations where we really need EJB (and even less situations where we need to distribute our objects)? Am I biased? I feel sometimes marketeers are leading the Java side, not only Microsoft's. I feel that most times I only need someting like Spring, Picocontainer (and what about the nearly-forgotten JINI?). What's your opinion about the EJB hype?

  Personally I agree about XML: there are plenty of I-put-XML-everywhere people around. Most times plain Java Properties are all I need. And, of course, XML was born to be human-readable, not machine-friendly, so I perceive someting wrong in all this XML radicalism.

  Posted by: mkj6 on January 10, 2004 at 07:00 PM

• Re: Web services provide flexibility for businesses
  > I hope in your company technical people
  > still decide the right technology to adopt.

  Most of the times, they do, but lots are influenced by what marketeers say.

  > Why I feel there are so little situations
  > where we really need EJB (and even less
  > situations where we need to distribute our
  > objects)?

  "Need" is a very hard word to use in this context. I'd say EJBs are suitable in a number of situations, but there are folks out there using them when they shouldn't. I do like EJB, I don't think it should use them all the times and I recognise they have limitations, but they can add great value in lots of occasions.

  After some time working with entity beans - especially CMR -, for example, I'd say it was a good choice to use them every time I did it, but they are limited, as when you need to switch vendors. It may be easy to reconfigure 1 entity bean by writing a new vendor-specific file, but it's _not_ that easy when you have more than a hundred of them - oh, yeah, the application performed pretty well, thanks. :-D

  Of course you have alternatives - Hibernate is great, for example, and I really like it -, but they have different approaches. At the end of the day, it's all about architecture and design. I am _not_ saying entity beans are better or worse than Hibernate; I'm just saying each technology has its own benefits and shortcomings. Know them, know when to choose the best for your specific project and do it wisely.

  Session beans and message driven beans are also useful, but not always needed.

  I wouldn't say there a little situation where you need EJB; I would say there are very little situations where you need the _whole_ thing. Stateless session beans seem to be useful many times.

  Using plain EJBs - without a framework, helper classes, dynamic proxies for some tasks etc. - is an overkill most times. So, if you won't have time to build the infrastructure or if you won't have enough budget to buy it, alternative solutions seem to be the obvious choice.

  About your local vs distributed comment, I am in favour of: design for distributed, implement locally unless there is evidence distributed mode is necessary.

  > I feel that most times I only need someting
  > like Spring, Picocontainer (and what about
  > the nearly-forgotten JINI?).

  All the three are very cool, but they can take a lot more work. These days I have been thinking if using PicoContainer instead of EJB in a specific case would be better. Then, I thought about all the stuff I was using from the EJB container that I needed and I realised that, even if I used some open-source projects as implementations of these services, I would have to write tons of extra code to make things work. I would also need to use an AOP framework - such as AspectWerkz - to get it working. Then, I came to the conclusion it wouldn't be that simpler than using EJB for this application. I can't say it wouldn't be simpler, but it wasn't worth the effort.

  Someone told me we need an "EnterpriseContainer" implementation of PicoContainer. That implementation should be more flexible and more lightweight than an EJB container and adding and removing things should be easier. It sounds a lot like JBoss to me; that proved me EJB is valuable, indeed.

  I am not saying Pico is worthless; it's quite nice, but you need it when you don't need EJB; some projects really do need them, that's the point. I think it all depends on the type of projects you work on. In my case, there are very little situations where Pico would be a simpler alternative when you think about infrastructure. There is no point in saying "you can write whatever and just what you want" if what you want is, in fact, an EJB container.

  Jini applies to different things - they are closer to webservices than to EJB - and I agree with you some projects would be far better using them than using EJB.

  To sum up, don't use EJB just because everyone is doing it; maybe it's right for you, maybe not. Maybe session beans are generally useful, entity beans are not always a good choice and a couple of message driven beans might be handy, but, please, don't think they'll save the world. You may live better or suffer a lot without them. You'll find out if you don't base your decisions on what's cool for the industry nowadays.

  Posted by: mister__m on January 11, 2004 at 09:36 AM

• Re: Web services provide flexibility for businesses
  The worst possible situation is where developers start *believing* the marketing hype! Then the marketeers can sit back and laugh as us developers propogate the madness for them. How many job adds do you see along the lines of: "Must have J2EE/WebSphere/XML" rather than "Must have track problem of solving real world problems.".

  God help you if you are hired as for a "J2EE/WebSphere/XML" job and you examine the problem and go "Hey guys, this just requires a simple Java-RMI interface to integrate these systems. I can fix one up this afternoon." That will go down like a lead balloon in the current web-services hype environment.

  Well done Michael for having the courage to speak out about this. As a developer community we need to encourage companies to utilise a problem solving approach rather than one based on using the latest tools and paradigms.
  

  Posted by: ashleyherring on January 11, 2004 at 10:00 PM

• Re: Web services provide flexibility for businesses
  > The worst possible situation is where
  > developers start *believing* the marketing
  > hype!

  Unfortunately, I have to call it "reality".

  > Well done Michael for having the courage to
  > speak out about this.

  Thanks. It really takes courage :-D

  > As a developer community we need to
  > encourage companies to utilise a problem
  > solving approach rather than one based on
  > using the latest tools and paradigms.

  Thanks for your reasonable comments. It's rare to find someone who understands each technology has its own applicability.

  Posted by: mister__m on January 12, 2004 at 05:19 AM

• Re: Just another tool for the toolbox
  >> In the end, web services (minus UDDI and
  >> others that aren't really being used widely)
  >> is nothing more than a new RPC protocol.

  >That's a common misconception and that's why
  >most people are doing bad things with
  >webservices; they are not meant to be used as
  >just a RPC protocol. Otherwise, you're using the
  >slowest technology for the job - that's exactly
  > what most people are using them for.

  I think I understand that the intent of the web services initiative transcends SOAP and the concept of being "just another RPC protocol" (ie. I have a SOAP book from a couple years before the term "web services" was even coined -- at least before I heard about it). However, I truly am failing to see where the rubber meets the road. I know there is more to it, but try as I might, I cannot work out when the use cases will actually be widely applicable. Granted, I may be suffering from tunnel vision here... but it is my lack of understanding of the vision that is forcing me into a wait-and-see, skeptic mode.

  Posted by: tlaurenzo on January 12, 2004 at 08:25 AM

• Re: Web services provide flexibility for businesses
  I agree, that's the point: looks like job offerings are prepared by marketeers. We always read long listing of buzzwords. Have you ever read "we require at least 5 years of X experience" and then you know that X technology was invented only two years ago?. My previous posting about the EJB hype was really about the fact that I have seen too many projects where technologies are used improperly.
  Many thanks to Michael for the interesting reply (and sorry for my english...)

  Posted by: mkj6 on January 13, 2004 at 06:53 AM

• Glad to hear it
  Finally, someone who agrees with our company policy for using Web Services!

  Posted by: dbuchwal on January 22, 2004 at 07:55 AM

• Re: Web services provide flexibility for businesses
  Thought-provoking discussion.

  Text tags in XML are used to organize semi-structured instance data into a hierarchy of types (e.g., per the W3C XML Schema spec -- elements, attributes, simpleTypes, simpleContent, complexTypes, complexContent, et al.). XML schemas, based on open standards, formalize types in a given problem domain into a 'vocabulary'. XML schemas are also used to validate instance data and to disambiguate types in one namespace from those in another.

  Because they have semantic content, XML types can be encapsulated in coherent messages -- that is, messages that carry metadata as well as data. Therefore, XML and XML-based technologies may be better suited (though admittedly less efficient) than RMI/IIOP for exchanging and/or integrating data among loosely coupled systems.

  Coders who demand efficiency often overlook the role of human cognition in computer programming ('marketeers' and hypemeister evangelists excepted).

  Perhaps binary XML is the best of both worlds, and we can put this argument to REST. (But see http://www.xmlmania.com/documents_article_57.php)

  jim_d

  P.S. (Reality Check): "WS-BusinessActivity Specification Completes the Web Services Transaction Framework. BEA, IBM, and Microsoft have released a third WS-* specification in the Web Services Transaction Framework. "Web Services Business Activity Framework (WS-BusinessActivity)" is designed to work in concert with WS-Coordination, WS-AtomicTransaction. WS-BusinessActivity defines protocols that enable existing business process and work flow systems to wrap their proprietary mechanisms and interoperate across trust boundaries and different vendor implementations."

  Posted by: jedeegan on February 08, 2004 at 12:10 AM

• Leitura cansativa
  Interessante o artigo...

  Eu sugiro que voce nao use paragrafos longos, para evitar que a leitura fique cansativa.

  []s

  Posted by: pinei on March 10, 2004 at 12:03 PM

• Why web Services? Many ponder and debate. Conceptually it makes sense to have loosely coupled distributed information system for better communication. Surely complex. Service oriented architecture suits when there are disparate information systems and need is to interact and colloborate to facilitate the business processes. Argument that XML is not too convenient and may be slow to efficiently design and transform into an effective communication system is shallow. Surely, the technology is emerging and improving. It would be naive to suggest to dump the technology that is promising and evolving. Why assume that most of the efficient systems are built on Java platform and there are very less of alternatives. Some of the older systems running on the various technology and platform are faily efficient and the need is of colloboration mechanism. Web services and SOA are surely in the right direction and are evolving to enable to have an effective communication and business processing system among the business partners using disparate information system. Complexity of the SOA systems today do not make these useless.
  

  
  regards,
  akshaya bhatia

  Posted by: aksbh on May 25, 2006 at 10:53 PM

• Michael's post says what I've been trying to say for years. At my company we use web services for java-to-java implementations because "we might want to integrate with .NET later". In the meantime we spend an exorbitant amount of time troubleshooting and updating the web services. People keep talking about web services and SOA without realizing that we already are a long way down that path with simpler and more proven technologies.

  Posted by: klumpbk on October 17, 2006 at 10:55 AM

This work is licensed under a Creative Commons License.