cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulhas Bhole <ulhas.bh...@progress.com>
Subject Re: Writing my own transport
Date Fri, 24 Apr 2009 10:56:43 GMT
Hi Bharat,
Looks like you are trying to use client side to act as server so what 
you need is creating a Destination (similar to what you have done at 
server side for the response)

-- Ulhas

Bharath Gargesh wrote:
> Hi Dan,
> I wanted to write my own transport, but then I saw your reply to this thread
> and found out a way to do this.
> But only that I was able to go half way through.
> On the Server side I did the following:
> 1.) Develop a JAX-WS and publish it to a local address.
> 2.) Got a handle to the LocalConduit through the Default Bus
> 3.) Registered a Listener to the Conduit.
> 4.) Prepare a SOAP Message for calling the JAX-WS, publish it
>      to the Conduit.close() and the reply SOAP Message from the JAX-WS
>      was got in the Listener.
>
> This is absolutely fine, the only thing that I need to do is, construct a
> SOAP Message to invoke the JAX-WS. 
> But I want to use the JAX-WS Client generated to be able to publish the
> message to the Local transport. 
> How can I force/use the JAX-WS client to put the message into the Local
> transport ?
>
> Can you please give me an Idea on how to do this for the JAX-WS client too.
>
> Regards
> Bharath
>
>
> dkulp wrote:
>   
>> Marcel,
>>
>> You can actually use the Local transport for this as well.   We have  
>> several tests that do this exact thing.
>>
>> We have a TestUtilities class:
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/test/TestUtilities.java
>> Look in the "invokeBytes" message which could show you how to invoke a  
>> "local" service using raw data.   The invokeBytes takes a string  
>> message in and returns a byte[], but it would be very easy to replace  
>> that with streams or a DOM or something similar.
>>
>> Dan
>>
>>
>>
>> On May 26, 2008, at 8:09 AM, Heemskerk, Marcel (M.) wrote:
>>
>>     
>>> Hello Dan and CXF,
>>>
>>> I've been looking in the documentation and still it's quite fuzy for  
>>> me.
>>>
>>> What i need is the following:
>>>
>>> We work WSDL first, so i have to stick to a certain XML format. From
>>> this i generate an HTTP service implementation. It contains (for
>>> example) the following pojo:
>>>
>>> ------------------------------------------------------------------------
>>> --------
>>> package com.sample;
>>> import javax.jws.WebService;
>>>
>>> @WebService(endpointInterface = "com.sample.WSInterface",
>>> targetNamespace = "http://com.sample/Calculator")
>>> public class Calculator {
>>> 	public CalculatorResult calculate(CalculatorQuestion q) {
>>> 		return new CalculatorResult(q);
>>> 	}
>>> }
>>> ------------------------------------------------------------------------
>>> --------
>>>
>>> This is deployed as web service:
>>>
>>> ------------------------------------------------------------------------
>>> --------
>>> <bean id="calculatorBean" class="com.sample.Calculator"/>
>>>
>>> <jaxws:endpoint
>>> 	  id="calculatorService"
>>> 	  implementor="#calculatorBean"
>>> 	  address="/"
>>> 	  wsdlLocation="/WEB-INF/wsdl/calculator.wsdl"
>>> 	  serviceName="tns:calc"
>>> 	  xmlns:tns="http://com.sample/Calculator"/>
>>> ------------------------------------------------------------------------
>>> --------
>>>
>>>
>>> What i want to do, is call the service through the JVM (thus NOT  
>>> through
>>> HTTP), with plain SOAP XML as input and plain XML as output, including
>>> custom SOAP Headers, WS-Security headers, and what not.
>>>
>>> If i use local transport i am stuck with the "Java interface" with
>>> CalculatorQuestion  and CalculatorResult.
>>>
>>> Which are the absolute minimum classes i need to implement?
>>>
>>>
>>> Thanks a lot for your info!
>>>
>>> - Marcel
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Oorspronkelijk bericht-----
>>> Van: Daniel Kulp [mailto:dkulp@apache.org]
>>> Verzonden: woensdag 7 mei 2008 6:09
>>> Aan: dev@cxf.apache.org
>>> Onderwerp: Re: Writing my own transport
>>>
>>>
>>>
>>> Depending on what you need to do, you may not need all of the below
>>> classes.
>>>
>>> For example, the CachedXXXputStream stuff may not be necessary
>>> depending on your protocol and current stream implementations.
>>> Actually, in most cases, you DON'T want to use that.   Instead, use a
>>> subclass of the AbstractWrappedOutputStream or your own stuff.
>>>
>>> The TransportFactory is technically not required either.   It depends
>>> on what you need to do.
>>>
>>> If you only need to write a client to talk to an existing service, you
>>> need a Conduit and a ConduitInitiator.
>>>
>>> Likewise, if you need to write a server only, you just need a
>>> Destination and DestinationFactory.   The TransportFactory is
>>> basically a convienience if you need both as it can be the
>>> ConduitInitiator and the DestinationFactory in on.
>>>
>>>
>>> Most of the "Logic" occurs in the Conduit/Destination objects.
>>> Generally, the Conduit.prepare adds an OutputStream to the method that
>>> does a couple things:
>>>
>>> 1) On the first write, it will do whatever header processing stuff is
>>> needed.  For HTTP, it sets the HTTP headers.
>>>
>>> 2) On the close, it can do one of:
>>>     a) wait for the response and call the listener directly.  The
>>> http conduit does this.  It's generally the faster way to do it in
>>> most cases.
>>>     b) Just send the message if there is some other asyncronous way
>>> that the response will come in and have the message listener called.
>>> The local transport does this.
>>>
>>> The AbstractWrappedOutputStream makes some of the above easier by
>>> providing callbacks for those events, but it can be any stream.
>>>
>>>
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>> On May 6, 2008, at 9:24 PM, Freeman Fang wrote:
>>>
>>>       
>>>> Hi Marcel,
>>>> Assume the transport you want to implement is AAA, basically you
>>>> need several class as below
>>>>
>>>> AAAConduit extends AbstractConduit,  kinda like  your transport  
>>>> client
>>>>         
>>>> AAADestination extends AbstractDestination,  your transport
>>>> destination
>>>> AAAConduitOutputStream extends CachedOutputStream, send out client
>>>> request, you should use your transport api to send out request in
>>>> this class
>>>> AAADestinationOutputStream extends CachedOutputStream, send out
>>>> server response, you should use your transport api to send out
>>>> response in this class
>>>> AAATransportFactory, factory to get Conduit and Destination, also
>>>> you need a transport_id to distinguash your transport
>>>>
>>>> You can take a look at org.apache.cxf.transport.jbi which should be
>>>> like your scenario
>>>>
>>>> Freeman
>>>>
>>>> Marcel Heemskerk wrote:
>>>>         
>>>>> I have a service 'service1'  listening to HTTP. I would like be
>>>>> able to make
>>>>> a new transport for this service, so i can use a propietary  
>>>>> transport
>>>>> protocol to receive the InputStream and send the OutputStream to.  
>>>>> The
>>>>> received message is SOAP, so i just want to send it into the CXF
>>>>> marshalling
>>>>> layer to have deserialized to a SOAP header with
>>>>> javax.xml.ws.Holder and
>>>>> SOAP response, etc...
>>>>>
>>>>> It should be simple, because i want to re-use the existing  
>>>>> 'service1'
>>>>>           
>>>>> binding, JAXB, etc. However, it does not seem obvious. I've been
>>>>> trying to
>>>>> reverse engineer the JMS transport or HTTP transport but no luck so
>>>>> far.
>>>>> Could someone point out to me the relevant files or a tutorial on
>>>>> this
>>>>> matter?
>>>>>
>>>>> Thanks,
>>>>> Marcel
>>>>>
>>>>>
>>>>>           
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://www.dankulp.com/blog
>>>
>>>
>>>
>>>       
>> ---
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>>
>>
>>
>>
>>     
>
>   


Mime
View raw message