Description of WSIF
WSIF enables developers to interact with abstract representations of Web services through their WSDL descriptions instead of working directly with the Simple Object Access Protocol (SOAP) APIs, which is the usual programming model. With WSIF, developers can work with the same programming model regardless of how the Web service is implemented and accessed.
WSIF allows stubless or completely dynamic invocation of a Web service, based upon examination of the meta-data about the service at runtime. It also allows updated implementations of a binding to be plugged into WSIF at runtime, and it allows the calling service to defer choosing a binding until runtime.
Finally, WSIF is closely based upon WSDL, so it can invoke any service that can be described in WSDL.
What does all this enable? Imagine your complicated Enterprise software system consisting of various pieces of software, developed over a period of tens of years - EJBs, legacy apps accessed using Java's connector architecture, SOAP services hosted on external servers, old code accessed through messaging middleware. You need to write software applications that use all these pieces to do useful things; yet the differences in protocols, mobility of software, etc. comes in the way.
The software you use moves to a different server, so your code breaks. The SOAP libraries you use change - say for example you moved from using Apache SOAP to Apache Axis - so your code breaks since it uses a now deprecated SOAP API. Something that was previously accessible as an EJB is now available through messaging middleware via JMS - again, you need to fix the code that uses the software. Or let's suppose you have an EJB which is offered as a SOAP service to external clients. Using SOAP obviously results in a performance penalty as compared to accessing the EJB directly. Of course, SOAP is a great baseline protocol for platform and language independence, but shouldn't java clients be able to take advantage of the fact that the software they are accessing is really an EJB? So your java customers pay a performance penalty since you have to use SOAP for to accommodate you non-java clients.
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.
Read more about this topic: Web Services Invocation Framework
Famous quotes containing the words description of and/or description:
“The Sage of Toronto ... spent several decades marveling at the numerous freedoms created by a “global village” instantly and effortlessly accessible to all. Villages, unlike towns, have always been ruled by conformism, isolation, petty surveillance, boredom and repetitive malicious gossip about the same families. Which is a precise enough description of the global spectacle’s present vulgarity.”
—Guy Debord (b. 1931)
“The next Augustan age will dawn on the other side of the Atlantic. There will, perhaps, be a Thucydides at Boston, a Xenophon at New York, and, in time, a Virgil at Mexico, and a Newton at Peru. At last, some curious traveller from Lima will visit England and give a description of the ruins of St Paul’s, like the editions of Balbec and Palmyra.”
—Horace Walpole (1717–1797)