ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "graham glass" <graham-gl...@mindspring.com>
Subject RE: Transaction ID Namespace (was Object lifetime options)
Date Thu, 02 Nov 2000 19:03:43 GMT
you might check out www.xaml.org.
i think they're working on this kind of stuff.

cheers,
graham

-----Original Message-----
From: Bill Wishon [mailto:Bill.Wishon@PictureIQ.com]
Sent: Thursday, November 02, 2000 12:43 PM
To: 'soap-dev@xml.apache.org'
Subject: Transaction ID Namespace (was Object lifetime options)



In trying to implement my new object lifetime model I have made quite a bit
of headway.  But I've come across one issue that I would like to get some
input on.  I was reading the soap 1.1 specification and came across section
7.2 it talks about the use a transaction ID to go along with the message
that is placed in the soap headers.  This idea of a transaction ID is
exactly what I would like for my object lifetime model, that is the
transaction scope/lifetime.  So my new question is what name space/XML
element should be transaction ID be?  The idea of a transaction ID is not
part of the soap specification per se but rather part of the infrastructure
component that handles the RPC messaging.  Is there name space that exists
already for the soap implementation done by Apache?  If so should I add the
transaction ID to that name space?  If there is no such name space already
should one be created for this implementation?  And if so what should that
be called?

There is another reference in the soap specification to transactions and
that is in section 4.2.1.  It shows an example header that include the
transaction ID, but the name space is just left as some-URI.  It is exactly
that URI that I'm interested in getting input on.

-Bill

-----Original Message-----
From: Bill Wishon [mailto:Bill.Wishon@PictureIQ.com]
Sent: Tuesday, October 31, 2000 3:15 PM
To: 'soap-dev@xml.apache.org'
Subject: Object Lifetime Options



Are there any plans to add more object lifetime options to soap services?

Right now there are the Application, Session, Request and Page choices for
the lifetime of the service object(s).  For an application I am writing I
would like an ID/timeout based lifetime model which would work something
like this:

Each request would have an object ID in it somewhere, either as the first
parameter or perhaps in the headers.  Every time a request is received with
a null object ID a new object is created, assigned an ID and inserted into a
hash that lives as part of the servlet context.  If a request with an ID is
received then that ID is used to lookup an object in the hash table of
objects.  If that object is not found then it is an error.  Every n seconds
we scan through the hash table pulling out objects that have expired, where
the time till an object expires is configurable.

By using a lifetime model like this it is possible for me to write client
side code that doesn't know about or can't deal with sessions and yet can
maintain and manipulate many different server-side objects.  Another big
reason for me wanting to do something like this is so that I don't have to
send the object in question back and forth, encoding and decoding it at each
end, because the object is quite large and it would be to slow.

Does this sound reasonable to anyone or am I alone in wanting this kind of
functionality?  If there are others interested I would be willing to
contribute my modifications back to the codebase.

Any thoughts?

-Bill


Mime
View raw message