[xgws-user] XSUL question

Shanmuga.MUHUNTHAN@fr.thalesgroup.com Shanmuga.MUHUNTHAN_at_fr.thalesgroup.com
Wed, 11 Jan 2006 16:57:24 +0100


Hi and thanks for reply,

I finally reached the goal I wanted to but I wonder whether there are an other "sexy" way to do what I'm doing. the following is a simplified listing of my application. This application is based on echo_async.wsdl (the same as xsul/test/echo_async).

1. creating the WsdlDefinitions and changing the SOAP ADDRESS of the WSDL file:
        WsdlDefinitions def = WsdlResolver.getInstance().loadWsdl(base, new URI(./misc/echo_async.wsdl)); 
        for(Iterator eS = def.getServices().iterator(); eS.hasNext(); ) {
        	WsdlService oneService = (WsdlService) eS.next();
        	for (Iterator eP = oneService.getPorts().iterator(); eP.hasNext(); ) {
        		WsdlUtil.replaceWsdlSoapAddr((WsdlPort)eP.next(), "http://192.168.0.10:32997/echoAsync");
        	}
        }

2. creating WSIFClient (with timeout and correlator) for WSDL abstraction:
        WSIFProviderManager.getInstance().addProvider(new xsul.wsif_xsul_soap_http.Provider());
        WSIFClient wclient = WSIFRuntime.getDefault().newClientFor(def, null);
	  XMLwclient.useAsyncMessaging(correlator);
        XMLwclient.setAsyncResponseTimeoutInMs(33000L);

3. creating port, operation and input/output/fault message:
 		WSIFPort wsifPort = wclient.getPort();
            operation = wsifPort.createOperation("echoString");
		inputMessage = operation.createInputMessage();
            outputMessage = operation.createOutputMessage();
            faultMessage = operation.createFaultMessage();
		inputMessage.setObjectPart("param0", "hello");

4. sending asynchronous message
		boolean success = operation.executeRequestResponseOperation(
                    inputMessage, outputMessage, faultMessage)

This enables me to do what I want to do: to load a local wsdl file, the client doesn't ask for wsdl to the server, to modify the SOAP ADDRESS by using WsdlUtil.replaceWsdlSoapAddr(...) into the source code, to use asynchronous messaging with ws-addressing. Are there an other better way to do that ?

I have also several questions:
1. What is the difference between XmlBeansWSIFRuntime and WSIFRuntime ?
2. Giving the listing below, how can I instantiate somewhere an handle on wsaInvoker because I want to modify header fields (replyTo) ? replyTo Field is not right but the response is send back correctly is it normal ?
3. The main advantage of WSIF* is dynamic aspect but in my listing below, I reduce the interest of WSIF since I modify SOAP ADDRESS into the source code and the WSDL is not asked to the server. In that case, what is the advantage to use WSIF and is it justifiable ? => WSDL abstraction ?

best regards
Shan

-----Message d'origine-----
De : Aleksander Slominski [mailto:aslom_at_cs.indiana.edu]
Envoyé : mardi 10 janvier 2006 19:03
À : Shanmuga.MUHUNTHAN_at_fr.thalesgroup.com
Cc : xgws-user_at_cs.indiana.edu
Objet : Re: [xgws-user] XSUL question


Shanmuga.MUHUNTHAN_at_fr.thalesgroup.com wrote:

>I studied the example async_msg and echo_async and I have few questions:
>
>1. What is the difference between WsaInvoker and WSIFClient ? both enables me to send message but I don't know how to choose one. 
>
WsaInvoker sends message to WS-Adressing (WSA) endpoint and it is lower 
level than WSIFClient that is an API to access Web Services using WSIF 
constructs (WSIFMessages etc.) - internally WSIF uses providers and 
SOAP/HTTP uses specialized Invoker (SoapHttpDynamicInfosetInvoker in 
XsulSoapOperation) - you can write as many providers as you want and 
plug them into WSIF (one of them could use WsaInvoker if that level of 
WSA abstraction was needed - WSA does not require HTTP as transport)

in general WSIF* is higher level API that uses WSDL abstraction (that is 
main distinction!), supports handlers, provides stubs, does data binding 
(such as XmlBeans) etc. and *Invoker stuff is lower level that works 
directly with XML (though it the distinction is nto that clear cut - 
there are different Invokers with different capabilities)

>(WSIF package is for dynamic but dynamic what ?)
>  
>
dynamic in sense you can send XML (of any form) to any service 
determined during runtime - when using WSIF dynamic part is also that 
you can talk to any service that is described in WSDL (if you do not use 
stubs as for stubs you need to generate Java interface before dynamic 
stub is created).

>2. When I use WSIFClient, the first thing the client does (when WSIFClient is instantiated) is to send a request of WSDL to server (GET /async_msg?wsdl HTTP/1.1). Is it possible to bypass this ? 
>
it is possible if you have locally WSDL just pass it file:/ or even 
construct in-memory WSDL and pass it to WSIFClient - try:
    WsdlDefinitions def = ... // your WSDL - read from file or build it 
