Deployable versus Standalone Proxies 

SAP Web AS Java provides two types of Web service proxies:

·        deployable proxy – a Web service client that must be deployed on the J2EE Engine as an application.

·        standalone proxy – a Web service client that generates stubs and runs without the J2EE Engine. This proxy can be used only with the release for which it has been generated.

Although both proxies have similar functions, there are some fundamental differences.

For the standalone proxy, a stub must be generated and the names and class names of the transport bindings, protocols, and transports that are used must be provided. The drawbacks of this approach are that if a name of a component is changed or requires some modifications, the stub is no longer valid and the whole proxy needs to be regenerated.

On the other hand, with the deployable proxy all information is either generated during deployment or is retrieved at runtime. Therefore, the deployable proxies are to a certain degree protected from runtime changes.

For both types of proxies, ServiceInterface and ServiceImpl classes are generated. Their names are derived from the service name of the WSDL that is used to generate the particular proxy.

For the deployable proxies, only the ServiceInterface is generated at the design time. The client assigns a JNDI name under which the ServiceImpl instace is bound at runtime. The JNDI name is relative to the java:comp/env/ context, which is the default for all J2EE components.

// for Deployed WS Clients import javax.naming.InitialContext;   InitialContext ctx = new InitialContext(); FooServiceInterface fsi = (FooServiceInterface)ctx.lookup(“java:comp/env/FooService”);

 

At deployment, the service implementation and the service stub are generated. To take the service implementation for the standalone proxy, the generated class must be instantiated:

// for standalone WS clients FooServiceInterface fsi = new FooServiceInterfaceImpl();