Discussions

News: Spending in Web Services Tools Market Stalled

  1. Spending on new Web Services technologies has dropped off this summer, partially due to the bad economy, and partially due to realization that companies are not in immediate or dire need of Web services or the underlying products to create them. Bill Gates mentioned last week that .NET was not moving as fast as hoped. Silverstream has said that WS sales have not improved in the last 18 months.

    Read Web services spending stalled.

    Related News: Gates: Slow going for .Net.

    It seems that hype is finally being lasso'd in by reality. Web Services have been hyped up as though they were the next big thing. For people heavily involved in integration projects, it probably is. For the rest of us writing enterprise applications, WS won't change our jobs or affect us.

    The take away point is that many companies have focused their strategic direction on Web Services as though it were something that would revolutionize the enterprise development industry. However, I think that this focus is mis-directed. It is not the enterprise development industry that needs Web Services, its the much smaller subset of that industry that is working on integration projects.

    Thus, the lack of spending on Web Services tools could deal a crushing blow to the numerous startups and new corporate initiatives that have bet their future on Web Services being the next big thing. Even Microsoft may have shot itself in the foot by tying its .NET marketing message so closely to Web Services, which is just a feature of .NET.

    Threaded Messages (45)

  2. Anyone surprised by this? I work in a heavily integration-focused department and nobody is talking about Web Services. In fact, I don't know any developers who are particuarly excited about it.
  3. Actually, I know of several Fortune 50 companies that are in fact standardizing on w/s for tier integration purposes. This is where w/s is useful.
  4. We are building several systems with WS for big govermental departments with real complex enviroments.
  5. Interesting...

    How are you handling security and managing transactions? For integration I would lean more towards a EAI product.

    You mention "real complex environments". Can you describe what you mean by this? Right now I am contemplating managing transactions between TUX, CICS, MQ and J2EE. How would I handle rollback of transactions acting upon all these systems?

    Correct me if I am wrong but having to front my legacy systems (aka "complex environments") with a WebService seems counter productive. Yet another communications layer. (YACL)

    I like meat on my burgers... WebServices taste like they are all bun...

    Where's the beef?
    Greg
  6. You have Business Transaction Protocol (BTP) spec to manage transactions in a loosely coupled environment. This spec describes how to manage transactions in web services.

    You can refer the spec at
    http://www.oasis-open.org/committees/business-transactions/

    -Muruga
  7. Collaxa provides very clean approach for orchestrating web services. Using their ScenarioBeans you can easily build asynchronous web services and you can easily compose any standard web services (.Net web services / WASP web services.)

    If you are doing some asynchronous web services development..then its worth to look at www.collaxa.com

    </r>
  8. IMHO, why be concerned with Web service transactions at all?

    I see Web services as being at a 'higher' level than code which requires transactions. They should actually provide a discrete service, and they either succeed or fail. They are just another form of distributed procedure calls, which operate in a different environment and under different constraints than local procedure calls.

    If you want to do something like this;

      beginTrans();
        addUser('fred nurks');
        addService('voice');
        addService('sms');
      endTrans();

    Then that process should be bundled in its entirity as a Web service ( called addUserWithServices ) with the required transaction control. There is a place for distributed transactions but people seem to want to over use them.

    Web services can potentially be called from many different environments, some environments may be very simple and not have any concept of transactions.

    Keep it simple and keep the unit of work as clearly defined services, don't try and publish generic objects.









  9. Now consider the case:

      buyHoliday
        start transaction
          purchse plane ticket
          purchase rail ticket
          purchase hotel room
        end transaction

    where the plane, rail and hotel components are all the
    responsibility of different companies.

    Can web-services address that kind of issue?
  10. <lyndon-samson>
    IMHO, why be concerned with Web service transactions at all?

    I see Web services as being at a 'higher' level than code which requires transactions. They should actually provide a discrete service, and they either succeed or fail.
    </lyndon-samson>
    ... altogether! You forget to add this magic word.

    WS was designed to implement applications as an orchestration of MULTIPLE existing third-party services as bulding blocks. Such orcestration almost always reqires transactions and single sign-on capabilities.

    Even if your application needs only one external service, it must be coordinated appropriately with in-house resources. Transactions are mandatory requirement (unless you are using 'currency rate' or 'weather report'-like services)

    The real problem with WS is that architects and developers are trying to use them as "Yet Another RPC" protocol, many of them even think that WS == SOAP. False. They are self-contained bulding blocks, components of "higher" level then currently used (EJB, JavaBeans, COM/COM+ etc.) But they require higher level secure transactional framework to glue them together. The lack of such framework (as implementation, not as specs -- there are a lot of them already) is another problem.

    My 2 cents to those, who tries to deliver enterprise data via WS to GUI (I've seen similar replies here). You don't need WS for this task. Take a look at REST (REpresentation State Transfer, if my memory serves me well). You have all required parts already (HTTP, XML and other + servlets, ASP, PHP, whatever-else-cgi). Keep simple things simple ;-)

    Regards
    VS
  11. "Web Services" is a lot of hype generated by Microsoft to justify a transition to the .NET framework. You have to have a good reason to make a shift. The other reasons to move to .NET are actually embarassing for Microsoft. These are (1) a platform that's more like Java and (2) a platform with better security.

    Microsoft made a gamble that it could sell the "Web Services" idea, so far it hasn't gained much traction, in the mean time Java is gaining steam and even surpasing Microsoft in this space. Surveys like http://www.webservicesarchitect.com/content/articles/fletcher02.asp 49% share of webservices work are done in Java vs. 37.3% done in .NET .

    Just to give you a feel of how good Java has become in supporting web services, here's a viewlet I put together:

    http://www.geocities.com/ceperez/eclipsedebugginwebservice_viewlet_swf.html

    warning, it's almost 2MB so use sparingly!

    Carlos
  12. Folks!

    The geocities site is exceeding my bandwidth limits, please use this site instead:

    Demo using Eclipse and Glue

    Anyone know where I can host this for free?

    Carlos
  13. The geocities site is exceeding my bandwidth limits, >please use this site instead


    You shouldn't have done such a good job! :)
    All this and not even one scantily clad model. :)
  14. "How are you handling security and managing transactions?"

    Most legacy systems (and non-so-legacy also) are designed to operate independently and will not like being part of a third-party generated transaction. Many times, the system owner will think "What if this foreign transaction deadlocks? What about latency? It's going to hurt my resources and integrity!", so, in many scenarios, as integrator you will have to ask the system to do its thing and just notify you how it went, also you will probably need an "undo" procedure (in case you have to rollback your integrating unit of work). It sounds ugly, but my guess is that, in many scenarios, it is the only way you will be allowed to interact with indepedent systems.
  15. Common Criteria evaulated setups are available, up to EAL3 AFAIK. PKI solutions like Baltimore SelectAccess and Entrust/Authority take a long part of the way there.
  16. What is the hype about?[ Go to top ]

    WHat the heck are all those new web services "standards" about. To me it is just a marketing gimmick.
    To me a web service is just a web applicaitons that receives an XML document as parameter and returns another XML document as a result.
    I have developed servlets with this capability since more than 2 years ago.
    what is the advantage of using those new standards over using a servlet?
    I do not see any. The web services protocols sit on top of HTTP so they cannot provide better performance. AFAIK they do not let you pass a security or transaction context so they are not well suited for enetrprise applications.
    Please, somebody tell me the advantage of using a "web service" over a simple servlet, which, BTW, is a web service to me, just simpler and less bloated.

  17. What is the hype about?[ Go to top ]

    "what is the advantage of using those new standards over using a servlet? "

    That question is similar to 'Why use CORBA when I can create a socket and send messages myself?'. The advantage of WS is the exactly as you stated - a standard protocol. This enables tool vendors augment IDEs, accelerate application development, and reduce training costs (new developers don't need to learn your proprietary approach).

    I don't believe that WS will live up to the hype, but it certainly has its place.
  18. What is the hype about?[ Go to top ]

    <em>
    That question is similar to 'Why use CORBA when I can create a socket and send messages myself?'. The advantage of WS is the exactly as you stated - a standard protocol. This enables tool vendors augment IDEs, accelerate application development, and reduce training costs (new developers don't need to learn your proprietary approach).
    </em>

    HTTP and XML seem pretty standard to me. I do not see what is my proprietary approach. With web services yo have to define an interface. With a servlet yo do too.

    BTW, using a servlet instead of a WS is not the same as using sockets instead of CORBA. CORBA <em>defines</em> a wire protocol with a lot of functionality over plain TCP, while SOAP and the other WS specs add very little functionality over what HTTP already offers. I think WS have their uses, but they provide not much more than a preprocessor that generates some metadata and a stub that eases (very little) calling a web application via HTTP from a client.


    <em>
    A benefit of a web service is that it provides a standard way of describing itself (i.e. inputs and outputs) via WSDL. With your servlet, there really isn't any standard way for a client to discover how to use it.
    </em>
    I see that benefit, but I do not think it justifies all the hype. If you create an application in most cases you have to know the interface the web service offers at compile time (because if you don't, then you do can't do anything). I see very few applications where this reflection capability would be useful.


    <em>
    Also, while your servlet probably is very simple and not bloated at all, if you try out a framework like GLUE, you'll find that from a developer's point of view, web services can be very easy to build and deploy (excellent documentation to get you started too).
    </em>
    Servlets (and other web app technologies) are also very easy to build and deploy.


  19. What is the hype about?[ Go to top ]

    I agree with Vegeta. Coming from the CORBA world, I really do not see any added benefit of WS's in enterprise wide applications considering the secruity, performance and portablity requirements. The discovery is feasible in CORBA as well.

    However, WS's may have it's advantages for certain applicatoins like in some B2B's as it's based on XML and HTML alone. Again, the simplicity may go if security and performance are of high precendence. With any technology, things get mature with time. Hope the same with WS's as well.

    One reason for push or hype --- it is not biased to any software vendor like MS, SUN etc.
  20. What is the hype about?[ Go to top ]



    >Coming from the CORBA world, I really do not see any added
    >benefit of WS's in enterprise wide applications considering
    >the secruity, performance and portablity requirements

    Coming also from the CORBA world, I do see what some of the benefits of SOAP are:
    Simplicity. Comparing WSDL generated code to IDL generated code (lets say for a C++ client) the amount of crud you have to write for CORBA is quite a bit more than with SOAP. With OBV CORBA, its also quite error prone. Forget to register just one OBV factory and you could end up with intermittant MARSHAL exceptions for a while until you work out why). (Some better code generation tools would go a long way to help).

    But, as you say, this simplicity comes at the price of performance (security interop has always been a problem in CORBA, so that doesnt count). The performance factor cant always be ignored - it can be of the order of 10x difference.


    -Nick

  21. What is the hype about?[ Go to top ]

    Web Services technology will continue to draw the accurate criticism that we have seen in the last 3 dozen posts until such time as the entire industry embraces the standards in which Web Services implements. Only when this happens will it make sense for businesses to integrate on an enterprise-to-enterprise level, which is what Web Services main intention is to do.
    I know .. I know.. Web Service is more than just aggregate B2B technology... yes, you can use it for internal integration and I wish I could agree. But the fact remains that there are indeed better performing integration implementations that are more scalable and just as flexible within a company's enterprise system architecture needs.
    BOTTOM LINE: The chicken has to come before the egg here. The industry must implement Web Services FIRST before the "trend" catches on with others. Only then will we leverage the true force of this new technology.

    Basil.
  22. What is the hype about?[ Go to top ]

    HAHA..SOAP is simplicty? Since when has Microsoft been a part of an elegant solution ?


    Here is simplicity:

    http://www.xmlrpc.com/
  23. xml-rpc is simple[ Go to top ]

    I also prefer xml-rpc to SOAP. I've never really seen why SOAP needed to be so complicated.

    Another alternative to SOAP, based on xml-rpc ideas, is our Hessian protocol http://www.caucho.com/hessian/hessian-draft-spec.xtp. Granted, it's binary, but that actually makes it easier to parse than xml-rpc (and vastly simpler than SOAP). We're using Hessian over HTTP using a servlet as our native EJB wire protocol.

    We've also used Hessian for JMS. Granted, that's for a very limited JMS implementation, but JMS doesn't really need all the verbiage of SOAP.

    (Err, this is probably getting off topic and promoting an obscure protocol too much. But the relevant point is that maybe if "web services" was simplified, it would be gaining market share and importance faster.)
  24. I see a need for simple service-oriented RPC over the Internet and/or limited bandwidths, both for Java-only and integration projects. Of course, there are current standards like RMI for the former and SOAP for the latter kind of projects.

    But what I really want to care about as an application developer is the server-side service implementation code and the client-side service access code. Everything else is infrastructure that should work but not bother me too much. The actual toolkit and wire protocol should be exchangeable with little or no modifications to both server-side and client-side application code. I consider such issues configuration options to be specified in deployment descriptors.

    And guess what, this is not too hard to achieve, even with current toolkits. I've played around with some custom samples and even adapted real-life applications, using the following free and server-independent toolkits: Caucho's Hessian, Caucho's Burlap, GLUE/SOAP, and good old RMI/JRMP.

    It's fairly easy and straightforward to isolate toolkit-specific client-side service lookup code. The client application just calls a service lookup method with a service id plus an interface and gets a service proxy that implements the interface. The actual toolkit and the toolkit-specific URL associated with a service id can be specified in some configuration file. The service lookup method handles all the configuration issues including toolkit choice.

    Writing toolkit-independent server-side services is not hard either. All of the toolkits allow mapping a specific service implementation class that just has to implement the service interface but not extend a toolkit-specific superclass. Hessian, Burlap, and GLUE map simply to a URL, RMI maps to a registry plus the name of a registry entry. Server configuration is just a matter of configuring toolkit-specific servlets and mapping them to certain URLs, even with RMI if you write a simple RMIServlet that exports a given service under a given registry entry name.

    Using a secure connection is easy with the HTTP-based toolkits (Hessian, Burlap, GLUE): Simply use HTTPS URLs and make sure a corresponding client certificate is available to the client VM. Of course, you need to activate the SSL support of your servlet engine on the server-side.

    Solutions for authentication are also emerging: Simply use HTTP basic authentication, without a need for modifying the client application code. The isolated service lookup code can retrieve user name and password from a client configuration file or from the user and hand them over to the toolkit-specific access code. On the server-side, you are free to use whatever authentication mechanism your servlet engine provides. GLUE already supports this, Hessian and Burlap will support this in an upcoming release.

    Altogether, there are a number of simple solutions for Java-based RPC available now. Choose whatever you need for your project, and you even have the option of changing your mind midway without much hassle. If you need to integrate with foreign language clients or servers, GLUE/SOAP might be the preferred choice. But Hessian and Burlap are not inherently Java-specific too: There already is a Hessian library for Python, for instance.

    BTW, I don't particularly like the reflection approach of calling an execute method with a method name parameter. I prefer working with Java interfaces.

    P.S.:
    Scott, it's great to see you on TheServerSide! Thanks again for your great web service toolkits - their stunning simplicity keeps amazing me...
  25. "I see a need for simple service-oriented RPC over the Internet and/or limited bandwidths, both for Java-only and integration projects. Of course, there are current standards like RMI for the former and SOAP for the latter kind of projects." -- Juergen

    A limitation of all extranet Java clients is that none can portably use RMI, often for lack of tunneling. Without RMI tuneling, there is also no extranet access to EJB or Jini. RMI tunneling could be almost guaranteed if Sun or JCP would create a standard for mapping of RMI onto XML-RPC or SOAP. In addition to portability, RMI over HTTP would also give security and authentication, as you mention elsewhere in your post. Is a third-pary already doing RMI via standard XML networking?
  26. CORBA sucks.[ Go to top ]

    "Coming from the CORBA world, I really do not see any added benefit of WS's in enterprise wide applications..." -- RD

    Admittedly the overlap of CORBA and XML/HTTP is significant, but CORBA does tend to struggle on extranets. Web services have these inherent advantages over CORBA, some of which also apply to an intranet, especially a multi-site intranet:

    1) Tunneling.
    2) Amorphous topology, no need for a broker.
    3) Connectionless.
    4) Human-readable traffic.
    5) Text is a pervasive encoding, no need for an IDL compiler at each end.
  27. CORBA sucks.[ Go to top ]

    Who needs webservices when you can use JMS
  28. CORBA sucks.[ Go to top ]

    "Who needs webservices when you can use JMS" -- Sanwar

    Quoting the JMS 1.1 spec: "JMS does not define a wire protocol for messaging." So clearly JMS alone is insufficient as an integration standard. Whereas web services do have a standardized wire protocol, namely XML over HTTP.
  29. What is the hype about?[ Go to top ]

    A benefit of a web service is that it provides a standard way of describing itself (i.e. inputs and outputs) via WSDL. With your servlet, there really isn't any standard way for a client to discover how to use it. While the client could look at a Java interface for it, it won't be useful unless they understand Java (and how do you best publish that interface?).

    Also, while your servlet probably is very simple and not bloated at all, if you try out a framework like GLUE, you'll find that from a developer's point of view, web services can be very easy to build and deploy (excellent documentation to get you started too).

    While we've had some success on our project (gov't contract) with web services in terms of integration and creating natural interface points, we have had serious problems with security (no standards yet) and performance (not to mention long-lived transactions). And there's no doubt that the overblown hype has been accompanied with a lot of ignorance about what a web service actually is - we've got management-level folks here who just think it's something you can use in a browser instead of requiring a thick client (and they see unlimited potential for something so innovative ;).

    Rob
  30. This was the same response when people started using EJBs. Everyone wanted to join the band wagon on criticizing EJBs. Still far from perfect, EJBs have evolved into a powerful enterprise technology through versions 1.0 to 2.0 and 2.1 promises more.

    Web services is not a silver bullet...

    However, all those people who have spent countless hours on understanding the proprietary messaging intricacies of EAI vendors would look at web services as the perfect technology for inter-operability.

    Regarding security within web services, it is still an evolving technology. Still there are promising initiatives like SAML and WS-Security.

    IMO one of the biggest problems in the industry is people being over cynical about new technologies. I don&#8217;t think web services are going to replace the existing EAI tools. However, EAI vendors can leverage the power of web services to provide more inter-operable solutions.
  31. What is the hype about?[ Go to top ]

    Meeraj Kunnumpurath wrote:

    "Web services is not a silver bullet...

    However, all those people who have spent countless hours on understanding the proprietary messaging intricacies of EAI vendors would look at web services as the perfect technology for inter-operability."

    Bravo. With the development of JMS, message-driven EJB's, and Web Services we are acquiring a very rich set of open standard EAI tools rivaling those of any of the proprietary EAI vendors. The piece still missing is the relative dearth of workflow manager and message broker products in this marketplace, but those products are beginning to appear also.
  32. What is the hype about?[ Go to top ]

    A good point indeed. I was looking for a developer-friendly solution that will put all these APIs to work. So far, I have found Collaxa's orchestration server to be dead-on for solving this problem. It fits into any J2EE environment and is easy to learn and program using the Scenario Bean abstraction. www.collaxa.com.

    Cheers. Jill.
  33. What is the hype about?[ Go to top ]

    Cynical? Who's cynical?

    Just because people call a dog a dog doesn't make them cyncial. It makes them realistic.

    If one defines cynicism as realising the people are stupid, primarily motivated by fear and greed, and then taking advantage of those facts, I would argue that many of the *vendors* are the cynics.

    Web Services are hard to do well. They work, in my experience, when you have a company-internal, small, low-bandwidth integration point between two very different systems, if both systems have owners/admins with an interest in achieving integration.

    <laugh/> Of course, I'm a pessimist, not a cynic...

    Cheers,
    Carson
  34. What is the hype about?[ Go to top ]

    <Carson Gross>
    If one defines cynicism as realising the people are stupid, primarily motivated by fear and greed, and then taking advantage of those facts, I would argue that many of the *vendors* are the cynics.
    </Carson Gross>

    Actually, that's almost exactly the definition of cynicism, which is the belief that people are motivated by selfishness (this, according to Webster)

    later,
    Dan
  35. What is the hype about?[ Go to top ]

    Difference being believing (cynic) and knowing (realist). A fine line.
  36. Spending money on Web Service tools?

    <laugh/> Riiiight:

    http://xml.apache.org/axis/

    Drag and friggen drop. God Bless Apache.

    Cheers,
    Carson
  37. GLUE standard edition is also free.
    download from http://www.themindelectric.com.

    cheers,
    graham
  38. <quote>
    GLUE standard edition is also free.
    download from http://www.themindelectric.com.
    </quote>

    Thanks, Graham, for the fantastic product. If anybody using WS didn't look at the GLUE yet, they definitely should. (and the Electric XML of course ;-)).

    --
    Dimitri
  39. I would also recommend GLUE, it couldn't be much easier to do web services.
  40. Check out Systinet WASP (http://www.systinet.com). You'll get far better security, performance, interoperability and easy development. WASP is FREE for development and 1 CPU deployments.

    ZD
  41. Why is everyone whining about Web Services?

    Web Services is just a strategy to use if it's useful for your problem.

    For instance, I needed a Windows GUI thin client to call remote procedures on scalable Unix servers that can pass through firewalls. Guess what, Web Services/SOAP provided the ideal solution to this problem. Perhaps, to exchange high secure very large datasets on a publish-subscribe guaranteed message protocol might not warrant Web Services.

    I think if some people lay off reading Infoworld and Computerworld Web Services articles and concentrate on common sense approach to technical solutions - then the whining would stop.
  42. From my perspective, every time I integrate someone else's service into my site using web services, I introduce a single point of failure over which I have almost no control.
  43. Well the best part about web services is the use of industry standard XML.This really help to communicate between the Two Great Development Plateforms J2EE and DOTNET.You cant deny development of a web service in a time like this where every one is moving from Desktop to Web and it really help for even small enterprises to communicate with other ones using Web Services.If you are a J2EE based Enterprise and Wanna Communicate with a DotNet based Enterprise ,You had to have a Web Service layer in order to comunicate Between both of them.
  44. You had to have a Web Service layer in order to comunicate >Between both of them.


    If you mean had to. No you didn't.
    If you mean have to. No you don't.

    Web services a just one way. A quick way, but they bring their own issues. Most are already mentioned. If one doesn't care about security and transactions then there still are exceptions and custom objects. If you are using them within the same platform (i.e. Java to Java with something like GLUE) then the custom object issue is solved - if the same code is deployed to the 'client' and 'server'.

  45. Lets face it .Net ( dot not) is dead. MS should concentrate to make a good OS but wait Linux is here who needs Windows anymore.
  46. Maybe Gates and Co. including some MS trolls in here can rig a few more polls to alter reality...

    I can see the headlines now:

    Schools of Bald IT Managers flock to Microsoft Web Services