from memory
    (XmlBeansWSIFRuntime|WSIFRuntime).getDefault().newClientFor(def, null);

>All server are not supposed to understand this request (??). Futhermore, this request is synchronous and it can not work with pure asynchronous server.
>  
>
it is not required - what is required is passing some from of WSDL from 
/somewhere/ to initialize WSIFClient - this is consistent with goals of  
WSIF that is built around enabling access to *any* WSDL described 
services (WSDL abstraction _is_ required)

>3. Is it possible to use the xmlbeans generated by xwsdlc (in the decoder sample, this is the contain of generated\xmlbeans_typesrc\decoder) in order to send and receive message ? that is to say, serializing the xmlbeans, creating input/output message using WSIFMessageElement() and sending it through WSIFClient? are there an other way to use the xmlbeans generated ?
>  
>
yes you can send them but you need to convert to (internal) XML 
representation just before sending and similarly fot receiving (that is 
what XSUL does behin the scene when it recevies message and sees that 
service needs XmlObject it converts XML into Xmlbeans XmlObject).

best,

alek

>
>-----Message d'origine-----
>De : Aleksander Slominski [mailto:aslom_at_cs.indiana.edu]
>Envoyé : lundi 9 janvier 2006 18:29
>À : Shanmuga.MUHUNTHAN_at_fr.thalesgroup.com
>Cc : xgws-user_at_cs.indiana.edu
>Objet : Re: [xgws-user] XSUL question
>
>
>Shanmuga.MUHUNTHAN_at_fr.thalesgroup.com wrote:
>
>  
>
>>hello everybody,
>> 
>>
>>    
>>
>hi!
>
>  
>
>>I would like to use a SOAP package on a project with four requirements:
>>1. The used SOAP package has to be very light (few MegaBytes).
>>2. The SOAP messages have to be encoded in Document/Literal
>>3. The API part implementation has to be asynchronous with ws-addressing implemented in the soap package (not in the developped API part). 
>>4. All the soap requests and response have to be send through the same socket (not only the request and corresponding response but also all the requests and all the responses).
>>5. WSDL to JAVA support. The package has to be able to generate java code from WSDL and implemente the generated file into an asynchronous communication.
>>
>>A magnificent summer day, I found a great package called XSUL. I was very impressed by all the features of XSUL and I tried to answer to all the required requirement :
>>1. XSUL package is very light (compared to AXIS/AXIS2) and this package can be modified in order to fit the user needs.
>>2. XSUL support DOC/LIT
>>3. XSUL support ws-addressing (better than gSOAP)
>>The following two questions are more delicate:
>>4. With XSUL it is possible to use the same socket for all request/response but it implies xsul source code modification. (in particular the modules puretls_client_socket_factory and puretls_server_socket_factory) (true unlike AXIS)
>> 
>>
>>    
>>
>XSUL by default delegates socket creation to a factory - i think for 
>puretls (check puretls_client_socket_factory module) it is using 
>HttpClientReuseLastConnectionManager which reuses the same socket if 
>invocations are within REUSE_TIME_WINDOWS_IN_MS (3 minutes by default - 
>this could be mad in future configurable)
>
>  
>
>>5. XSUL support WSDL to JAVA. But implementing asynchronous application from generated PortType seems to be difficult since no sample are provided.
>> 
>>
>>    
>>
>on service side there is no difference for your application code 
>regardless if web service sends responses synchronoulsy (over the same 
>HTTP connection) or async (using seaprate outbound HTTP conenctions or 
>storing response message for later pick up in a message box service): 
>XSUL when hosting application will determine how to send response 
>message based on WS-Addressing headers used: if ReplyTo/FaulTo is not 
>anonymous it will automatically send response async.
>
>the example code is tests/async_msg and in particular see 
>EchoPeer/EchoPeerImpl (you can ignore StickySoapHeaderHandler as it is 
>only used to test accessing/modifying SOAP headers from inside service).
>
>client side requires a bit more work as you need to tell XSUL where do 
>you want response to go - by default it is using sync. HTTP but calling 
>WSIFClient.useAsyncMessaging() can be used to determine where and how 
>inbound response messages should be received and correlated back to 
>outbound request messages on client side- see 
>tests/async_msg/EchoAsyncClient (to run self test try java -Dlog=trace 
>-Dstart_server  xsul.async_msg.EchoAsyncClient -no_stub -count 2 
>-client_port 0)
>
>  
>
>>Am I right ?
>>
>>Has somebody already experimented the implementation of asynchronous application from generated code ?
>>
>> 
>>
>>    
>>
>i am not sure if i get what exactly you plan? do you have more details? 
>server side sould work just fine and client side should also work fine 
>(not overly tested though)
>
>best,
>
>alek
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay