cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Writing my own transport
Date Wed, 28 May 2008 13:53:11 GMT

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