Featured White Papers

• What Developers Want: The End of Application Redeploys

Sponsored Links

• Career opportunities at Harman- Careers That’ll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Bridging islands of enterprise software

WSIF offers enterprise Java systems a bridge to any component or service, regardless of implementation or location

By Gautam Shah, JavaWorld.com, 09/26/05

Every enterprise software system must tie together numerous existing software systems and codebases. Such systems might need to access existing Enterprise JavaBeans (EJB) components, legacy code in Java, or Web services over SOAP. Such dependencies make enterprise software systems brittle. They tend to break when external systems change location or when implementation technologies change. Basing all your components and solutions on SOAP is not always the answer because a SOAP-based implementation has penalties. Web Services Invocation Framework (WSIF) is the answer. It provides your Java codebase total freedom for such platform and location vagaries.

Simply put, WSIF is a client-side invocation framework. It is a simple Java codebase with an API that sits between your client code and the services your code must access. It provides a layer of abstraction to decouple client code from access to a service, as well as its location and underlying implementation. Thereby, your Java code can access both SOAP and non-SOAP-based services in a transport-, language-, and platform-independent fashion. As will be demonstrated in examples below, with WSIF, you will find that your code does not need to change or be recompiled when the service implementation changes from Java classes to EJB, or to SOAP-based services, or to even .Net and COM-based (Component Object Model) services.

WSIF also provides location independence. A service's actual location is externalized in a configuration file. This allows your client code's access location to change with no code modifications or recompilation.

Just to give you an idea about WSIF's power, the following Java StockQuote client code will not change when the actual service provider moves from Java to EJB or to SOAP; the required interface remains.

                        ...   
// Create a service factory.
WSIFServiceFactory factory = WSIFServiceFactory.newInstance();
// Parse WSDL.
WSIFService service =
factory.getService('c://stockquoteservice.wsdl',
                  null,
                  null,
                  "http://mycompany.stockquote/",
                  "net.xmethods.services.stockquote.StockQuotePortType");
// Create the service stub, StockQuote.class is class generated by WSDL2Java for StockQuote service WSIF configuration file.
StockQuote service = (StockQuote) service.getStub(StockQuote.class);
// Do the invocations.
string symbol = "IBM";
string result = service.getQuote(symbol);
system.out.println("Price for " + symbol + " is " + result);
...
                   

Benefits of WSIF

An enterprise application usually consists of numerous pieces of software services developed over many years in assorted languages on various platforms with different protocols—pieces that must work together to provide business and operational functionality. These pieces constantly change: A service previously available as Java class may change to a Java Message Service-based implementation. Or a service that used a particular version of a SOAP implementation may be upgraded, leaving your code with a deprecated API. Or a service available as an EJB component internally within a company is outsourced to an external vendor and is now available as a SOAP-based service.