cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: WS-MakeConnection operation structuring
Date Fri, 18 Nov 2011 21:55:17 GMT
On Thursday, November 17, 2011 2:37:13 AM Aki Yoshida wrote:
> 2011/11/17 Dennis Sosnoski <dms@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<dms@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

Mime
View raw message