Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 35864 invoked by uid 500); 1 Oct 2001 15:56:42 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 35618 invoked from network); 1 Oct 2001 15:56:36 -0000 Subject: RE: How to get/pass header session information To: axis-dev@xml.apache.org Cc: axis-user@xml.apache.or X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: "Greg Truty" Date: Mon, 1 Oct 2001 10:55:38 -0500 X-MIMETrack: Serialize by Router on D04NM201/04/M/IBM(Release 5.0.8 |June 18, 2001) at 10/01/2001 11:55:38 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Is an API to manipulate headers really something that you want as part of the client programming model? Headers really contain contextual information with isn't part of the request. Therefore, it shouldn't be part of the client programming model. However, if the exposing is a way to manipulate the headers within the handler framework, than that portion makes sense. Other problems is that you essentially have are if you want to support other XML encodings eventually, you have to re-write your app. If the support was added to the runtime for other XML encodings, the app wouldn't change, just the runtime and the changes to the handlers to support the new header structure. Regards...Greg Greg Truty WebSphere Architecture/Development, IBM Austin EMail: gtruty@us.ibm.com (Internal) gtruty@ibmusm26 Phone: (ext) (512) 838-2828 (Tie) 678-2828 "Doug Davis" cc: axis-user@xml.apache.org Subject: RE: How to get/pass header session 10/01/2001 information 08:04 AM Please respond to axis-dev In general I think you're probably right - not widely advertising that a client can muck with (or even get at) the SOAP envelope would be a good thing. It helps keeps the client app at a higher level and not tied so directly to SOAP. However, I do think it is worthwhile to make those APIs available so that people who do want it can get at it. Requiring people to have to write handlers is asking a but much (IMHO). -Dug Russell Butek/Austin/IBM@IBMUS on 10/01/2001 08:57:57 AM Please respond to axis-dev@xml.apache.org To: axis-dev@xml.apache.org cc: axis-user@xml.apache.org Subject: RE: How to get/pass header session information Do we have any concern with letting clients have direct control over message header info? I'm still a newbie to the SOAP world, so maybe my assumptions are baloney, but in the CORBA world, we really didn't want the client to be able to muck with the message headers. The header was the realm of the ORB and its services: security, transactions, etc. and we didn't want clients to tamper with their information. Portable interceptors were developed for service folks to gain limited access to the header. A client could always write an interceptor, but access to the header was limited enough that they could add their own info, but not mess with what was already there. Russell Butek butek@us.ibm.com Glen Daniels on 09/28/2001 04:04:14 PM Please respond to axis-dev@xml.apache.org To: "'axis-user@xml.apache.org'" cc: "'axis-dev@xml.apache.org'" Subject: RE: How to get/pass header session information Good catch, Mark. I think the right solution to this might be to add APIs like this to ServiceClient: public void addHeader(SOAPHeader header) public void clearHeaders() This would allow the user to add headers to outgoing messages. I'm not sure, but I think a good default might be to persist the headers across invoke()s unless clearHeaders() is called, which would enable very easy usage in scenarios like the session one you mention. Axis-dev'ers? +1, -1? --Glen > -----Original Message----- > From: Mark Roder [mailto:mroder@wamnet.com] > Sent: Friday, September 28, 2001 4:02 PM > To: 'axis-user@xml.apache.org' > Subject: RE: How to get/pass header session information > > > > I figured out how to get the session information by doing the > following: > User aUser=ArchiveDataTEST.getValidUser(); > RPCParam userParam = new RPCParam("User", aUser) ; > > String endpoint = > "http://localhost:80/cgi-bin/wambase/mvsrch_front"; > > ServiceClient client = new ServiceClient(endpoint); > client.addOption(AxisEngine.PROP_DOMULTIREFS, new Boolean(false)); > client.addSerializer(User.class,new QName(),new BeanSerializer()); > String ret = (String)client.invoke("Login", > new Object [] > {userParam }); > Message msg = client.getResponseMessage(); > SOAPEnvelope env=msg.getAsSOAPEnvelope(); > SOAPHeader sessionHeader = > env.getHeaderByName("urn:schemas-wamnet-com:Session","SessionID"); > String aString = (String) sessionHeader.getValueAsType(new > QName(Constants.URI_2001_SCHEMA_XSD, "string")); > > String sessionId = aString.trim(); > System.out.println("SessionID:" +sessionId); > > I can create(I think it works) a header using the following code: > Document doc = XMLUtils.newDocument(); > Element element = > doc.createElement(ArchiveConstants.NS_SESSION_ID); > element.setAttribute(ArchiveConstants.NS_AUTH_REF, > ArchiveConstants.NS_AUTH_URI); > element.appendChild(doc.createTextNode(sessionId)); > SOAPHeader sessionHeader = new SOAPHeader(element); > > Now that I have the SOAPHeader, it looks like ServiceClient > is written in a > way that doesn't allow me to add my own SOAPHeaders to a message. > > The invoke(method,args) creates a RPCElement and then runs > invoke(RPCElement). > > The invoke(RPCElement) creates the SOAPEnvelope and adds the > body, creates > the message, calls invoke() and then decodes the response. > > What I want to do is add my own header after the > invoke(RPCElement) does the > work of setting up the message but before invoke() is called. > > Options: > Option1: I started down the wrong path and there is an easier way. > Option2: > Change how the invoke methods are called so that the > RPC invokes call > a "createEnvelope(method,args)" method that returns a > SOAPEnvelope. They > then call the invoke(SOAPEnvelope) method to make the call. A > "decode(SOAPEnvelope)" method will then return the object. > This is breaking > up the current invoke(RPCElement) method into the part above > invoke() and > below invoke(). > > This change would allow me to do the following in my code: > > reqEnv = client.createMessage(method,args); > reqEnv.addHeader(myHeader); > responseEnv = client.invoke(reqEnv); > resultObject = client.decode(responeEnv) > > Option3: Make a method that you can pass in a header for > the message > > Does this make sense? Am I missing something? > > Later > > Mark > > > > > > > -----Original Message----- > From: Mark Roder [mailto:mroder@wamnet.com] > Sent: Friday, September 28, 2001 12:29 PM > To: 'axis-user@xml.apache.org' > Subject: How to get/pass header session information > > > > I am just starting to use axis, so this may be simple. I am > working on a > soap client application hitting an existing server. > > How do I pull the session information out of the header of > the following > response? > > Then, how do I add it all following requests? > > > My current code: > > User aUser=ArchiveDataTEST.getValidUser(); > RPCParam userParam = new RPCParam("User", aUser) ; > > String endpoint = "http://localhost:80/cgi-bin/wambase/mvsrch_front"; ServiceClient client = new ServiceClient(endpoint); client.addOption(AxisEngine.PROP_DOMULTIREFS, new Boolean(false)); client.addSerializer(User.class,new QName(),new BeanSerializer()); String ret = (String)client.invoke("Login", new Object [] {userParam }); System.out.println("Sent 'Hello!', got '" + ret + "'"); Response I need to get session information out of: HTTP/1.1 200 OK Date: Fri, 28 Sep 2001 16:39:10 GMT Server: Apache/1.3.11 (Unix) mod_ssl/2.5.0 OpenSSL/0.9.4 Connection: close Content-Type: text/xml ses09281011739119691.id Example request I need to put the session information into: POST /cgi-bin/wambase/mvsrch_front HTTP/1.0 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: 608 SOAPAction: "urn:schemas-wamnet-com:Archive#GetLibraries" ses09281011809017084.id Thanks Mark