ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis/Raleigh/IBM" <>
Subject RE: Transaction ID Namespace (was Object lifetime options)
Date Thu, 02 Nov 2000 20:08:23 GMT
While it doesn't handle the 'transaction-ness' of your idea
the pluggable provider code that will soon be checked-in
will handle the notion of an 'instance-id' being passed back
and forth between the client and the server, allowing the
server/provider the chance to identify which specific object
to invoke the method on.

Bill Wishon <> on 11/02/2000 02:20:04 PM

Please respond to

To:   "''" <>
Subject:  RE: Transaction ID Namespace (was Object lifetime options)

Actually the 'transaction' I am thinking about is purely an RPC construct
idea.  I'm thinking of the transaction like this:

1.  Begin the transaction by creating a remote object.  The client receives
a transaction ID.
2.  Modify that remote object using soap RPC requests.  Each soap request
has the transaction ID in the header to identify which object to invoke the
method on the server side.
3.  Request some output from that object.
4.  Dispose of the remote object ending the transaction.

The xaml stuff seems more oriented around a businesslike transaction,
card purchases, business to business e-commerce communication, and things
that nature.


-----Original Message-----
From: graham glass []
Sent: Thursday, November 02, 2000 11:04 AM
Subject: RE: Transaction ID Namespace (was Object lifetime options)

you might check out
i think they're working on this kind of stuff.


-----Original Message-----
From: Bill Wishon []
Sent: Thursday, November 02, 2000 12:43 PM
To: ''
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.


-----Original Message-----
From: Bill Wishon []
Sent: Tuesday, October 31, 2000 3:15 PM
To: ''
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
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
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?


View raw message