service interface in both web.xml and webservices.xml?

[hani Ibrahim]

Dear all,
i cant distinguish why service-interface,wsdl-file,jaxrpc-mapping-file ..etc exists in both web.xml and webservices.xml
would anyone explain to me why that?

[Mike Pandey]

Hi Guys,

Does that mean the webservices.xml is just used while generating server side artifacts?

Also, could you please explain as to how service-ref element in web.xml, the webservices.xml file and the jax-rpc mapping play a role at the runtime if any?

Please help clear my doubts.

Thanks,
Mike

[Peer Reynders]

I'm not sure if the spec details when the information is used (deployment vs. runtime).
It may be up to the container to decide if changes in the descriptors are detected at start up time, or whether a redeploy is necessary.

RMH Chapters 22,23,24 cover this topic pretty well.
Based on what you find there, make yourself a skeleton web.xml, ejb-jar.xml and webservices.xml (i.e. what elements can appear in there). Copy those, then flesh out the ones that pertain to web services and annotate them for your own use.

Example: The service-ref is basically a web services version of the ejb-local-ref descriptor which is a JNDI addressable component.

<?xml version="1.0" encoding="UTF-8"?>
<web-app � >
    �
    <ejb-local-ref>
        <ejb-ref-name>ejb/BookHomeLocal</ejb-ref-name> [B]<!-- Endpoint can access this through JNDI -->[/B]
        <ejb-ref-type>Entity</ejb-ref-type>
        <local-home>com.companyz.BookHomeLocal</local-home>
        <local>com.companyz.BookLocal</local>
        <ejb-link>BookEJB</ejb-link>
    </ejb-local-ref>
    �
</web-app>

So when a servlet accesses a web service as a component the container needs to resolve a number of issues:

What service interface is exposed by the component

What are the end point interfaces exposed by the component?

How is information in the SOAP headers processed?

