Return-Path: X-Original-To: apmail-cxf-dev-archive@www.apache.org Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 623AD7556 for ; Thu, 17 Nov 2011 10:13:33 +0000 (UTC) Received: (qmail 42693 invoked by uid 500); 17 Nov 2011 10:13:32 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 42334 invoked by uid 500); 17 Nov 2011 10:13:30 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 42320 invoked by uid 99); 17 Nov 2011 10:13:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2011 10:13:28 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [74.50.49.35] (HELO sosnoski.com) (74.50.49.35) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2011 10:13:20 +0000 Received: from [192.168.0.65] (ip-58-28-158-218.static-xdsl.xnet.co.nz [58.28.158.218]) (authenticated bits=0) by sosnoski.com (8.12.10/8.12.10) with ESMTP id pAHACts2004394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2011 05:12:57 -0500 Message-ID: <4EC4DE26.1040402@sosnoski.com> Date: Thu, 17 Nov 2011 23:12:54 +1300 From: Dennis Sosnoski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: dev@cxf.apache.org CC: Aki Yoshida , Daniel Kulp Subject: Re: WS-MakeConnection operation structuring References: <4EC37291.9050106@sosnoski.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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: >> 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 >> >>