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
