SCJP - Webmaster of battlereports.com
with kind regards,<br />Ravi
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
with kind regards,<br />Ravi
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 ?
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Darryl Failla
Sun Certified Java 2 Programmer
Pax et Bonum!
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.![]()
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
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.
Ramesh Nagappan CISSP<br />Co-Author of "Core Security Patterns"<br />[email protected]<br /><a href="http://www.coresecuritypatterns.com" target="_blank" rel="nofollow">www.coresecuritypatterns.com</a>
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.
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.
Pax et Bonum!
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)?
Don't get me started about those stupid light bulbs. |