ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | celtix List | June 2006 Index

<--  Date Index  --> <--  Thread Index  -->

RE: [celtix] Can transport see the operation ?


Title: Can transport see the operation ?

Hello Richard,

"I believe that the FTP transport in Artix works in similar way to what you are suggesting.". You are correct in that Artix FTP transport's default naming implementation uses unique filenames for requests and reply files. However, you can easily override this behavior by implementing naming interfaces yourself and telling the runtime what your naming convention is. (more info here)
 
In your case you will have one and only request/reply filename that you need to look for. Keep in mind that in such setup you should only have 1 client and 1 server instance looking for their request/reply files in 1 FTP directory at a time. You should also keep in mind that a large file takes a while to store on FTPD host and should your client start reading this file prematurely you will run into trouble. If  1 client 1 server per directory is a desirable setup then you need not worry about request/reply correlation, as long as your client and server are able to differentiate consequent requests/replies (may be your filenames  do differ by having a time stamp or something similar, you didn't specify).
 
Cheers,
Marat
 
 

-----Original Message-----
From: Shaw, Richard A [mailto:richard.shaw@xxxxxxxxxxxxxxxx]
Sent: Tuesday, June 20, 2006 11:38 AM
To: celtix@xxxxxxxxxxxxx
Subject: RE: [celtix] Can transport see the operation ?

I understand what you are saying bu that is not my use case.
 
I have a legacy system which writes its data into an XML file on an FTP server and updates this file every hour. I want to write a client to get and use this data without it knowing that it accessing a FTP server for the data, I want it to think that it is sending a web service request and being given the data as the reply.
 
So my filenames are fixed and were define some years ago.
 
My other use case for this is to text our client software. We will create a sample response file and place it onto the FTP server and change the WSDL file temporarily to tell it that the response is in a file - one per operation. We can test that our client works. This is useful for testing that we can handle responses that the live server doesn't return very often. It also means we can test the client without effecting the server or having to install a duplicate test server.
 
I believe that the FTP transport in Artix works in similar way to what you are suggesting.
 
Thanks for the comments.

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: richard.shaw@xxxxxxxxxxxxxxxx

www.atkinsglobal.com/its

 


From: Carbery, Des [mailto:des.carbery@xxxxxxxx]
Sent: 20 June 2006 15:03
To: celtix@xxxxxxxxxxxxx
Subject: RE: [celtix] Can transport see the operation ?

Richard -
 
One thing to consider is reviewing the naming scheme you are using for your files on the ftp server. Instead of trying to match your ftp files to the operation name I'd instead recommend that you come up with a different scheme that doesn't require a coupling between the operations and the transport.
 
How about you simply define the folder where they will reside like
<ftpfile:address location="ftp:///myserver/"/>

 
Your client then creates files with random (or rolling) names in that folder for requests and expects the same file returned with a "response" at the end. For example the client will create a file called request1.xml and then wait for a file called request1_response.xml to find the reply. This means that your ftp code doesn't need to know or even understand the content of what it is sending and can therefore work without adding extensions to the binding. This naming scheme can obviously get more advanced if you need to share folders with other endpoints or want to have different areas for request and response but the basic idea is to remove the need to know the operation you are invoking.
 
cheers
    - des
-----Original Message-----
From: Shaw, Richard A [mailto:richard.shaw@xxxxxxxxxxxxxxxx]
Sent: 20 June 2006 14:34
To: celtix@xxxxxxxxxxxxx
Subject: RE: [celtix] Can transport see the operation ?

I can now get the name of the operation but I can't extract the BindingOperation object because I need the name of the InputMessage and OutputMessage to pass into the getBindingOperation() function along with the method name.
 
I can't see where these are - I can get the class names but they don't necessarily match the message names. I was assuming that METHOD_MESSAGE and METHOD_RETURN might have been them but they return null.
 

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: richard.shaw@xxxxxxxxxxxxxxxx

www.atkinsglobal.com/its

 


From: Shaw, Richard A [mailto:richard.shaw@xxxxxxxxxxxxxxxx]
Sent: 20 June 2006 12:37
To: celtix@xxxxxxxxxxxxx
Subject: RE: [celtix] Can transport see the operation ?

Thanks, I was missing the bit that stores the context in my outputMessageContext.
 
I was extending the GenericMessageContext, I've now changed to extend the MessageContextWrapper and I've added super(context) to my constructor.
 
Thanks again.

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: richard.shaw@xxxxxxxxxxxxxxxx

www.atkinsglobal.com/its

 


From: Paibir, Ajay [mailto:ajay.paibir@xxxxxxxx]
Sent: 20 June 2006 12:13
To: celtix@xxxxxxxxxxxxx
Subject: RE: [celtix] Can transport see the operation ?

The operation name can be accessed by using the standard JAX-WS MessageContext.WSDL_OPERATION property. Also as per the spec it is not mandatory to set the property in the context.

However on looking through the Celtix Code the Transport context i.e OutputStreamMessageContext should have the property set.  While creating the transport Context using the ServerTransport.createOutputStreamContext(MessageContext bindingContext) the binding context is passed in.

Basically this binding context will have to be wrapped/copied into the output stream context of the FTP transport.

Regards

Ajay


From: Shaw, Richard A [mailto:richard.shaw@xxxxxxxxxxxxxxxx]
Sent: 20 June 2006 11:29
To: celtix@xxxxxxxxxxxxx
Subject: [celtix] Can transport see the operation ?

In my custom transport which gets the response data from an FTP file (the one I posted a couple of weeks ago). I wanted to add extra support so that each operation could be configured in the WSDL to a different file.

My WSDL looks like this -

    <binding name="TrafficNewsISOAPBinding" type="tns:TrafficNewsI">
        <xformat:binding/>
        <operation name="GetTrafficNews">
            <soap:operation soapAction="" style="document"/>
            <input name="GetTrafficNews">
                <soap:body use="literal"/>
            </input>
            <output name="GetTrafficNewsResponse">
                <soap:body use="literal"/>
            </output>
        </operation>
    </binding>
   
    <service name="TrafficNewsService">
        <port binding="tns:TrafficNewsISOAPBinding" name="SOAPOverHTTP">
                <ftpfile:address location="ftp:///myserver/TrafficNews.XML"/>
        </port>
    </service>

So when I make a GetTrafficNews request the reply is the contents of the TrafficNews.xml file on my FTP server.

This is fine when my WSDL defines a single operation, but if there is more than one operation I want to define the following WSDL -

    <binding name="TrafficNewsISOAPBinding" type="tns:TrafficNewsI">
        <xformat:binding/>
        <operation name="GetTrafficNews">
            <soap:operation soapAction="" style="document"/>
                <ftpfile:address location="ftp:///myserver/TrafficNews.XML"/>
            <input name="GetTrafficNews">
                <soap:body use="literal"/>
            </input>
            <output name="GetTrafficNewsResponse">
                <soap:body use="literal"/>
            </output>
        </operation>
        <operation name="GetTrafficSpeeds">
            <soap:operation soapAction="" style="document"/>
                <ftpfile:address location="ftp:///myserver/TrafficSpeeds.XML"/>
            <input name="GetTrafficSpeeds">
                <soap:body use="literal"/>
            </input>
            <output name="GetTrafficSpeedsResponse">
                <soap:body use="literal"/>
            </output>
        </operation>
    </binding>
   
    <service name="TrafficNewsService">
        <port binding="tns:TrafficNewsISOAPBinding" name="SOAPOverHTTP">
                <ftpfile:address location="ftp:///myserver/TrafficNews.XML"/>
        </port>
    </service>

So now if the operation has a file defined it gets the response from there, otherwise it uses the file defined in the port. GetTrafficNews reads from TrafficNews.xml and GetTrafficSpeeds reads from TrafficSpeeds.xml

My question is (finally) how can my transport work out what the operation is so that it can get the correct filename ? I want this to work with any binding (I've tested pure XML and SOAP), looking at the source code of Celtix it seems that transport doesn't have access to the binding context so it can't use it to query what the operation was.

I did wonder if I should have used a handler instead because it has access to the LogicalMessageContext and can work out what the operation is and then get the response from the FTP server, but this isn't quite as neat, and is harder to configure for use.

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: richard.shaw@xxxxxxxxxxxxxxxx

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.



This message has been scanned for viruses by MailControl



<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.