JAX-WS is a Java™ EE
technology that improves the speed of SOAP-service communication and
access. With EGL, you can generate SOAP services and service requesters
that use either JAX-WS or the predecessor technology, Java API for XML-based RPC (JAX-RPC). The current
intent is to base future enhancement of EGL SOAP-service support on
JAX-WS.
Services and service requests that rely on JAX-WS can interact
with other logic that relies on JAX-RPC. Runtime compatibility is
assured. In relation to EGL, JAX-WS gives you the added convenience
of generating a service only once, even if you subsequently deploy
the code as a SOAP service to multiple target projects.
The following restrictions apply:
- EGL support for JAX-WS is available only if the SOAP service or
service requester is deployed on a server that supports JEE version
5. Testing was on the following platforms:
- WebSphere® Application
Server 7.0.
- Apache Tomcat 5.x, under Java 1.6.
- Apache Tomcat 6.x, under Java 1.6.
- When JAX-WS is in use, EGL structured records cannot be transferred
between a service and service requester. When JAX-RPC is in use, structured
records can be transferred; but if both the requester and service
are EGL generated, both the requester and service must run under JAX-RPC.
For details on the EGL support for structured records, see “Service
part reference.”
- If the EGL target project is a web project that includes services
or service requesters, the project can use only one of the two technologies;
either JAX-WS or JAX-RPC. When you generate or deploy code to the
target project, you cannot add support for services or service requesters
that use the other technology.
An earlier point is worth repeating:
Even though the Java EE technology
for accessing or deploying services must be the same for all the logic
in a given target project, each of the remote SOAP services being
accessed can be deployed under either of the two technologies. Runtime
compatibility is assured.
- If you worked in an EGL version previous to 8.0.1.1 and used a
WSDL file to automatically create an Interface part, Record parts,
or a service skeleton, the parts that you created are likely to cause
errors in the following case:
- You retain the parts that were created from the WSDL file; and
- You use those parts as the basis of code that you then generate
or deploy to a target project that is configured to use JAX-WS.
If you want to convert code that was written in an EGL version
previous to 8.0.1.1 so that the code can run with JAX-WS, re-create
the Interface part, Record parts, or service skeletons that are in
use in that code.
You
do not need to re-create Interface parts, Record parts, or service
skeletons in either of the following cases:
- You are generating or deploying code that was created in version
8.0.1.1 or greater; or
- You are regenerating or redeploying older code to a target project
that is also configured for JAX-RPC.
- If you have code that uses the getContext system
function, your code will need to change when you switch between JAX-RPC
and JAX-WS. The reason is that the object returned by getContext is
different in JAX-RPC and JAX-WS. For details, see “getContext.”
The factor that determines whether a target project is configured
for JAX-WS or JAX-RPC is a check box on the Deployment Descriptor
editor, in the Overview tab. A variation of
this rule is in effect for service requests that use @WebBinding,
which is a property that lets you specify service-access details directly
in the code logic; specifically, in the declaration of the service-access
variable. In this last case, the factor that determines how the service
request is configured is the value of the check box in the deployment
descriptor that is referenced by the build descriptor used to generate
the requester.
