cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bharath Gargesh <bharath.garg...@hp.com>
Subject Re: Writing my own transport
Date Fri, 24 Apr 2009 10:29:07 GMT

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
> 
> 
> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Writing-my-own-transport-tp17088528p23213779.html
Sent from the cxf-dev mailing list archive at Nabble.com.


Mime
View raw message