<?xml version="1.0" encoding="UTF-8"?>
<web-app � >
    �
    <service-ref> [B]<!-- Specified because HypotheticalServlet accesses the Web service -->[/B]
        <service-ref-name>service/BookQuoteService</service-ref-name>[B]<!-- JNDI name -->[/B] 
        <service-interface>com.jwsbook.jaxrpc.BookQuoteService</service-interface>
        <wsdl-file>WEB-INF/wsdl/BookQuote.wsdl</wsdl-file>
        <jaxrpc-mapping-file>WEB-INF/mapping.xml</jaxrpc-mapping-file>
        <service-qname>mh:BookQuoteService</service-qname> [B]<!-- Required Service name in the WSDL (fully qualified) -->[/B] 
        <port-component-ref> [B]<!-- Only necessary for dynamic proxies (Service.getPort() method) -->[/B]
            <service-endpoint-interface>
                com.jwsbook.jaxrpc.BookQuote
            </service-endpoint-interface>
            <port-component-link>BookQuoteJSE</port-component-link> [B]<!-- Only if service is in the same J2EE application. Could also be prefixed with the JAR path (#) containing the component -->[/B]
        </port-component-ref>
        <handler xmlns:ds="http://schemas.xmlsoap.org/security/2000-12" > [B]<!-- Client-side handler, similar to the handler element in the webservices.xml -->[/B]
            <handler-name>ClientSecurityHandler</handler-name> [B]<!-- Name must be unique across all deployment descriptors in the archive -->[/B]  
            <handler-class>com.jwsbook.jaxrpc.sec09.ClientSecurityHandler</handler-class>
            <init-param> [B]<!-- Returned by java.util.Map HandlerInfo.getHandlerConfig() -->[/B]
                <param-name>KeyAlgorithm</param-name>
                <param-value>DSA</param-value>
            </init-param>
            <init-param>
                <param-name>KeySize</param-name>
                <param-value>512</param-value>
            </init-param>
            <init-param>
                <param-name>SignatureAlgorithm</param-name>
                <param-value>SHA1</param-value>
            </init-param>
            <soap-header>ds:Signature</soap-header> [B]<!-- Processing these header(s) -->[/B] 
            <soap-role>Security</soap-role> [B]<!-- Role(s) assumed when processing header(s) -->[/B]
            <port-name>BookQuotePort</port-name> [B]<!-- Which WSDL port is the handler installed for -->[/B] 
        </handler>
    </service-ref>
    �
</web-app>

So

service-interface - (service) interface exposed by the component.

wsdl-file, jaxrpc-mapping-file and service-qname - the WSDL specifies the original WSDL interface and soap bindings while the mapping file maps Java endpoint interfaces to particular WSDL ports and soap bindings.

port-component-ref - dynamic proxies don't use WSDL with mapping files. So this is where you specify the necessary service-endpoint-interface (which would otherwise be specified in the mapping file). This is mutually exclusive with wsdl-file, jaxrpc-mapping-file and service-qname.

handler - this is the declaration of a single handler in your client-side handler chain. Here we are consuming a web service. Handlers specified in webservices.xml are server-side handlers for a web service being published.

handler-name - name of the handler that other parts of the descriptor use to refer to the handler

handler-class - actual java class implementing the handler

init-param - handler configuration information

Do the same kind of thing for the other web.xml descriptors, the descriptors in ejb-jar.xml, webservices.xml and possibly the mapping file and soon the big deployment picture will become clear to you.

[Peer Reynders]

Originally posted by hani Ibrahim:
i cant distinguish why service-interface,wsdl-file,jaxrpc-mapping-file ..etc exists in both web.xml and webservices.xml

The "obvious" reason:
The descriptors in the web.xml refer to web services being consumed; the servlet is a web service client. The webservices.xml refers to web services being published by the application server - the actual web service is being configured.
[ June 19, 2007: Message edited by: Peer Reynders ]

[Mike Pandey]

Thanks Peer for the clarification.

I read through Ch 22 & 23 in RMH and few other doubts have originated.

It says, the <service-ref> in web.xml would help the Web Clients in generation some skeleton code which helps in SOAP messages generation for a operation call from Client.

It also says that the port definition in webservices.xml would be used at endpoint to generate 'JAXRPC servlet' kinda code which would do the marshalling of SOAP messages into Java Method calls.
Further, it talks about defining the Implementation class in web.xml as Servlet. This is also fine.

But how would the web container know to direct webservice calls to the generated JAX RPC servlet which embeds the JSE?
And where does the mapping go in web.xml to declare the generated Code as Servlet?

Thanks,
Mike

[Peer Reynders]

Originally posted by Mike Pandey:
But how would the web container know to direct webservice calls to the generated JAX RPC servlet which embeds the JSE?
And where does the mapping go in web.xml to declare the generated Code as Servlet?

You are not concerned about that. The settings for the generated JAX-RPC servlet may or may not be in the web.xml.
Your application server vendor could very well decide to divert web service requests before they reach the web application container - and have them processed by a "web services container" that is totally under the control of the application server. If you like, you could think of the webservices.xml as the deployment descriptor for that "web services container".

Your concern with the web.xml is how you make the web service client stubs (components) available to the servlets in the web application container that consume web services.

PS: I once fiddled with the Sun Java System Application Server PE 8.2 which had the JWSDP installed. I installed a filter in the request handler chain of the web container. The filter saw all the requests coming in for all the servlets and JSPs that were deployed in the web container. It never fired for any web service requests. In that sense it was handy to complete the SCWCD before the SCDJWS.
[ June 21, 2007: Message edited by: Peer Reynders ]

[Mike Pandey]

Thanks once again Peer!!

But another doubt here....

I installed a filter in the request handler chain of the web container. The filter saw all the requests coming in for all the servlets and JSPs that were deployed in the web container. It never fired for any web service requests.

Let us assume I have a Implementation marked as servlet in web.xml and webservices.xml too marks it for a given Port component.
Now if I have a filter mapping for that particular servlet, does the above stmt mean that any webservice Reqst for that port will not pass through this filter?

Thanks,
Mike

[Peer Reynders]

I'm not quite sure if I understand your question. I suspect that this relates to this area of the web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-app � >
    �
    <servlet>
        <servlet-name>BookQuoteJSE</servlet-name>
        <servlet-class>com.jwsbook.jaxrpc.BookQuote_Impl</servlet-class>[B]<!-- Note: BookQuote_Impl is NOT a servlet; 
                                                                                But this gives it a name and associates the 
                                                                                implementing class with it other information 
                                                                                like WSDL, JAX-RPC mapping file, end-point 
                                                                                interface etc. is specified in the webservice.xml 
                                                                                where it is linked to this servlet through the 
                                                                                servlet link element which specifies the name in the 
                                                                                servlet-name element. -->[/B]
        <init-param> [B]<!-- USELESS -->[/B]
            <param-name>limit</param-name> [B]<!-- endpoint isn�t a servlet � NO WAY to get at these -->[/B]
            <param-value>1000</param-value>
        </init-param>
        <load-on-startup>5<load-on-startup> [B]<!-- lazy load if omitted or negative. 0 is loaded first. -->[/B]
        <run-as>
            <role-name>MHApplication</role-name> [B]<!-- logical security identity under which the endpoint will execute -->[/B]        
        </run-as>
        <security-role-ref> [B]<!-- used with programmatic security isUserInRole() -->[/B]
            <role-name>ADMIN</role-name> [B]<!-- role tested with isUserInRole() -->[/B]
            <role-link>employee</role-link> [B]<!-- actual logical role in the application -->[/B]
        </security-role-ref>
    </servlet>
    �
</web-app>

See also RMH Page 666 and Figure 22-6. That element says servlet but it is actually configuring the endpoint BookQuoteJSE running inside a JAX-RPC Servlet, it isn't configuring the JAX-RPC servlet itself. It simply uses the existing mechanism for naming the endpoint so that it can be referenced with servlet-link or port-component-link descriptors. This (servlet-link) name is used by the webservice.xml to reference deployment information that is specific to a JSE, just like a (ejb-link) name is used to reference info specific to an EJB endpoint (RMH 699; Listing 23-5).

These "link" descriptors are of particular interest to platform vendors who might offer optimizations where clients of a web service that are deployed on the same application server as the web service itself, can bypass the conversion to HTTP (and possibly SOA). These optimizations would bypass filters anyway (and would possibly bypass even the JAX-RPC handlers).

Point: The servlet descriptor configures the JSE not the JAX-RPC Servlet.

Now RMH 669; Table 22-1 seems to indicate that filters can effectively see the HTTP request, responses for JSEs.

Contemplating on the context of my experiments I now seem to recall that the web service in question was in fact an EJB endpoint. Basically if you needed access to the raw HTTP request (at the time my intent was to grab the requestor's IP address and stuff it in a SOAP header to make it available to the JAX-RPC handlers) then you are limited to a JSE. It seemed that the EJB container was doing its own "HTTP thing" - ignoring the already existing capabilities in the web container.

In conclusion: I would guess that for a JSE a filter can see the JSE's HTTP requests and responses � however the filter will not see any of the HTTP requests and responses for any EJB endpoint in the same J2EE application.

[Mike Pandey]

Thanks Peer.

RMH 669; created the confusion.

we declare the JSE as Servlet only for mapping purpose and it is not a Servlet then I have a question on the foll stmt

In conclusion: I would guess that for a JSE a filter can see the JSE's HTTP requests and responses

I would reckon this to be fine if the filter was linked to with JAX-RPC Servlet. How would JSE go around?

guess this thread is getting longer and longer...

Thanks once again.

[Peer Reynders]

Originally posted by Mike Pandey:
How would JSE go around?

(Again, if I understand your question correctly) I seem to nebulously recall that the specification was a bit open to interpretation of how the JAX-RPC servlet would work. It could either simply be a single servlet that acted like a front controller to all deployed JSE's (like Axis) or the application platform could actually generate a separate JAX-RPC servlet for each deployed JSE.

[Mike Pandey]

Thanks a lot Peer.