Hi Dan and Ulhas,

Thanks to you two, now I can publish messages to Local Transport and
intercept them.

Now I am able to intercept the messages in the MessageObservers of the
LocalDestination and the LocalConduit.

I work on a platform which provides Java API for IPC. The API allows
transfer of bytes from one process to another.
My plan is as follows:

1.) Publish a JAX-WS endpoint on a local Transport, Get the LocalConduit and
register a MessageObserver in it. Wait for IPC messages here, when any
message is got, convert this to SOAP message and send it to the Local JAX-WS
Endpoint Impl, get the response and Reply back.

2.) Now the Client (JAX-WS Client). Get the LocalDestination (register a
dummy local Endpoint here) and register the MessageObserver. Intercept the
messages from the Client here and post the messages to the Step 1.) through
IPC. I can get the response from the JAX-WS Service.

But now I am stuck here. How do I reply the response to the caller/JAX-WS
Client.

Where should I look into (Interceptors and Phases ?). Kindly provide a brief
outline of how do I acheive the above. Or simply put, How can I propagate
the message from LocalDestination's MessageObserver back to the caller ?

Kindly reply.

Regards
Bharath

dkulp wrote:
> 
> 
> Bharath,
> 
> It's relatively simple.....
> 
> Service service = new Service(seviceName);
> service.addPort(portName, 
>           "http://schemas.xmlsoap.org/soap/";, 
>           "local://localhost:9090/hello"); 
> HelloInterface proxy = service.getPort(portName, HelloInterface.class);
> 
> Basically, use the same URL as you did for the server side publish.
> 
> 
> Dan
> 
> 
> 
> On Fri April 24 2009 6:29:07 am 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/apach
>> >e/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:dk...@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
>> >> dk...@apache.org
>> >> http://www.dankulp.com/blog
>> >
>> > ---
>> > Daniel Kulp
>> > dk...@apache.org
>> > http://www.dankulp.com/blog
> 
> -- 
> Daniel Kulp
> dk...@apache.org
> http://www.dankulp.com/blog
> 
> 

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

Reply via email to