Browse Prior Art Database

Exposing non-compliant JAVA services as Basic Profile compliant JAX-WS Web Services

IP.com Disclosure Number: IPCOM000180142D
Original Publication Date: 2009-Mar-04
Included in the Prior Art Database: 2009-Mar-04
Document File: 3 page(s) / 25K

Publishing Venue

IBM

Abstract

Exposing non-compliant JAVA services as Basic Profile compliant JAX-WS Web Services

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 1 of 3

Exposing non-compliant JAVA services as Basic Profile compliant JAX -WS Web Services

This design provides the capability to web service-enable non-compliant (JAX-WS) JAVA services as basic profile compliant JAX-WS web services. This design eliminates the need for additional coding by the java service developer to web service enable the JAVA services.

Limitations


JAX-WS compliant services require JSR-181 annotations to support web service enablement. This invention allows those same JSR-181 annotations to be used with non-compliant JAX-WS classes. This allows these services to be web service enabled in the same manner as compliant services. The primary advantage is that there is no longer a requirement to provide, continually maintain and enhance a proxy service services for each implementation.

Standards like JAX-WS help with exposing POJO and stateless session EJBv3 as Web services. However there are restrictions related to Accessibility, Method Type and Method Parameter Types that limit the scope of services that can be web service enabled.

The following types of JAVA services cannot be deployed as Web Services using JAX-WS:

A JAVA service that has a private constructor with a factory method to access the service.

An RMI service which has to be looked up from the RMI registry or from a bootstrap service factory method.

Limitations prevent static methods from being exposed as WSDL operations.

JAX-WS uses JAXB for marshalling/un-marshalling a service request and response, schema generation and data binding. However it has limitations in its support for dynamic data types and any solution requires custom code. One way to work around the limitations listed above would require writing a proxy service class [conforming to the Web service standards] for each of these services and then deploy those as Web Services.

Solution


Since JAX-WS compliant services require JSR-181 annotations to support web service enablement, this design allows those same JSR-181 annotations to be used with non-compliant JAX-WS classes. This allows these services to be web service enabled in the same manner as compliant services.

The primary advantage is that there is no longer a requirement to provide, continually maintain and enhance a proxy service services for each implementation.

As mentioned earlier, there are limitations identified that result in non-compliant

1

Page 2 of 3

JAX-WS service classes. With proper class, method and parameter level metadata information we can overcome those limitations to expose these JAVA services as JAX-WS Web Services. The metadata information can be provided either through annotations or through the deployment descriptors.

Resolving the Accessibility problem

This innovation introduces 2 new class level annotations @WSConnector(..) and @WSConnectorProperty(name,value) to provide the metadata information related to obtaining the handle of the JAVA service class.

The WSConnector annotat...