• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Jeanne Boyarsky
  • Tim Cooke
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
Bartenders:

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

 
Ranch Hand
Posts: 182
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.



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?




  • 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
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Ranch Hand
    Posts: 62
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Ranch Hand
    Posts: 62
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I'm not quite sure if I understand your question. I suspect that this relates to this area of the web.xml:

    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
    Ranch Hand
    Posts: 62
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Ranch Hand
    Posts: 62
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks a lot Peer.

     
    No more fooling around. Read this tiny ad:
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic