Jitendra Kotamraju wrote:
> 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).
I must admit that the document is little out-of-date w.r.t names.
Jitu
>
> 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
>>
>
> ---------------------------------------------------------------------
> 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
>