| 词条 | Web Services Invocation Framework |
| 释义 |
}}{{Infobox software | name = Apache WSIF | logo = | screenshot = | caption = | developer = Apache Software Foundation | latest_release_version = 2.0 | latest_release_date = January 27, 2003 | operating_system = Cross-platform | genre = Web services | license = Apache License 2.0 | website = {{URL|http://ws.apache.org/wsif}} }} The Web Services Invocation Framework (WSIF) supports a simple Java API for invoking Web services, no matter how or where the services are provided. The framework allows maximum flexibility for the invocation of any Web Services Description Language (WSDL)-described service. Using WSIF, WSDL can become the centerpiece of an integration framework for accessing software running on diverse platforms and using widely varying protocols. The only precondition is that the software needs to be described using WSDL, and to have included in its description a binding that the client's WSIF framework has a provider for. WSIF defines and comes packaged with providers for local Java, Enterprise JavaBeans (EJB), Java Message Service (JMS), and Java EE Connector Architecture (JCA) protocols, which means that a client can define an EJB or a Java Message Service-accessible service directly as a WSDL binding and access it transparently using WSIF, using the same API one would use for a SOAP service or a local Java class. StructureIn WSDL, a binding defines how to map between the abstract PortType and a real service format and protocol. For example, the SOAP binding defines the encoding style, the SOAPAction header, the namespace of the body (the targetURI), and so forth. WSDL allows there to be multiple implementations for a Web service, and multiple ports that share the same PortType. In other words, WSDL allows the same interface to have bindings to for example, SOAP and IIOP. WSIF provides an API to allow the same client code to access any available binding. As the client code can then be written to the PortType, it can be a deployment or configuration setting (or a code choice) which port and binding it uses. WSIF uses providers to support these multiple WSDL bindings. A provider is a piece of code that supports a WSDL extension and allows invocation of the service through that particular implementation. WSIF providers use the J2SE JAR service provider specification, making them discoverable at runtime. Clients can then utilize any new implementations and can delegate the choice of port to the infrastructure and runtime, which allows the implementation to be chosen on the basis of quality of service characteristics or business policy. Bindings for EJBs, JMS, and JCAWSIF defines additional binding extensions so that Enterprise JavaBean (EJBs), local Java classes, software accessible over message queues using the Java Message Service (JMS) API and software that can be invoked using the Java Connector architecture can also be described in WSDL. WSIF is packaged with providers that allow transparent invocation of such software given the corresponding WSDL description. DescriptionWSIF 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. If a complicated enterprise software system consists 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 – it is necessary to write software applications that use all these pieces to do useful things, yet the differences in protocols, mobility of software, etc. get in the way. If the software one uses moves to a different server, the code breaks. The SOAP libraries one uses change - for example, when one moves from using Apache SOAP to Apache Axis – so code breaks because 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 if one has an EJB which is offered as a SOAP service to external clients. Using SOAP results in a performance penalty as compared to accessing the EJB directly. SOAP is a 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 allowing WSDL to be used as a normalized description of disparate software, and allows one 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), there is an API centered around WSDL which is used to access the functionality, which lets one write code that adapts to changes easily. The separation of the API from the actual protocol also means there is flexibility - you can switch protocols, location, etc. without having to even recompile your client code. So if your externally available SOAP service becomes available as an EJB, one 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. Differences between WSIF and AxisAxis is an implementation of SOAP. It includes on the server-side infrastructure for deploying web service implementations and then routing SOAP messages between clients and those implementations. It also implements the JAX-RPC specification for invoking SOAP services. WSIF is similar to the client piece of Axis, in that it is used for invoking services. However, WSIF's API is WSDL-driven and protocol independent; it allows protocol-specific code ("providers") to be plugged in. For invoking SOAP services, WSIF is packaged with an Axis provider, that uses Axis APIs (i.e. JAX-RPC) to do the invocation. So WSIF operates at a more abstract level than Axis. Differences between WSIF and JAX-RPCJAX-RPC is an API for invoking XML-based RPC services – essentially its current scope is limited to invocation of SOAP services. WSIF is an API for invoking WSDL-described services, whether they happen to be SOAP services or not (for example, WSIF defines WSDL bindings so that EJBs, enterprise software accessible using JMS or the Java Connector architecture as well as local Java classes can all be described as first-class WSDL services and then invoked using the same, protocol-independent WSIF API). See also
ReferencesExternal links
2 : Web service specifications|Web services |
| 随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识，基本涵盖了大多数领域的百科知识，是一部内容自由、开放的电子版国际百科全书。