You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dennis Sosnoski <dm...@sosnoski.com> on 2011/11/16 09:21:37 UTC
WS-MakeConnection operation structuring
I'm having trouble implementing the WS-MakeConnection MakeConnection
operation, and I'm hoping somebody can give me some pointers. The
problem is that even though this looks like a SOAP operation, it really
is not - the response can be anything that's waiting for the endpoint,
with no predefined element or schema type. If I configure this using
Service/ServiceInfo/OperationInfo/etc., as we do for other WS-* protocol
endpoints, it looks like I have to make it a oneway operation (since the
response can be anything) - but if I then set a response message, it'll
be ignored.
What I want to do is to pop a message off an internal queue for the
address and make that the response. Any pointers on how I can make this
happen?
Thanks,
- Dennis
Re: WS-MakeConnection operation structuring
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
On 11/19/2011 10:55 AM, Daniel Kulp wrote:
> ...
> How about something along the lines of: create some sort of response message
> thing in the ServiceModel to make sure it's not treated as a one-way. Then
> likely add an interceptor on the out chain (at the very beginning) that would
> grab the content that should be returned and the associated
> BindingOperationInfo and such from the original service and reset the values
> on the Exchange to those and such.
>
> Actually, the make connection stuff, when ready, could just create the
> MessageContentsList and such like normal, set the binding and service stuff on
> the exchange, and let the normal OutgoingChainInterceptor handle the entire
> setup of everything. I think.
>
> That all said, I don't really know enough about the MakeConnection stuff to
> really know what it's trying to do.
I've tried looking into the approach you suggested, but I'm having a
hard time getting anywhere. Here's a quick overview of WS-MC to clarify
the concerns.
Mostly what WS-MakeConnection does is allow you to use asynchronous
responses without exposing a client endpoint. It does this by having the
client supply the server with a unique anonymous endpoint identifier (of
the form
http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id={unique-String})
for the ReplyTo on the request, then poll the server for responses using
the MakeConnection operation. This MakeConnection looks like a normal
one-way SOAP operation, but the back channel from the request will be
used for the first message waiting for that client, if any (as
identified by the unique endpoint identifier).
WS-MakeConnection is composable with WS-RM,
WS-Security/WS-SecureConversation, or both. Although the common use case
is as described above, where it is used to handle asynchronous
responses, it can also be used for other cases (at least in theory) -
for instance, as the endpoint for a pub/sub subscriber.
On the management of messages awaiting delivery, the specification notes
that "these messages form a class of asynchronous messages that is not
dissimilar from “ordinary” asynchronous messages that are waiting for
the establishment of a connection to their destination Endpoints."
It looks like OutgoingChainInterceptor is what sets up the conduit for
an asynchronous message in CXF, so it seems reasonable to implement the
WS-MC wait queue at that same point (with an interceptor just prior to
OutgoingChainInterceptor, I'd guess). This interceptor would suspend the
processing of the message after invocation of the service, only resuming
the processing when a MakeConnection request has established a back
channel connection for the response message. This would be prior to
WS-Security and WS-RM message mangling, so when the processing is
resumed these other technologies should just do their stuff as normal.
Does that sound about right?
On the client side, this should also use the same sort of handling as an
asynchronous response. The difference is just that polling with WS-MC
will be used rather than a separate listener.
- Dennis
Re: WS-MakeConnection operation structuring
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday, November 17, 2011 2:37:13 AM Aki Yoshida wrote:
> 2011/11/17 Dennis Sosnoski <dm...@sosnoski.com>:
> > Hi Aki,
> >
> > Yes, the response should be something the client is expecting - but the
> > problem is that that response is not part of the MakeConnect operation
> > definition.
> >
> > Like WS-RM and many other WS-* technologies, WS-MakeConnection defines a
> > service that resides at the same endpoint address as a user service. In
> > the WS-RM code, this situation is handled by defining the added service
> > using the same constructs as a normal CXF service - a ServiceInfo, an
> > InterfaceInfo linked to the ServiceInfo, an OperationInfo for each
> > operation, and MessageInfo and MessagePartInfo for each message. But for
> > WS-MakeConnection I don't think I can use this construct because there's
> > no set definition for the response message - even the response element
> > name is different, since it's just whatever message needs to be
> > returned. If I try creating a definition without setting a response, it
> > gets handled as a one-way operation and the response message I set in
> > the MakeConnection request processing is ignored.
>
> I thought initially we could use the dispatcher approach (i.e.,
> setting the XML Source as the response type) to get the response back.
> But I was not sure how and where this source object should be mapped
> to the "real" response object. So, instead, I thought we could
> dynamically define the operation for each particular MakeConnection at
> the endpoint or in other words, customizing this operation at each
> endpoint.
How about something along the lines of: create some sort of response message
thing in the ServiceModel to make sure it's not treated as a one-way. Then
likely add an interceptor on the out chain (at the very beginning) that would
grab the content that should be returned and the associated
BindingOperationInfo and such from the original service and reset the values
on the Exchange to those and such.
Actually, the make connection stuff, when ready, could just create the
MessageContentsList and such like normal, set the binding and service stuff on
the exchange, and let the normal OutgoingChainInterceptor handle the entire
setup of everything. I think.
That all said, I don't really know enough about the MakeConnection stuff to
really know what it's trying to do.
Dan
>
> > But I suspect that just substituting the message I've previously queued
> > up for the response is not even the correct approach, anyway. I need to
> > instead somehow take over the back channel from the request and use
> > that for sending the saved message, implementing all the processing
> > that should be done as per the message's interceptor chain (including
> > security processing). I've been trying to figure out how to do that,
> > but I'm pretty much lost.
> >
> > Dan, can you offer any suggestions on this?
> >
> > Thanks,
> >
> > - Dennis
> >
> > On 11/17/2011 12:34 PM, Aki Yoshida wrote:
> >> Hi Dennis,
> >>
> >> The response to the MakeConnection request may be arbitrary, but the
> >> client that wants to initiate a particular MakeConnection request
> >> might know what response to expect?
> >>
> >> I haven't thought about it and maybe I am missing the details.
> >>
> >> Regards, aki
> >>
> >> 2011/11/16 Dennis Sosnoski<dm...@sosnoski.com>:
> >>> I'm having trouble implementing the WS-MakeConnection MakeConnection
> >>> operation, and I'm hoping somebody can give me some pointers. The
> >>> problem is
> >>> that even though this looks like a SOAP operation, it really is not
> >>> - the response can be anything that's waiting for the endpoint,
> >>> with no predefined
> >>> element or schema type. If I configure this using
> >>> Service/ServiceInfo/OperationInfo/etc., as we do for other WS-*
> >>> protocol endpoints, it looks like I have to make it a oneway
> >>> operation (since the response can be anything) - but if I then set
> >>> a response message, it'll be
> >>> ignored.
> >>>
> >>> What I want to do is to pop a message off an internal queue for the
> >>> address
> >>> and make that the response. Any pointers on how I can make this
> >>> happen?
> >>>
> >>> Thanks,
> >>>
> >>> - Dennis
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: WS-MakeConnection operation structuring
Posted by Aki Yoshida <el...@googlemail.com>.
2011/11/17 Dennis Sosnoski <dm...@sosnoski.com>:
> Hi Aki,
>
> Yes, the response should be something the client is expecting - but the
> problem is that that response is not part of the MakeConnect operation
> definition.
>
> Like WS-RM and many other WS-* technologies, WS-MakeConnection defines a
> service that resides at the same endpoint address as a user service. In the
> WS-RM code, this situation is handled by defining the added service using
> the same constructs as a normal CXF service - a ServiceInfo, an
> InterfaceInfo linked to the ServiceInfo, an OperationInfo for each
> operation, and MessageInfo and MessagePartInfo for each message. But for
> WS-MakeConnection I don't think I can use this construct because there's no
> set definition for the response message - even the response element name is
> different, since it's just whatever message needs to be returned. If I try
> creating a definition without setting a response, it gets handled as a
> one-way operation and the response message I set in the MakeConnection
> request processing is ignored.
I thought initially we could use the dispatcher approach (i.e.,
setting the XML Source as the response type) to get the response back.
But I was not sure how and where this source object should be mapped
to the "real" response object. So, instead, I thought we could
dynamically define the operation for each particular MakeConnection at
the endpoint or in other words, customizing this operation at each
endpoint.
>
> But I suspect that just substituting the message I've previously queued up
> for the response is not even the correct approach, anyway. I need to instead
> somehow take over the back channel from the request and use that for sending
> the saved message, implementing all the processing that should be done as
> per the message's interceptor chain (including security processing). I've
> been trying to figure out how to do that, but I'm pretty much lost.
>
> Dan, can you offer any suggestions on this?
>
> Thanks,
>
> - Dennis
>
>
> On 11/17/2011 12:34 PM, Aki Yoshida wrote:
>>
>> Hi Dennis,
>>
>> The response to the MakeConnection request may be arbitrary, but the
>> client that wants to initiate a particular MakeConnection request
>> might know what response to expect?
>>
>> I haven't thought about it and maybe I am missing the details.
>>
>> Regards, aki
>>
>> 2011/11/16 Dennis Sosnoski<dm...@sosnoski.com>:
>>>
>>> I'm having trouble implementing the WS-MakeConnection MakeConnection
>>> operation, and I'm hoping somebody can give me some pointers. The problem
>>> is
>>> that even though this looks like a SOAP operation, it really is not - the
>>> response can be anything that's waiting for the endpoint, with no
>>> predefined
>>> element or schema type. If I configure this using
>>> Service/ServiceInfo/OperationInfo/etc., as we do for other WS-* protocol
>>> endpoints, it looks like I have to make it a oneway operation (since the
>>> response can be anything) - but if I then set a response message, it'll
>>> be
>>> ignored.
>>>
>>> What I want to do is to pop a message off an internal queue for the
>>> address
>>> and make that the response. Any pointers on how I can make this happen?
>>>
>>> Thanks,
>>>
>>> - Dennis
>>>
>>>
>
Re: WS-MakeConnection operation structuring
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Aki,
Yes, the response should be something the client is expecting - but the
problem is that that response is not part of the MakeConnect operation
definition.
Like WS-RM and many other WS-* technologies, WS-MakeConnection defines a
service that resides at the same endpoint address as a user service. In
the WS-RM code, this situation is handled by defining the added service
using the same constructs as a normal CXF service - a ServiceInfo, an
InterfaceInfo linked to the ServiceInfo, an OperationInfo for each
operation, and MessageInfo and MessagePartInfo for each message. But for
WS-MakeConnection I don't think I can use this construct because there's
no set definition for the response message - even the response element
name is different, since it's just whatever message needs to be
returned. If I try creating a definition without setting a response, it
gets handled as a one-way operation and the response message I set in
the MakeConnection request processing is ignored.
But I suspect that just substituting the message I've previously queued
up for the response is not even the correct approach, anyway. I need to
instead somehow take over the back channel from the request and use that
for sending the saved message, implementing all the processing that
should be done as per the message's interceptor chain (including
security processing). I've been trying to figure out how to do that, but
I'm pretty much lost.
Dan, can you offer any suggestions on this?
Thanks,
- Dennis
On 11/17/2011 12:34 PM, Aki Yoshida wrote:
> Hi Dennis,
>
> The response to the MakeConnection request may be arbitrary, but the
> client that wants to initiate a particular MakeConnection request
> might know what response to expect?
>
> I haven't thought about it and maybe I am missing the details.
>
> Regards, aki
>
> 2011/11/16 Dennis Sosnoski<dm...@sosnoski.com>:
>> I'm having trouble implementing the WS-MakeConnection MakeConnection
>> operation, and I'm hoping somebody can give me some pointers. The problem is
>> that even though this looks like a SOAP operation, it really is not - the
>> response can be anything that's waiting for the endpoint, with no predefined
>> element or schema type. If I configure this using
>> Service/ServiceInfo/OperationInfo/etc., as we do for other WS-* protocol
>> endpoints, it looks like I have to make it a oneway operation (since the
>> response can be anything) - but if I then set a response message, it'll be
>> ignored.
>>
>> What I want to do is to pop a message off an internal queue for the address
>> and make that the response. Any pointers on how I can make this happen?
>>
>> Thanks,
>>
>> - Dennis
>>
>>
Re: WS-MakeConnection operation structuring
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Dennis,
The response to the MakeConnection request may be arbitrary, but the
client that wants to initiate a particular MakeConnection request
might know what response to expect?
I haven't thought about it and maybe I am missing the details.
Regards, aki
2011/11/16 Dennis Sosnoski <dm...@sosnoski.com>:
> I'm having trouble implementing the WS-MakeConnection MakeConnection
> operation, and I'm hoping somebody can give me some pointers. The problem is
> that even though this looks like a SOAP operation, it really is not - the
> response can be anything that's waiting for the endpoint, with no predefined
> element or schema type. If I configure this using
> Service/ServiceInfo/OperationInfo/etc., as we do for other WS-* protocol
> endpoints, it looks like I have to make it a oneway operation (since the
> response can be anything) - but if I then set a response message, it'll be
> ignored.
>
> What I want to do is to pop a message off an internal queue for the address
> and make that the response. Any pointers on how I can make this happen?
>
> Thanks,
>
> - Dennis
>
>