Hi Josef, Thank you very much for your time spend in helping me understand this. The analysis was great! I followed your tip, and tried to use tcpmon on transportsession but I saw that the only session info send to client was the JSESSIONID in the cookie (which is defined in sevlet spec). I.e. The HTTP response was this: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=1CE110EACECC0AE176C6610DA81D0446; Path=/axis2 Content-Type: text/xml;charset=UTF-8 Transfer-Encoding: chunked Date: Thu, 27 Jan 2011 16:49:43 GMT
f3 10 0 So I am not sure how you worked arround this, in the example you mention on the MS WFC Client. You note: >>Sending the request later by MS WCF Client without that cookie did not work. >>I hade to add to the http-header all the same bit's as the axis2 java client >>was >>sending in scope="soapsession". >> But I do not know how you got that info to send it. In the reply in my test, there is only the JSESSIONID send back to the client. And if I make a web service invocation by different instances of web service client, the object is re-instantiated on the server. Thank you!!! ________________________________ From: Stadelmann Josef <[email protected]> To: [email protected] Sent: Thu, January 27, 2011 12:29:50 PM Subject: AW: AW: axis2 session scopes To my understanding, the trick with servicegroupId in the soap address header makes only real sense in scope="soapsession". Given we can have several transports one being http, another being RPC or JSM or whatever, I would want to have a solution selecting my service instance independent from transport protocol used. So I should avoid managing it on the transport level. Managing how to reach the service providing object (instance) for a particular user session thread should go in my mind only to the SOAP/XML stack and avoid any transport level inclusion/cluttering. That is the reason why I selected long lasting objects and have one user session thread ending in a instance of a service-class (an object) which gets is message via web service facilities. (just my view). And it works perfect, without any big overhead. It was that decision which allowed us to see an web service providing object as a holder of a HP-WSIT-JAVABEAN which keeps the IPC channel open (to send data from Java to the C-Wrapper-World) to an OpenVMS legacy process 80'000 LOC's of PASCAL plus Oracle DB. Saying, we have to integrate and speak to legacy server processes on a per user session thread basis. (which is overhead I know, but we do legacy-integration, and many old process is just not multi-threaded, or thread aware). As long as a users client keeps the session/thread open to the service providing object, as long will each message reach the same object identified by the servicegroupId. (think of the servicegroupId as of an "object-identifier" very similar to an IOR in the CORBA world). It's the server which must give you this object reference, and it's the responsibility of the client to re-use/re-ship it with each request to the axis2 engine to reach "the object". What is a transport session? When does the transport session start and when does it end? Now comes my weak bit! I never used scope="transportsession" So I have read this excellent article. http://www.developer.com/open/print.php/3620661 (do me a favor and forget about the space in the scope=" transportsession" as shown in the article, as it may lead to problems (somewhere there is a scope dispatcher in java if scope.compare("soapsession") then …- so he looks at strings very carefully :-)) Given a user client has several transport sessions open, how does it chose about which one to use? Maybe you have 3 stubs? Manage sessions by transport means: Articel: The lifetime of the session is controlled by the transport, not by Axis2; If axis2 has no control over the session then we need to have our service instance identifying bits located somewhere else, maybe on the transport level, maybe inside the http-header, but for sure not a the soap/xml protocol level; So it's very likely that a cookie is used for that service instance, and that the axis2 server has to return the cookie to the client as it creates the service instance, a cookie the client has to re-use again to hit the same service instance. (very much like an IOR in CORAB) That is when you have to start massaging your http header in the client and sniff in a cookie; and you do it at the transport level and not at the soap/xml header. Article: One of the key advantages of the Transport session over other sessions is that you can talk to multiple service groups within one transport session Where is the identifying bit selecting the service group wanted? My learning with scope="soapsession" and long lasting session was: I had to implement a MS WCF Client talking to an Apache Axis2 web service server with long lasting sessions (state full service providing objects)! I had to fake axis2! I had to give the axis2 engine what it needs to think that an axis2 client is talking. By a TCP Monitor or by Wireshark I figured out what axis2 engine expects. Observation, and not expected at all but it was there on the wire: a http cookie was sent by the axis2 client. Sending the request later by MS WCF Client without that cookie did not work. I hade to add to the http-header all the same bit's as the axis2 java client was sending in scope="soapsession". This http-header-massage in addition to the servicegroupId header on the soap/xml level made me build interceptors at the client which intercept each outgoing and incoming request, just to add/retrieve all required information to reuse them during the next send/request. Josef Von:am am [mailto:[email protected]] Gesendet: Mittwoch, 26. Januar 2011 17:50 An: [email protected] Betreff: Re: AW: axis2 session scopes Hi Josef, Thank you very much for the detailed analysis!!! Now it very clear in my mind. This solves the soapsession. I am wondering though, is the servicegroupId required in the transportsession as well? In transport session, session info are send back-and-forth via cookies and so it is transparent to the programmer. The only thing needed is to setManageSession to true in client object. At least this is what I understood from reading articles. But trying it out, a new web service is created each time. So now I am thinking if I need to send the servicegroupId in the transportsession as well. - If yes, then how do I find it? Because the client.getServiceContext().getTargetEPR().getAllReferenceParameters().get(new QName("http://ws.apache.org/namespaces/axis2%22,%22ServiceGroupId";)); used for soapsession throws NPE for transportsession, which I guess makes sense since there is no addressing header in transportsession. But how do I find it, to send it in next request? - If no, what am I doing wrong to observe this behavior? I.e. new instance of web service? I have set session to transportscope and the managesession to true in client. Isn't it enough? Thanks! ________________________________ From:Stadelmann Josef <[email protected]> To: [email protected] Sent: Wed, January 26, 2011 11:44:53 AM Subject: AW: axis2 session scopes We use scope="soapsession" in the following case A: we have 3 different client programs running from the same PC each with the same WS stub. B: Each one of the 3 client shall span one dedicated user session thread to a dedicated web service based object, which is an instance of your web service class. (Think how a client-object finds its server-object via a strong link) cA talks to sA, cB talks to sB, cC talks to sC, but never cA talks to sB or sC. Just a 1 to 1 object relation. B: By using scope="soapsession" the initial call of cA to the web service creates for our service class a web service object sA (as instance) and it returns a servicegroupId Header to the calling client cA. C: The client cA is now required to send his received servicegroupId in the addressing header with each request to the axis2 engine which dispatches the request to sA D: that way we can guarantee you that each users client session thread i.e. cA, reaches always the same service object (instance) sA E: and by adjusting a timeout in the client and the server we have long lasting objects, client and server side, objects talking to each other for hours. And we have no need to re-establish for each request a new stub or a new service providing object. Josef Von:am am [mailto:[email protected]] Gesendet: Montag, 24. Januar 2011 17:47 An: [email protected] Betreff: Re: axis2 session scopes Ah, I see now. So the idea is that either a single instance of a serviceClient is reused across calls or if new instances must be used it must be directed to the specific serviceGroupId. Right? For soapSession scope as mentioned in the article we use the client.getServiceContext().getTargetEPR().getAllReferenceParameters().get(new QName("http://ws.apache.org/namespaces/axis2%22,%22ServiceGroupId";)); for transportSession what is the approach? The above method returns null (since there is no replyto header I guess) but on transport which is based on cookies, I set to client the managesession attribute to true, and still can not re-use session across different service clients objects. What is the approach on transport? Thank you! ________________________________ From:Deepal jayasinghe <[email protected]> To: [email protected] Sent: Sun, January 23, 2011 10:51:51 PM Subject: Re: axis2 session scopes The problem is not sending the servicegroupID or the session related information. When you keep sending request it always create a new instances, only way to stop is to copy the servicegroupID from the previous request and send it alone with the next request. One another way to get this work is try following, then you will see the expected behavior. ServiceClient client = new ServiceClient(); Options options = new Options(); options.setTo(new EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService";)); options.setManageSession(true); client.setOptions(opts); client.invokeBlocking(); client.invokeBlocking(); client.invokeBlocking(); If we do the above, you only get one service instances. Deepal The article describes how to keep session, without needing to reuse the same ServiceClient object. I.e. keep session using different ServiceClient objects. My question was, why is the web service class being re-instantiated for each web service invocation for ALL scopes except application. I have configured client to manage session (and engaged addressing for soapsession) and the web service class keeps-on re-instantiated for each web service call. So, I am not having a problem on keeping/using session (I am using messageContext and serviceContext for session related data). I can not understand why the web service class is re-instantiated. Is this a bug in Axis2? If not, what is the logic for this? I think that for enterprise level application this is too costly. Is some sample code needed for this? Thank you ________________________________ From:Deepal jayasinghe <[email protected]> To: [email protected] Sent: Sun, January 23, 2011 10:25:50 PM Subject: Re: axis2 session scopes Now, I got the point. For that you need to try the following. http://wso2.org/library/3184 Deepal Hi Deepal, I have tried all scopes. In client side I have set manage session to true. For instance. I set the session scope in services.xml to "transportsession". In the web service I use MessageContext messageContext = MessageContext.getCurrentMessageContext(); ServiceContext scontext = messageContext.getServiceContext(); To store values to last per session. e.g. scontext.setProperty("SUM","" + sum); and I re-use sum across invocations. Also in client I do: ServiceClient client = new ServiceClient(); Options options = new Options(); options.setTo(new EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService";)); options.setManageSession(true); client.setOptions(opts); I can see that the data I place in MessageContext persist across invocations but I also see that a new web service instance is created per invocation. So my question is, that the session data will persist but I should expect the web service to be re-instantiated per invocation? In the example of transport session I have in the web service: public class MyLittleWebService{ publicMyLittleWebService(){ System.out.println("MyLittleService constructor called! New Instance created!"); } And the constructor is being called across all invocations for all types of session except application. So I understand I must use session data, but this is the expected behavior as well? Re-instantiate the WS per invocation? Isn't it expensive for enterprise level web services? If I am confused on this, please help me out understand what am I doing wrong here. Thank you ________________________________ From:Deepal Jayasinghe <[email protected]> To: [email protected] Sent: Sun, January 23, 2011 4:08:04 PM Subject: Re: axis2 session scopes On 1/23/2011 7:11 AM, am am wrote: I am starting on axis2 (1.5.4). I am looking into the various session scopes for web services (request, soapsession etc). By experimenting, I notice that in all scopes except the application scope, there is a new instance of my web service being created per service call. Only by setting the scope to "application" in the services.xml, the web service is instantiated only once, and being re-used across all web service calls. My testing for this, was actually a print statement in the web service constructor. The constructor was called for scope="request" or scope="soapsession" or scope="transportsession" for each ws call. So my question is the following: Is this the case in axis2? And if yes, for non-trivial web services, isn't it very costly (to re-instantiate per service call)? Is the recommended approach to use application scope services? Or my understanding is wrong here? Nope, this is not the way Axis2 does the session. As I can see you have not send session related information to manage the session. For example, when you use soapsession you need to send the session ID, which you can do simply by engaging addressing module to both client and server side and setting the setManageSession(true) in the option object. Similarly, when you use transport session you are required to send the cookies, which can also done by setting the above property. For the request session, it creates service instance for each invocation. Deepal Thank you!
