TECHNOLOGY: Industry Standard
Web Services—Anyhow, Anywhere
By Marta Bright
WSIF lets you access Web services independent of protocol or location.
Flexible. Faster. Better. Easier. These are words that every developer not only loves to hear, but also steadfastly wants to believe in. But when you're developing Web services, integrating legacy applications with newer services across different protocols, are there any magic standards that help cut down on time and effort? There's Web Services Invocation Framework (WSIF), so the answer is yes.
WSIF was created to offer a simple Java API for invoking Web services, no matter how or where the services are provided. What's more, WSIF presents a unique set of benefits by helping to form the centerpiece of an integration framework that can access software running on diverse platforms and using widely varying protocols.
WSDL Is as WSIF Does
Why is WSIF such a cool tool for developing Web services? The answer lies in WSIF's relationship with both Web Services Definition Language (WSDL) and Simple Object Access Protocol (SOAP).
WSDL is an XML format that describes network services as a set of endpoints that operate on messages containing either document-oriented or procedure-oriented information. A WSDL binding defines how to map between abstract and real service formats and protocols, while a WSDL document describes the locations of the Web services.
The WSDL document is part of the WSIF architecture; this architecture also contains the WSIF Service interface, the WSIF Operation, and the WSIF Provider. A WSIF Service interface generates an instance of the WSIF Operation. A WSIF Operation invokes a service based on a particular WSDL binding. A WSIF Provider is an implementation of a WSDL binding that can run a WSDL operation through a binding-specific protocol.
Got all that? WSIF includes providers—protocol-specific code—for Java Messaging Services (JMS), Java, Enterprise Java Beans, and SOAP. SOAP, which is used to connect disparate systems, is a lightweight protocol for exchanging information in a decentralized, distributed environment. It's a protocol closely associated with Web services.
WSIF Takes the Sting Out of SOAP
According to Bill Eidson, a consulting member of Oracle's technical staff, without WSIF, SOAP can be somewhat limiting. "In many systems, you don't necessarily want to use SOAP within a particular application if you're working with the database or other adapters, because of issues such as performance and scalability," he says. (The database adapter contains SQL commands that let applications read data from and write data to a database—for example, Oracle9i Database.) "WSIF steps in and lets you take advantage of the fact that the WSDL specification doesn't say that all services must use SOAP."
WSIF views SOAP as one of many —with an emphasis on many—ways to expose software functionality. "WSIF leverages the extensibility aspect of WSDL that a lot of other Web services libraries don't," says Eidson. "The WSIF library, which takes advantage of WSDL's binding extensibility, provides a framework for plugging in non-SOAP technologies such as the database adapter, Java, and Enterprise JavaBeans."
WSIF in Action
The WSIF API lets clients invoke services that focus on the abstract service description—the portion of WSDL that covers port types, operations, and message exchanges—all without referring to real protocols. Abstract invocations are appropriate in this environment because they're backed up by providers that conduct the message exchanges according to the specifics of a particular protocol.
"One of the really neat things about WSIF," explains Bo Stern, a principal member of Oracle's technical staff, "is that when you use WSDL to capture machine-understandable information for the Web, it splits the information into two pieces—an abstract service description and a concrete service description—with the latter acting as the binding section of WSDL. For example, when you use WSDL to capture an interface contract, WSDL enables the expression of this contract in abstract terms through the use of port types, operation names, input parameters, output parameters, and all their data types. All of your different operations can be disassociated from how the implementation of those operations is actually carried out."
The net benefit, Stern says, is that WSIF completely eliminates the dependence on the outside world. "Let's say that tomorrow, instead of using Java Connection Architecture (JCA), you want to use SOAP or another kind of binding or communication protocol," he says. "With WSIF you don't have to touch the business process at all. You can simply modify the binding in WSDL, and both the contract and abstract service descriptions will remain the same. From there you simply swap out the binding from JCA to SOAP, and the business process doesn't change at all."
The WSIF-BPEL-Oracle Connection
Oracle's history with Business Process Execution Language (BPEL) and WSIF goes back to the early days of a process management software engine developed by Silicon Valley-based Collaxa. Collaxa's core product, called BPEL Server, collected data from different applications to complete a particular business process—handling insurance claims, for example.
Oracle successfully jump-started the emerging BPEL effort after acquiring Collaxa in June 2004. "At the time, Collaxa had one of the world's first true implementations of the BPEL language," Stern recalls. "When we acquired Collaxa, we'd been developing JCA adapters and found that we could actually reuse that effort." At the time, Stern had been working on a project developing adapters that could send a variety of documents over a variety of protocols, including HTTP, FTP, and SMTP. "Because Collaxa decided to base its BPEL implementation on WSIF, it was easy to extend the reach of the product by simply plugging in another WSIF provider—a JCA WSIF provider," says Stern. "This helped us repurpose work and move from one project to the next." The project Stern mentions produced Oracle BPEL Process Manager, Oracle's standards-based tool for creating, deploying, and managing cross-application business processes.
Getting applications based on multiple protocols to work together is hard enough, and adding new applications to the mix—using protocols not even imagined when the oldest applications in the stack were developed—is an inevitable next step. WSIF directly addresses this challenge by letting you use WSDL as both a normalized description of disparate software and as a way to access software regardless of protocol or location.
Marta Bright (firstname.lastname@example.org) is a senior editor for Oracle Publishing.