Mailing-List: contact soap-dev-help@xml.apache.org; run by ezmlm
Message-ID: <099A29474675D41190B3009027DCCCAE0C991E@JNM-MAIN>
From: Bill Wishon <Bill.Wishon@PictureIQ.com>
To: "'soap-dev@xml.apache.org'" <soap-dev@xml.apache.org>
Subject: RE: Transaction ID Namespace (was Object lifetime options)
Date: Thu, 2 Nov 2000 11:20:04 -0800 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Actually the 'transaction' I am thinking about is purely an RPC construct or
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, credit
card purchases, business to business e-commerce communication, and things of
that nature.

-Bill

-----Original Message-----
From: graham glass [mailto:graham-glass@mindspring.com]
Sent: Thursday, November 02, 2000 11:04 AM
To: soap-dev@xml.apache.org
Subject: RE: Transaction ID Namespace (was Object lifetime options)


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