Anshuk Pal Chaudhari

Subscribe to Anshuk Pal Chaudhari: eMailAlertsEmail Alerts
Get Anshuk Pal Chaudhari: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal, Apache Web Server Journal, Open Web Magazine

J2EE Journal: Article

Web Service Invocation Framework

Adding wheels to Web services

The open source initiatives have transformed the technical landscape by leaps and bounds in the past two decades. It has gone a long way toward breaking the stranglehold of monopolistic software companies over technologies. When programmers have the ability to read, redistribute, and modify the source code for a piece of software, the software evolves faster and better. It happens at a speed that is way faster compared to the slow pace of conventional software development.

Web Services and Open Source
Today there is a glut of choices for developers of software. The choices extend from choosing operating systems to application development framework components. The business enterprises are now harnessing the power of open source by using ready-made open source components and frameworks. This helps the enterprises save on development costs and also cut down on project implementation time.

The introduction of Web services has now provided a way of integrating applications based on open standards seamlessly across technologies. The emergence of Web services can primarily be attributed to the open source community. It also has brought the leading technology vendors across the spectrum, endorsing and supporting open source in a big way.

The Need for a Web Services Invocation Framework (WSIF)
Currently the programming models in the J2EE framework support synchronous and asynchronous invocations. However this is accomplished by using two different programming models, shown in the subsections below.

JAXM (Java API for XML Messaging)
JAXM provides a rich set of interfaces for implementing message-oriented asynchronous invocation of Web services. One of the bigger advantages of JAXM is that it does not limit message standards restricted to SOAP. Hence we can have a rich set of message standards and have different message approaches that can include vertical specific schemas like Accord for insurance, FiXml for the financial industry, etc. However JAXM lacks fully formed asynchronous message profile support and requires a domain-specific profile.

JAX-RPC for RPC-style synchronous communication
JAX-RPC is now inherently embedded as a part of a J2EE specification. It is very easy to develop potentially complex RPC-based Web services. However, RPC-based Web services lead to tight coupling between the service providers and the consuming clients. RPC basically supports a synchronous model where the client has to wait until the execution of the remote procedure is completed.

This necessitates a developer to have knowledge of two different sets of APIs, so this fuelled the need for a framework that would be an abstraction layer above the various programming models. Thus this abstraction layer will be responsible for the invocations across varied bindings. This also has the ability to future-proof the enterprise services against change in the SOAP API, for instance, Apache SOAP to Apache Axis.

Say, for example, we have a very intricate software system composed of various chunks of software - message-driven beans, mainframes, Java classes, JMS, and Web service. The objective now is to write an application that will in turn utilize all of these chunks of software and accomplish some result. The moment we take that application to a different server, the complete code breaks; furthermore, there is number of issues associated with this situation.

WSIF fixes the problems by allowing WSDL to be the normalized description of the complete software system and will allow us to access that system independently of the protocol and the location. So it may be a SOAP, an EJB, or JMS - we have an API centered on WSDL that we utilize to access the functionality. The separation of the API from the actual protocol also means we have flexibility - we can switch protocols, location, etc. without having to even recompile the client code. So if an available EJB becomes available as a SOAP service, we only need to change the service description (the WSDL), without having to make any changes in applications that use the service.

The motivation for WSIF is that we wanted to see the "services-oriented architecture" become more extensive than just SOAP. There are a number of different protocols, transports, and distributed computing technologies that offer more than SOAP does today - especially in terms of management, transactions, security, and other quality of service (QoS) features.

Therefore the primary goals of the WSIF are:

  • To have a binding-independent mechanism for Web service invocation
  • To prevent clients from experiencing the hassles of binding to a particular protocol for a Web service
  • To allow dynamic selection between multiple bindings to a Web service
  • To facilitate the development of Web service intermediaries
Introduction to WSIF
WSIF is a toolkit that provides a simple API for invoking Web services irrespective of their technical bindings. WSIF provides a way to call any service regardless of the transport protocol or where it is located. It allows the description of the application code, which might be Simple Java Classes or Enterprise Java Beans or Java Messaging Service or Web service, etc. in the Web Service Description Language (WSDL). The WSIF API allows clients to invoke services that focus on the abstract service description. In a WSDL the service is described in terms of the following parts:
  • Port Type: Defines the abstract interface of the service
  • Binding: Defines how to map among the abstract interface, a service format, and the underlying protocol
  • Message: Defines the request and the response of the corresponding methods and services
  • Port: Defines the actual endpoint where the service is located, e.g., the implementing class for Java Binding
WSIF Architecture
The main components of the WSIF architecture are as follows:
  • WSIFProvider
  • WSIFServiceFactory
  • WSIFService
  • WSIFPort
  • WSIFOperation
  • WSIFMessage
The basic idea is to invoke the service by using the abstract description of the WSDL. It is carried out in the following steps:
  • Loading of WSDL Document
  • Creation of port factory for the corresponding service
  • Port factory is being used to receive the port
  • Creation of message
  • Invocation of the service by supplying the port with the operation name

More Stories By Anshuk Pal Chaudhari

The authors are interning and/or working as part of the Web Services COE (Center of Excellence) for Infosys Technologies, a global IT consulting firm, and have substantial experience in publishing papers, presenting papers at conferences, and defining standards for SOA and Web services. The Web Services COE specializes in SOA, Web services, and other related technologies.

More Stories By Sandeep Gaikwad

The authors are interning and/or working as part of the Web Services COE (Center of Excellence) for Infosys Technologies, a global IT consulting firm, and have substantial experience in publishing papers, presenting papers at conferences, and defining standards for SOA and Web services. The Web Services COE specializes in SOA, Web services, and other related technologies.

More Stories By Ambar Verma

The authors are interning and/or working as part of the Web Services COE (Center of Excellence) for Infosys Technologies, a global IT consulting firm, and have substantial experience in publishing papers, presenting papers at conferences, and defining standards for SOA and Web services. The Web Services COE specializes in SOA, Web services, and other related technologies.

More Stories By V. Niranjan

The authors are interning and/or working as part of the Web Services COE (Center of Excellence) for Infosys Technologies, a global IT consulting firm, and have substantial experience in publishing papers, presenting papers at conferences, and defining standards for SOA and Web services. The Web Services COE specializes in SOA, Web services, and other related technologies.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.