Web Services still haven't taken off

[John Raab]

It seems that with the weak climate for IT spending the "launch" of web services is slow to take off. I am a consultant and we are starting to slowly see them emerge here and there as useful tools in certain situations, but definitely not the "killer internet app" that everoyne was expecting.
I would very much like to know what our guest speakers think about the future of web services within the short term (3 year timespan)?
-John

[Ravi Anamalay]

Would that be related to the availability of broadband ? I know that here in Australia broadband hasn't really taken off for various reasons, some of them political.

[Lasse Koskela]

Perhaps it's a good thing that Web Services doesn't "take off". No, I'm not against Web Services. My point is that the slow "acceptance" might actually be a sign of healthy, business-driven use of technologies. Web Services has its uses, but there will also always be need for lower-level technologies due to, say, top performance requirements. What do you think?

[Ravi Anamalay]

You mean web services are being used when there is a real business need for them, as opposed as to using them simply because they're the latest fad ?

[Lasse Koskela]

Originally posted by Ravi Varman:
You mean web services are being used when there is a real business need for them, as opposed as to using them simply because they're the latest fad ?

Yes. I know it's a cliche (the "not for technology's sake" part) but I think that we're finally acting according to what we say... Not revamping our systems just to be able to decorate CVs but for a valid, financial/strategic reason.

[Darryl Failla]

I would sure like to think that the change-for-the-sake-of-change mentality that grips so many administrative supervisors is FINALLY wearing away. Just as with sleeping dogs, you should leave running apps lie.

[Mark Reimer]

I've been writing a lot of portlets lately and I couldn't help but notice how web services play a large role in a portal environment.
I'm guessing that as we see more commercial portals, we will see a rise in the use of web services.

[Douglas A Hoffman]

Following the whole, "technology not for technology sake" but to focus on business needs I am intrigued by WSIF implementation. The idea being to exploit WSDL for something other than WebService directly and leverage for existing legacy, EJB, or other component seems to be looking at keeping investments going while also leveraging new technologies to expand their reach. Glad I followed the carrot of the "free book" today.

[Lasse Koskela]

Originally posted by Douglas A Hoffman:
Following the whole, "technology not for technology sake" but to focus on business needs I am intrigued by WSIF implementation. The idea being to exploit WSDL for something other than WebService directly and leverage for existing legacy, EJB, or other component seems to be looking at keeping investments going while also leveraging new technologies to expand their reach. Glad I followed the carrot of the "free book" today.

You lost me. What do you mean by "WSIF exploiting WSDL for..."? I recently tested WSIF for a simple, dynamic client and I couldn't find any features that would not be available in the JAX libraries.

[Ramesh Nagappan]

Originally posted by Lasse Koskela:

You lost me. What do you mean by "WSIF exploiting WSDL for..."? I recently tested WSIF for a simple, dynamic client and I couldn't find any features that would not be available in the JAX libraries.

BTW, WSIF is a IBM Alphaworks discontinued effort submitted to Apache. If you are looking into a portable code, supporting J2EE standards then think about using JWSDP. JWSDP tutorial shows examples how to invoke EJBs and Servlets from JAX-RPC and SAAJ.
Another thing, J2EE 1.4 will have full-fledged support JAX-RPC and SAAJ. EJBs( SLSB and MDB) can be exposed as Web Services as well.
/Ramesh

[Douglas A Hoffman]

You lost me. What do you mean by "WSIF exploiting WSDL for..."? I recently tested WSIF for a simple, dynamic client and I couldn't find any features that would not be available in the JAX libraries.

Sorry, I was not going from an experience base with WSIF, but from another post which ref'd the Apache site. From that I was trying to see what WSIF was supposed to be, and to that end read what I thought described its goal... Sounded reasonable, but I probably have totally misread or misunderstood it... beware the greenhorn!

WSIF fixes these problems by letting you use WSDL as a normalized description of disparate software, and allows you to access this software in a manner that is independent of protocol or location. So whether it is SOAP, an EJB, JMS (or potentially .NET and other software frameworks), you have an API centered around WSDL which you use to access the functionality. This lets you write code that adapts to changes easily. The separation of the API from the actual protocol also means you have flexibility - you can switch protocols, location, etc. without having to even recompile your client code. So if your an externally available SOAP service becomes available as an EJB, you can switch to using RMI/IIOP by just changing the service description (the WSDL), without having to make any modification in applications that use the service. You can exploit WSDL's extensibility, its capability to offer multiple bindings for the same service, deciding on a binding at runtime, etc.

[Robert Skoczylas]

It seems that with the weak climate for IT spending the "launch" of web services is slow to take off. I am a consultant and we are starting to slowly see them emerge here and there as useful tools in certain situations, but definitely not the "killer internet app" that everoyne was expecting.
I would very much like to know what our guest speakers think about the future of web services within the short term (3 year timespan)?

I have no idea where Web services will be in 3 years and I don't think anyone could answer this question today. 3 years is more like an eternity in computer time...I could probably tell you what web services are trying to achieve today and in the next couple of months.
I do agree with you that we are seeing more and more projects using web services technologies. It's not a question of inventing a technology that will allow you to build a "killer app" but simply a technology/solution that is based on open industry standards. Why is this important?
Web services technologies will provide many different business opportunities for companies, since companies will be able to communicate with other companies (B2B) independent of their platforms and business implementations.
One area that can be addressed today is in the integration space where we have millions of applications running on different platforms written in different languages that could potentially leverge each other to perform business operations. There are alot of issues assocuiated with such collaboration but the idea is to have technologies that are independent of the vendors specific implementation. So for example, Company A (using Java) can invoke services provided by Company B (using .NET) by using SOAP RPC.
There are lots of initiatives that are going on today and have evolved significantly over the last couple of months. There were many holes that basic WUST (WSDL UDDI SOAP technologies) do not address such as security, transactions, etc ... which are currently being addressed by other standards. These missing gaps likely influence the wide use of web services.
I think it is an evolving area that will only get better. Of course, this is not a silver bullet. It does not solve all problems. In fact, one should be very careful when choosing any technology. It reminds me of the misuse of XML. I think we could all identify one instance of such occurance, where people used XML because it was the cool thing.
In result, it caused many performance issues.
I love XML and I think it is a technology that has facilitated many things.
hope this helps,
-robert