users@jax-ws.java.net

Re: 1:1 mapping between business logic and service implementation class

From: Jitendra Kotamraju <Jitendra.Kotamraju_at_Sun.COM>
Date: Fri, 30 Mar 2007 13:46:52 -0700

Angel Todorov wrote:
> Hi Vivek,
>
> Ok, this fulfills my expectations to a great extent. One last question:
>
> Does this mean that when using the Provider API, the SOAP message will
> go through the same chain as described here:
>
> [1]
> https://jax-ws-architecture-document.dev.java.net/nonav/doc21/com/sun/xml/ws/server/package-summary.html
>
>
> , or the above is only used for POJO annotated services ? Thank you.
Same architecture for Provider endpoints also. Though the chanin may
consists of different tubes(for e.g instead of SEIInvokerTube,
ProviderInvokerTube).

Jitu
>
> Regards,
> Angel
>
> On 3/30/07, Vivek Pandey <Vivek.Pandey_at_sun.com> wrote:
>> Hi Angel,
>>
>> Angel Todorov wrote:
>> > Hi Vivek,
>> >
>> > Thanks. That's what I had in mind. it seems it is indeed suitable when
>> > one doesn't want to have 1:1 mapping and wants to reuse one provider
>> > for calling different "functions" from a backend.
>> >
>> > I have several additional questions though, which didn't become clear
>> > to me from the documentation:
>> >
>> > 1) Are attachments (mostly, MTOM) supported when the Provider way is
>> > used ?
>> Yes.
>> > 2) If I don't configure any explicit handlers for the provider, is
>> > there any SOAP validation taking place before invoke() is called ?
>> the SOAP validation rules apply (as mentioned in SOAP 1.1 and BP 1.1).
>> However it applies only to SOAP/HTTP binding.
>> > 3) Am I always left with the option to generate the SOAP response by
>> > hand (AddNumbersImpl provider sample) ? Is there any way to stream the
>> > SOAP response using an XMLStreamReader or something like this ?
>> You may like to look at the JAX-WS RI specific Provider<Message>
>> support. See [1] for details.
>> > 4) How can I access, from the invoke() method , properties related to
>> > the service / operation , i.e. stored on a level above the actual
>> > current message?
>> >
>> you mean wsdl:operation wsdl:service names? I think jitu added support
>> for these couple weeks back.
>>
>> thanks,
>>
>> -vivek.
>> [1]http://weblogs.java.net/blog/kohsuke/archive/2007/03/dispatch_and_pr.html
>>
>> > Thanks in advance very much.
>> >
>> > Best Regards,
>> > Angel
>> >
>> > On 3/23/07, Vivek Pandey <Vivek.Pandey_at_sun.com> wrote:
>> >> You may like to checkout Provider based endpoint that can serve the
>> >> incoming message in a generic way and then it can dispatch it to the
>> >> appropriate endpoint.
>> >>
>> >> See https://jax-ws.dev.java.net/nonav/2.1/docs/provider.html for
>> >> details.
>> >>
>> >> -vivek.
>> >>
>> >> Angel Todorov wrote:
>> >> > Hi,
>> >> >
>> >> > I would like to ask whether in JAX-WS, I always have to have one to
>> >> > one mapping between a service and a java implementation class,
>> >> > annotated with @WebService . Is it possilble to have a generic java
>> >> > class which , based on a service name, and the operation name,
>> (and
>> >> > maybe some namespace), dispatches requests to some internal
>> business
>> >> > logic ?
>> >> >
>> >> > For example, using Axis2 i don't need to have a service
>> implementation
>> >> > class. I can decide to which backend to dispatch (having
>> transformed
>> >> > it) the request using the MessageReceiver concept.
>> >> >
>> >> > Thanks very much for your feedback.
>> >> >
>> >> > Regards,
>> >> > Angel
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe_at_jax-ws.dev.java.net
>> >> > For additional commands, e-mail: users-help_at_jax-ws.dev.java.net
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe_at_jax-ws.dev.java.net
>> >> For additional commands, e-mail: users-help_at_jax-ws.dev.java.net
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe_at_jax-ws.dev.java.net
>> > For additional commands, e-mail: users-help_at_jax-ws.dev.java.net
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jax-ws.dev.java.net
>> For additional commands, e-mail: users-help_at_jax-ws.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: users-help_at_jax-ws.dev.java.net
>