EGL support for JAX-WS and JAX-RPC

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: 
    1. You retain the parts that were created from the WSDL file; and
    2. 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.