The web services modules and APIs have continually evolved with the underlying technology, from JAXRPC to JAXWS, and now, support for other runtimes such as Axis2. Further complicating this is the requirement to support different containers such as Glassfish, JBoss, and Tomcat. Initially, the APIs, SPIs and support for both the JAXRPC and JAXWS coexisted in the various web services modules. In NB 6.0, the JAXRPC and JAXWS support were explicitly separated into two distinct parts, which was a major improvement in the module structure. See Milan's description of this effort in But now, as we anticipate to support more technologies and more containers there is a need to further refine our APIs and module structure.

Why Are We Doing This?

For several reasons:

  • Refocus the APIs and modules so that it can accomodate new web service stacks seamlessly.
  • We need a stable API to entice external contributors to implement new and exciting web service technologies.
  • Eliminate duplicate code.
  • Improve support for different containers.
  • Improved APIs will facilitate more test coverage of the modules.

Where We Are Now

The following diagram is a rough illustration of the current web service support structure: File:websvc_current_ReviewAndStabilizeWebServiceAPIs.JPG

Where We Want to Be

The following diagram illustrates the initial concept of the desired API structure: Image:websvc-api_ReviewAndStabilizeWebServiceAPIs.png

Closer Look

The following diagram is a closer look at the relationships among the different web service modules. The modules near the top expose APIs either as public or "friend" dependencies: Image:websvc_ReviewAndStabilizeWebServiceAPIs.jpg



Be build system independent

Current websvc APIs heavily depend on Ant. If we want to support other build systems (like ie. maven), we should have websvc APIs build system independent

Contract between WS support and server plugins

Current contract is defined by isToolSupported(String):boolean, getToolClasspath(String):File[[ | ]] method and related String constants in J2eePlatform class in J2eeserver module. For server plugin developer it might not be clear what he should return from given methods. The idea is to define the contract by some abstract/final class or interface and let the ws support work only with this object.

Proposed Solution

In Web Services API module there would be defined an object which would be an abstraction of particular web services stack for given environment (ie. JDK, serverplugin). This object would have following abilities:

  • has defined sth like ID (to be able to say whether it is JAX-RPC, JAX-WS, Axis,...)
  • knows about a tool for generating WSDL and its classpath (ie. wsgen, wscompile)
  • knows about a tool for proceeding WSDL and its classpath (ie. wsimport, wscompile)
  • knows about paths to keystore, truststore etc within given environment
  • knows if particular ws stack in given environment supports a particular capability * (ie. wsit, JSR-109)

* possible capabilities would be strictly defined as constants of some type (not Strings) in the API - this would give us better control of what's used where and why

Implementation details

  • server plugin would provide 0..n instances of WsStack SPI implementation in a lookup IZ #133853 - one for each possible ws stack configured directly on the server (ie. for glassfish there would be one instance describing JAX-WS and one JAX-RPC; for Tomcat 5 there would be no instance, for Tomcat with JWSDP configured on the server there would be one instance etc), once a server plugin would return no instance then the default behaviour would be to look for the Ws Stack impl within the IDE (ie. JAX-WS/Metro library) and add it only to a project
  • there should be some way to compute URL on which the web service will be published

Suggested Web Service Server API (Contract between WS and J2ee Server)


IZ #129323 - Provide Web Services API/SPI for serverplugins
IZ #133853 - Add lookup to J2eeModuleImplementation to make it extensible

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo