> -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 2007?6?6? 5:40 > To: [email protected] > Subject: Re: Skipping some layers in the interceptor chain > > > Ugh please no :-D > > I'd recommend taking a look at the JAX-WS provider/dispatch > mechanisms. You > can send a Source object via the Dispatch (and it will wrap > it with a SOAP > body if necessary or handle whatever binding stuff needs to > happen). On the > server side you can then receive the XML via a Provider. Once > again you'll > get a Source object which should be easy enough to work with. > > I believe there are some ok samples here: > > http://java.sun.com/mailers/techtips/enterprise/2006/TechTips_ > July06.html > > - Dan > > On 6/5/07, Dan Connelly <[EMAIL PROTECTED]> wrote: > > > > The most straight-forward (but moderately inefficient) way > to process > > XML messages within SOAP is to have a service method that merely > > exchanges Request-Response XMLs (Strings byte[ ]s),. like so in the > > service Interface: > > > > public interface String getResponse(String myRequestAsXml) ; > > > > Implement the service in XSL transforms. > > > > For real-life XML "eFile" messaging service see : > > http://www.streamlinedsalestax.org/EFileService-1.0.1.wsdl > > > > > > > > Shaw, Richard A wrote: > > > I'm not sure if we are talking at cross purposes here. So > I'll give an > > example - > > > > > > My logical message is - > > > > > > <AddNumbers> > > > <First>10</First> > > > <Second>20</Second> > > > </AddNumbers> > > > > > > I want to call a Dispatch and pass in the XML as above. > > > > > > If I set the binding in my wsdl file to be pure XML, I > expect to see the > > XML above passed over the transport. > > > > > > If I changed the binding to SOAP, I would expect it to look like - > > > > > > <SOAP-ENV:Envelope> > > > <SOAP-ENV:Body> > > > <AddNumbers> > > > <First>10</First> > > > <Second>20</Second> > > > </AddNumbers> > > > </SOAP-ENV:Body> > > > </SOAP-ENV:Envelope> > > > > > > If I changed the binding to be Corba it would be in a binary coded > > format > > > > > > (not shown) > > >
Yes, this should work. What happens behind the scene is that the interceptors in the chain are not harded or fixed, instead interceptors are contributed by bus, endpoint and bindings during the construction time. If you take a look at SoapBindingFactory.java and XMLBindingFactory.java, you will see how different interceptors are added into the chain for different bindings. So just a minor modification to the graph you have drawn below: B,C and F,G might not always be the case, it depends on what interceptors you have in the chain. Take the Dispatch case as an example, because DispatchImpl.java didn't add all these binding interceptors into its outchain (see DispatchImpl.getDispatchOutChain()), there is no JAXB convention involved at all. > > > My understanding of the interceptor chain is as follows > (and maybe I > > have this wrong, which is where my mis-understanding lies) - > > > > > > Client side > > > =========== > > > A - I call a function of my port using java objects > > > B - It gets converted into XML (JAXB) > > > C - XML goes through binding layer to format the message > > > D - The transport sends the formatted message > > > > > > Server Side > > > =========== > > > E - Transport receives the message > > > F - binding layer decodes message into XML logical message > > > G - XML is converted into java objects (JAXB) > > > H - I have my message as a java object > > > > > > I want this process to start at C and end after F so that I pass a > > logical XML message and receive my reply as a logical XML > message even > > though the binding/transport may not have used XML for the > communication. > > I'm doing this at the moment by adding my own JAXB calls > before A and after > > H. > > > > > > Richard Shaw > > > > > > ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`° > º¤ø,¸¸,ø¤ > > > > > > Richard Shaw > > > Technical Design Authority - Information Solutions Consultancy > > > Intelligent Transport Systems > > > > > > Atkins Highways and Transportation > > > Woodcote Grove, Ashley Road, Epsom, Surrey, KT18 5BW > > > > > > Tel: +44 (0) 1372 756407 > > > Fax: +44 (0) 1372 740055 > > > Mob: 07740 817586 > > > E-mail: [EMAIL PROTECTED] > > > > > > www.atkinsglobal.com/its > > > > > > -----Original Message----- > > > From: Freeman Fang [mailto:[EMAIL PROTECTED] > > > Sent: 05 June 2007 11:23 > > > To: [email protected] > > > Subject: Re: Skipping some layers in the interceptor chain > > > > > > Hi Richard, > > > Comment inline > > > Shaw, Richard A wrote: > > > > > >> If I use the dispatch interface does CXF still pass it > through the > > binding and transport layers ? > > >> > > >> > > > It only skip mashall/unmashall for binding layer, but can > not skip the > > transport layer, anyway, you need deliver message to remote process > > > > > >> The XML in the sample is a soap message which would > suggest to me that > > it isn't using the binding because that would normally > convert the XML into > > SOAP. > > >> > > >> My use case requires me to talk to various legacy > services using more > > than SOAP. > > >> > > >> > > >> > > > SOAP payload is not compulsory here, you can use any > payload you like. > > > > > > Thanks very much > > > > > > Freeman > > > > > > > > > > > >> Richard Shaw > > >> > > >> ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`° > º¤ø,¸¸,ø¤ > > >> > > >> Richard Shaw > > >> Technical Design Authority - Information Solutions Consultancy > > >> Intelligent Transport Systems > > >> > > >> Atkins Highways and Transportation > > >> Woodcote Grove, Ashley Road, Epsom, Surrey, KT18 5BW > > >> > > >> Tel: +44 (0) 1372 756407 > > >> Fax: +44 (0) 1372 740055 > > >> Mob: 07740 817586 > > >> E-mail: [EMAIL PROTECTED] > > >> > > >> www.atkinsglobal.com/its > > >> > > >> -----Original Message----- > > >> From: Liu, Jervis [mailto:[EMAIL PROTECTED] > > >> Sent: 04 June 2007 03:20 > > >> To: [email protected] > > >> Subject: RE: Skipping some layers in the interceptor chain > > >> > > >> Hi Richard, > > >> > > >> Can't you use Dispatch interface? Sth like below shall > allow you to > > >> skip unnecessary JAXB marshalling ( code snippet from CXF > > >> dispatch_provider sample) > > >> > > >> QName serviceName3 = new QName(" > > http://apache.org/hello_world_soap_http";, "SOAPService3"); > > >> QName portName3 = new > > >> QName("http://apache.org/hello_world_soap_http";, "SoapPort3"); > > >> > > >> SOAPService3 service3 = new SOAPService3(wsdlURL, > > serviceName3); > > >> DOMSource domReqPayload = new > DOMSource(..................); > > >> Dispatch<DOMSource> dispDOMSrcPayload = > service3.createDispatch > > (portName3, > > >> > > >> DOMSource.class, Mode.PAYLOAD); > > >> > > >> DOMSource domRespPayload = dispDOMSrcPayload.invoke > > (domReqPayload); > > >> > > >> > > >> Cheers, > > >> Jervis > > >> > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: Shaw, Richard A [mailto:[EMAIL PROTECTED] > > >>> Sent: 2007?6?1? 23:33 > > >>> To: [email protected] > > >>> Subject: Skipping some layers in the interceptor chain > > >>> > > >>> > > >>> I have the following requirement and was wondering > whether anybody > > >>> could tell me if it is possible - > > >>> > > >>> 1 - I have an XML string which represents the logical > message for a > > >>> request > > >>> 2 - I want to use this to make a request on an > appropriate service > > >>> 3 - I want to catch the reply at the XML level without > creating a > > >>> java object > > >>> 4 - transform the reply using a XSL stylesheet to be the logical > > >>> message of another service > > >>> 5 - send the logical message to the final service > > >>> > > >>> This is for a generic data fetch. It requests data from a SOA > > >>> component, transforms the data into a set message, > which is sent to > > >>> my datastore component. I don't want to write a new > component for > > >>> every type of data source that I want to fetch data from. > > >>> > > >>> I have implemented the above using the original Celtix > code, but it > > >>> has the following inefficiencies - > > >>> > > >>> 1 - I load the XML from my config. unmarshal it into an > object and > > >>> then use that to call my service which will marshal as > its first step > > >>> 3 - the response is unmarshalled into a java object so > I then marshal > > >>> it back to an XML stream to pass to the XSLT transformer > > >>> 5 - I unmarshal the transformed XML into a java object > and use that > > >>> to call my data storage service > > >>> > > >>> Thanks > > >>> > > >>> Richard Shaw > > >>> > > >>> ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º° > `°º¤ > > >>> ø,¸¸,ø¤ > > >>> > > >>> Richard Shaw > > >>> Technical Design Authority - Information Solutions Consultancy > > >>> Intelligent Transport Systems > > >>> > > >>> Atkins Highways and Transportation > > >>> Woodcote Grove, Ashley Road, Epsom, Surrey, KT18 5BW > > >>> > > >>> Tel: +44 (0) 1372 756407 > > >>> Fax: +44 (0) 1372 740055 > > >>> Mob: 07740 817586 > > >>> E-mail: [EMAIL PROTECTED] > > >>> > > >>> www.atkinsglobal.com/its > > >>> > > >>> > > >>> > > >>> This email and any attached files are confidential and copyright > > >>> protected. If you are not the addressee, any > dissemination of this > > >>> communication is strictly prohibited. > > >>> Unless otherwise expressly agreed in writing, nothing > stated in this > > >>> communication shall be legally binding. > > >>> > > >>> The ultimate parent company of the Atkins Group is WS > Atkins plc. > > >>> Registered in England No. 1885586. Registered Office > Woodcote Grove, > > >>> Ashley Road, Epsom, Surrey KT18 5BW. > > >>> > > >>> Consider the environment. Please don't print this > e-mail unless you > > >>> really need to. > > >>> > > >>> > > >>> > > >> This message has been scanned for viruses by MailControl - (see > > >> http://bluepages.wsatkins.co.uk/?6875772) > > >> > > >> > > >> > > > > > > > > > > > > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog > ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
