Web Services: More Smoke Than Fire


News: Web Services: More Smoke Than Fire

  1. Web Services: More Smoke Than Fire (19 messages)

    According a recent article on SDTimes discusses the alphabet soup of Web Services, provides a brief comparison of initiatives from Microsoft and Sun, as well as providing respite for all the worried J2EE developers who fear that Web Services will displace them: "For the Java world, you'll still need expert programmers who can handle J2EE, database integration, EJBs and security".

    Read Web Services: More Smoke Than Fire

    Threaded Messages (19)

  2. Hehe, again the "Web Services a doomed fad" topic I guess... but again, I think he is absolutely right... they are just middleware... not even. I don't understand why SOAP receives so much attention... its really not more than IIOP, maybe JRMP or T3 or whatever... every appserver vendor could do RMI-over-SOAP, so what's the great thing about it?
    And UDDI is also really nice but not even just another LDAP. XML based, okay, but hey, there are so many registries and directories out there, what is new about it?
    ebXML and BizTalk are really just another EDIFact, so again, nothing really new.
    I appreciate XML and WebServices will make everything easier, but they are definitely not the "new era", agreed.
    Howeverm, I'll not complain too much but instead ride the marketing hype ;-)

    so long,

  3. Reminds me of something I wrote far back in the October of 1999 in my Viewpoints Section - "The latest SOAP Opera"



  4. SOAP is a text-based protocol that can pass through HTTP firewalls, unlike IIOP or JRMP that are binary protocols. SOAP and web services provide the ultimate in inter-operability amongst heterogeneous technologies. I really hope SOAP replaces IIOP and JRMP for EJB communication.
  5. I also think that the appeal of SOAP is that it goes over HTTP, so you don't have to open up a firewall to use it.

    On the other hand, we could easily use IIOP or JRMP if a firewall could be configured to recognize IIOP and JRMP traffic. I don't think many firewalls have code that does this, and obviously sys admins don't want to open up an entire port and let everything through. It would be useful if someone wrote IIOP support for ipchains/iptables. Right now it probably only recognizes UDP and TCP.

  6. Meeraj,

    Don't believe the hype that much. Yes, SOAP is great to get across the firewall but why would you want to use it for EJB access. On the backend SOAP belongs to only one area: external coomunications. You want to expose your service or access another use SOAP but that's about it. There is a reason for IIOP, JRMI and DCOM being there. They are more efficient and compact than SOAP.
  7. Web Services: More Smoke Than Fire[ Go to top ]

    IMHO both models are useful. For b2b the use of http(s) is a strong advantage, but you will want to access only course grained services. Since iiop is more efficient it is more suitable for A2A communication and allow finer grained (but not too fine) services. However, the same story goes for native function calls. This, in turn, is more efficient than IIOP etc. etc.

    Everyone is already using web services in his own way, but the fact that a standard comes up is a good thing. The use of communication via the web will replace some proprietary technology and in some cases IIOP or COM-based solutions, but is foremost complementary to these technologies.
  8. I keep hearing this mantra... SOAP is a sad excuse for microsoft's failure to sit down at the OMG like hundreds of other vendors have and hammer out a middleware foundation we can all agree on.

    Anyway, I've always wondered by it's such a big deal to open the firewall for IIOP rather than rely on the IIOP vendors neat-o http-firewall-piercing gizmo. Are firewalls that inflexible???
  9. There have always been issues with IIOP and firewalls -- it's typically not the problem with the firewall per se, it's the fact that organizations are scared to open a firewall port for IIOP, because they don't know enough about it.

    Coupled with the fact that there are 5 or more competing "firewall integration" products which all handle stuff differently, and with the fact that the OMG can't standardize on something that *works*, it looks like people are punting.

    Steve Vinoski and Doug Schmidt wrote an interesting article on XML/SOAP versus CORBA, and most of the stuff is also exactly equivalent for XML/SOAP versus J2EE (well not necessarily "versus" but on the relative strengths and weaknesses of each). It's here:


  10. But then again SOAP travelling over http is just laughable... as I see it, companies were afraid opening an RPC port on their firewall (GIOP, JRMP, whatever) so the software vendors found a way to tunnel the firewall... great! Now http becomes "dangerous"... well, as dangerous as IIOP was before. Its just less compact (needs more bandwidth), can do less, is less flexible and so on. Until it is extended... then it will be as complex as IIOP (or even more complex, because of the overhead and XML not being an RPC protocol but general purpose). GREAT JOB!

    Sometimes it is just strange what happens in the software industry...

    kind regards,

  11. It seems to me that the most harshest criticism of Web Services come from those of us who cannot get by the plumbing aspect of it all. I readily agree: SOAP, XML, HTTP, and RPC ( in whatever shape or form ) is indeed nothing new. But the conceptual design and architecture of enterprise-based applications has indeed changed, and it is an important change to respect and notice.
    In the past, an architecture that was considering external users to enterprise applications would become more complex. The Java client that was configured for the user audience could not be deployed without some major intelligence-embedding done on the part of the J2EE developers and their counterparts in the user-interface departments. This was because the information necessary to access back-end EJB components may not have been intended to be configured by an uncontrolled user environment( ie. the rest of the world ). It was not a show-stopper: that is, some good exception handling and strong communication between the Java client developers and the J2EE developers could overcome this issue... but what about maintenance, upgrades, customization. It promised to become a nightmare.
    What was needed were endpoints. Places in the architecture where the different players could "drop off" their data and thereby decouple themselves from the binding logic and sticky collaboration needed with each other. For example, a MOM supports this "drop-off" of data by making messaging asynchronous. A publisher makes contact with the MOM, then calls it a day. It doesn't wait around to see the consequences of its published information. All it knows and cares about is sending data( ie. dropping it off at an end point ). Imagine a publisher if it needed to know all about the subscriber or the subscriber's environment. Well, that's not really decoupled then. Just like Web Services, the concept of a MOM has been around for ages, so why the big hoopla with JMS? The answer is analogous with "why the big hoopla with Web Services". We could make users talk to enterprise systems before, so what's the big deal?
    It's because architects and designers can plan systems in a new way, and vendors will produce products to support that new way of thinking. That's all Web Services is. Bit that doesn't mean that it isn't a revolution or even an evolution. It's both. Just because a physical product is not there, it doesn't mean that we have not entered a "new age". Let's give ourselves more credit than that: Web Services represents an important shift in how the future of IT will shape itself.
    I don't give the argument enough justice. Let Barry Morris of IONA technologies explain it as well( taken from Java Developer's Journal, most recent issue ):

    "(The)... endorsement of the 'evolutionary' view was strongly contested by Morris, who time and again stressed to his fellow panelists and to the entire audience of developers and i-technology professionals that there has never been anything like Web services before...it's a complete and utter revolution.

    Morris spoke of Web services as a 'flattening' of information infrastructures, such that 'more people are able to get at your enterprise value' than ever before. Exposing that enterprise value as Web services is going to be the key to the next phase of e-business, he explained. Just as people writing in Word or doing a presentation in PowerPoint are in effect programming, they are empowered by technology to do something previously doable only by programmers. So, continued Morris, Web services is poised to enable a mass adoption of distributed computing techniques previously available only to software engineers."

    Here's the argument I like best:
    ....Morris dismissed UDDI and WSDL at one point, insisting that focusing on the "plumbing" of Web services was missing the point of Web services entirely: Web services is a paradigm that enables corporate developers to finally unite their applications.

    I'm not saying to choose one over the other, but let's not slam the concept of Web Services as hype.


  12. I think the critical driver of Web Services adoption will be the unified support of the major vendors behind it. The missing element before was the support of all the major players. DCOM was a Microsoft only thing and CORBA was never endorsed by Microsoft. I think this unified support makes all the difference. It certainly isn't the technical merits as I think the various Web Services standards are immature compared to their predecessors. But, the standards are simple to implements and this fact alone might be the panacea to the interoperability problems that have plagued CORBA.
  13. Hmm, to say this: I like the idea of web services, and again, I'll ride the hype, but from a general viewpoint...
    You see, there is no "support from all vendors"... the MS things (SOAP, WSDL, WSCL, UDDI, BizTalk) are competing with RosettaNet and ebXML... don't think the worlds will ever be fully unified.
    Just because it is XML it doesn't mean it is interoperable. I could say "it is ASCII, thus it is interoperable" and this would be the same nonsense. XML by itself doesn't make anything more interoperable, it _can be used_ to do this, yes.
    The idea of WebServices is great, but nothing new... nothing is new about these (Orfali talked about this service environment years ago in his CORBA books). It just uses new protocols now. More complicated ones.


  14. Bernard:

       Again, I see the two of us agreeing on several points, so I hate to pick on this one point, but...

       It is the technical arguments against Web Services that are being made of which I disagree with. I feel that it is really pointless to show how Web Services is not a new concept. The idea that we had the technical werewithal to implement Web Services 10 years ago is irrelevant. The idea that somebody else with a CORBA background thought of these advantages way before anybody else did is great( this person was a pioneer and should be recognized as such ), but really isn't relevant to the question of "Is Web Services all hype?". This sticking point is bringing us back to the main fallacies involved with the now-infamous "Pet-Store" debate.

        First point:
      You see, there is no "support from all vendors"... the MS things (SOAP, WSDL, WSCL, UDDI, BizTalk) are competing with RosettaNet and ebXML... don't think the worlds will ever be fully unified.

       Yes, there IS an automatic and implicit support from all vendors because Web Services are XML and any vendor can make XML. But let's not dwell on this technical capability! The only reamining issue with the concept of "support from all vendors" is the intangible one of Will-Everybody-Do-The-Same-Thing. Like you said, RosettaNet has been around for a while and is an XML standard that defines business transactions -- but not everybody is using it! Thus, the real issue is that since everybody is "making Web Services", it is easy to see that everybody will be adhering to the Web Services way of doing business --- that is, if we don't get caught up in calls to not follow this supposedly conspiracy-laden hype that mongers fear among the important players ( the developers/programmers ). This means that although the industry has not yet globally implemented Web Services to replace a perfectly functional transactional XML standard like RosettaNet, the idea that everybody is going to making Web Services tells us that by supporting Web Services should eventually lead to global implementation of a unified standard. Now whether that involves ebXML to define the meta-meaning of the content or whether it involves some aspects of RosettaNet is *not the point*. The fact of the matter is that RosettaNet, for whatever reason, was not universally adopted. To bemoan that fact will not bring us forward into the future. Let us recognize the purpose of these great ideas from the past and not try to honor them by dragging them into a fight with a technology that is trying to build from their successes and failure.
        Point 2:
    Just because it is XML it doesn't mean it is interoperable. I could say "it is ASCII, thus it is interoperable" and this would be the same nonsense. XML by itself doesn't make anything more interoperable, it _can be used_ to do this, yes.
         Yes Bernard, I agree with you that just because a technology uses XML, it is not automatically the greatest thing since sliced bread. But your assertion on this merely proves the point I'm trying to make on Point 1. We need one more thing than just the technical requirements to make something work. This thing is global acceptance for a global standard. RosettaNet did not have this across the board. And what about ebXML? ebXML is a great idea, and it can co-exist with a Web Service. The fact that Web Services has the power to overlap ebXML's functionality does not mean that it is Web Services vs. ebXML; rather, why can't we come to a happy medium with these two technologies? ebXML has the power to define business data and format it in a standard, unified way; Web Services has the power to access business logic via XML-RPC( ie. EJBs, etc ), and also to encapsulate business data as payload. Instead of driving a wedge between these two technologies, let's accentuate their advantages and develop applications that highlight them. Why can't we use a client to invoke a Web Service which defines parameters for an EJB, and have an ebXML document piggy-back on the payload? You instantly get the best of both worlds by automatically seperating the business content and business meta-data from the delivery methodology and application logic requirements --- and guess what? It's all in XML! So bottom line is that this is actually a chicken-egg conundrum. You have to have the requirements FIRST, then develop the technology to support them. You're absolutely right --- the adherence to XML means absolutely nothing. It's what you plan on doing with that XML which is the crux of the argument.
        Point 3:
    The idea of WebServices is great, but nothing new... nothing is new about these (Orfali talked about this service environment years ago in his CORBA books). It just uses new protocols now. More complicated ones.
         True true true... but this is a sweeping statement that merely provides for a smokescreen to the real argument. I recently talked to a developer who bashed Web Services because he "has been using Web Services for years". I immediately thought of the person who posted a message on the "Pet Store" debate who sarcastically claimed that he could write assembly code that would put both .NET and J2EE's Pet Store design to shame performance-wise. He was making the point that although some very talented technical people have always had the ability to develop and use Web Services, the supposed "hype" around having all corporations use Web Services is not to try and challenge these previous technologies. It's to have it globally recognized. Period.

       There is no hype. There is no conspiracy. The only issue at stake here is the ability of each of us to let go of our pre-existing protectionist attitudes towards choosing one technology over the over and move towards a unified standard of conduction business and developing applications. This is a very dangerous move because we need to be sure that the unified standard is open and available to all members of the IT community and is the best possible technology to serve the wide-range of uses that the business community needs. Instead of focussing our energies on pointing out how this technology is better than that, let's concentrate on the larger issue of how we are going to work together in the future.

    Thanx for reading,

    Ted Sfikas

  15. I still don't see how the web services will be able to deliver on the promise - hype - of unification. <br>

    I have a simple case. Two companies offering similar datbase driven products, let's say on-line shops with product catalogues. The companies would like to swap product information. They build import / export product web services.
    However, the effort to implement this service was never in the recent years at the transport protocol layer...It was in the down in the data and business logic layer. So the simple service of "getProductInfo(id)" is still not solved yet. It all comes down to actually adhere to vertical industry standards.
    I add another partner, what do I have to do today? Re-negotiate the XML structure for the new realtionship and the analyse the implications through all the layers down to my database. It's not really a middleware issue here. Anything from HTTP(s) to FTP or SMTP would do...<br>
    How are webservices making my life easier?
  16. I'm not sure I understand your question fully, but I will try to answer based on what my impressions are right now. I think you are asking how Web Services could make your life easier given that you work at a company whose product line needs to be exchange with another company.
    We all know that there are many ways to do this. Why is Web Services the best choice? Firstly, assuming that your company not only wants to swap data with another company, but perhaps *any* company, then the first thing that comes to mind is the format of the data, not the delivery. So you are correct when you say that using HTTP, FTP, etc is irrelevant. What *is* relevant is the format of the data sent. Some vendors may wish to send you XML, some may wish to send you flat files. Either way, the meaning of the content is the same. Thus, there needs to be a universal way of *expressing* your data.
    Web Services does not make your life easier in this sense. Whether your company is told that you can buy a widget at $5.00 apiece like this:


    or like this:


    or like this


    the meaning is all the same.

    But what if there was a code module that could have parameters set on it which would transform each of these 3 different formats into a Unified XML, one that every company agreed upon but doesn't necessarily use for whatever reason( performance, etc etc ).?
    Wouldn't it be nice to be able to access that code module no matter where you were in the world or what your client or operating system type was? Let's say that this code module is an EJB. This EJB is on company ABC's EJB Server. The EJB has the logic to be able to transform hundreds of known XML formats( via DTDs previously loaded into ABC's database. JAXB for extra smoothness? ) into the Unified XML format. It also has the intelligence to be able to transform that proprietary flat file output that you saw above. The only thing is, you have to be able to *talk* to it and *use* it, regardless of client software origins and operating system origins, and regardless of your choice of data format.
    Web Services takes care of the first two: you are able to use Web Services in a way that can access this powerful EJB despite the client program you develop and operating system that you are on that will generate the data needed to invoke the EJB.
    But what about the third thing? The data format? What if you have no problem creating a Web Service and using it, but you find it troublesome to adhere to the EJB's format constraints( ie. let's say that you are using a proprietary format that the EJB cannot understand ). The notion of discovery and description then come into play. You want your client running the Web Service to automatically discover another Web Service which will handle the conversion of your proprietary data format into, say, ebXML. From there, you can have your newly formatted data sent to ABC's database via the original Web Service, which is able to handle ebXML. Through UDDI, you discover that company XYZ has already developed an EJB that can do this. The EJB is wrapped around a Web Service as well. So you now build your business activity by fitting two Web Services together.
    Or, to make your life even easier, use ebXML to start with to avoid the extra work, but that part is not relevant to the point.
    The point is that all of the little nuances and difficulties of exchanging information and handling information is not about the technology and not about the effort any longer. There are ways around both those issues. The one thing that remains unsolved is a common business language and a common way of doing things. Web Services merely provides a vehicle to achieving this utopia, it isn't the utopia itself.
    But that doesn't mean that it should not be recognized for what it is -- an important step in the right direction.
  17. Web Services: More Smoke Than Fire[ Go to top ]

    The important part of web services is the services part, not the web part. As others point out SOAP implementations are an almost trivial problem.

    The importance of web services is in exposing large grained business services that can be assembled/composed into applications. This is a genuinely innovative and revolutionary paradigm. Microsoft's Passport service is the shape of things to come. A single globally available implementation, or what I assume will be the Liberty Alliance answer, a single globally available interface that may hide a distributed implementation of considerable complexity.

    Will web services make software development more efficient and productive? - Absolutely! Will it result in a decline in demand for J2EE developers? - Previous productivity improvements didn't reduce the demand for developers, and I see no reason that web services be different! There seems to be an unlimited demand for new software.

    In the medium term I think the services paradigm will be more influential inside enterprises than between enterprises, as getting to services is 95% of the effort in getting to web services. Here's a paper I wrote on this subject http://www.enba.com.sg/Whitepaper1.html
  18. Web Services: More Smoke Than Fire[ Go to top ]

    It's funny how people can't see that people still need to write services for web services, even after web services becomes popular. Web services are like traders. If there's nothing to trade, why do we need the traders?

    Another point, people are having a hard time even to optimize their internal business and applications nowadays. B2B and web services may be promising, but have a long long way to go. They may become popular in a particular sector or niche soon, but it's not going to impact the whole industry.

    Last point, I believe people shouldn't write web services by hand. They should be able to point and click to enable a service to be web services ready. A lot of vendors has developed or are developing tools to do just that. So the key thing is, if you envision that a service may become a web service in the near future, design for it. You may want to make it an (session) EJB. In the J2EE world, session beans are the most appropriate component to support web services. They are scalable. They are also strong typed and tools can generate stubs and skeletons for them easily by introspection.

    So J2EE or .NET developers really don't have to worry about the future. After all, we are the ones who are providing the meat, the real value.

    Just my few cents.
  19. Web Services: More Smoke Than Fire[ Go to top ]

    I thought it was a pretty poor article, but its produced an interesting debate.
    "... that people still need to write services for web services, even after web services becomes popular."
    And, obviously, write web services for web services.
    "Web services are like traders. If there's nothing to trade, why do we need the traders? "
    Services to broker those services with all attendant business processes to facilitate that.
    As soon as business process is expossed qua Web Service, there is the likely hood for any non-trivial service of competition on points of value or amount of added value.
    In some cases there will be a need for the lowest bid, in others the greatest value add, and some reliable way to measure this.
    There seems no end of work to be done in this regard.
    "So J2EE or .NET developers really don't have to worry about the future. After all, we are the ones who are providing the meat, the real value."
    I wonder what the reaction here is to this statement from Ontoprise (www.ontoprise.de): -
    "Currently, B2B-applications that are based on XML are put into practice. That XML is not the solution for interoperability in B2B-applications will be recognized as soon as a large number of enterprises will use these XML-based solutions: the syntactical and therefore unwieldy handling of interoperability aspects will end up in the demand to manage heterogeneous information sources on a conceptual and thus a semantic level."
    What is meant is XML as opposed to a derived extension such as RDF and DAML+OIL.
  20. Web Services: More Smoke Than Fire[ Go to top ]

    Web Services is just another way to do stateless remote calls. When we have better object transparency we will be somewhere. Web Services are just as lousy as are DCOM calls, stateless session beans etc.
    Entity beans are a little better but not quite there yet.

    CORBA has done it best so far. Web Services is nothing new and will add little.