Shane,
Getting to what I *think* was your original question... first, if all you're
worried about is tracking the user, and if your app is written using
servlets and EJBs, then note that you have standardized context calls to get
the caller principal in both those environments. Nothing fancy needed, just
getUserPrincipal() stuff (one method on servlet context, another on EJB
Context).
Or, you could use a Logging Decorator that logs every business call into a
user-specific log at each step of the work request tracing through the
server. This lets you log/bill/whatever on a method invocation on a specific
component (or many of them - up to you) without doing anything at all in
your business logic. We expect this to be a powerful technique.
Or, you may want more/different information. In that case, you can look to
our context propagation, described below. In summary, we will be passing
contexts using ThreadLocal variables, to avoid altering business APIs, and
we expect to serialize that data over remote calls too.
(Note - some of what I'm describing below is in place now, some is still in
the design/implementation phase. But it's what we expect in Ver 4)
(Or at least, it's what *I* expect ... life is changeable ...)
In Enhydra Enterprise, the plan is that we attach some Contexts to the
thread that handles a work request. For example, the WebContainer attaches a
SecurityContext and an ApplicationContext to each HTTP Request... the
SecurityContext identifies the user/client for the work request; and the
AppContext provides data which is visible to every component and thread
working for that application. We use the AppContext for various things
(tracking namespace roots might go there, for example) but we also will let
you write name/value pairs of application environment variables into it just
as you do in an Enhydra 3 context. (Though I'd rather see those bound into
JNDI in an app: namespace, at least for Enhydra Ver 4 apps.)
We have not decided where to put the session ID in the internal context
structure: a new context - the session context? (That's my candidate) ... an
attached element on the app context? (but the session id isn't constant
across the app, since there are multiple session actyive in the app at
once)... a new Principal in the security context? (That oughta wake up
Craig! but isn't the session id a sort of name?)
The important point in response to your question is that we do context
tracking with ThreadLocal variables which then pass through the business
APIs transparently, and we serialize and propagate those objects during
remote calls, so you could put session or user-tracking code into your
application components and the data would be available wherever the call
goes.
At this point you're probably thinking about two things: what else you can
do with this facility, and how we do our part, propagation ... at least,
that's what *I'm* thinking about :)
You can do a lot, more than I can likely imagine. But, an unresolved issue
might keep us from immediately doing part of the propagation for you - we
have some policy decisions to take about keeping the various copies of
AppCtx running around "sufficiently consistent" - those policy debates
haven't hit the Architecture WG yet ... so dynamic data attached to the app
context by the user may not get propagated in the next release. We'll try -
join that discussion when we get started (another week or two away, I think.
Gotta get the next "release" dropped to Enhydra.org)
As to how we will do our part ... our choices are to extend the approach
that is being used now, or to look for "better" approaches. This is likely
not interesting to many folks, but a little background just in case: the
propagation can take place at the RMI layer (by manipulating the
rmic-generated source for stubs and skels, as JOnAS does with RMI 1.1
support), or in the IIOP layer (as would be done with Handlers in Jeremie or
(I think) RMI-IIOP); or, Rikard Oberg showed a nice trick for doing this
with a plug-in to an undoc'ed API in the JDK1.2 RMI structure (see his
ctxrmi example, over at www.dreambean.com) We are looking at how these play
together, and which ones might support the intra-VM optimization that
Jeremie uses to such good benefit. We have things to learn about managing
threads in the Sun RMI implementation!
Back to your questions: The issue of plug-play compatibility is, ummm,
interesting. Even if we assume you take the Enhydra-generated stubs,
skeletons, support classes etc and install them on a BEA etc server, I don't
think it'll work; all of these approaches assume some code that provides the
context data to be marshalled, and there isn't a good standard there for how
to set up that interoperability, so the answer is probably no when we using
these propagation techniques. (What would an Enhydra SessionID context mean
on a BEA server, even if we got the data unmarshalled? etc) RMI-based
interoperability is fine as far as the spec goes ... but it doesn't go far
enough for all the customer needs...
Hope I got to the question you cared about.
Wayne Stidolph / Lutris Technologies
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Christophe
Ney
Sent: Wednesday, February 14, 2001 10:37 AM
To: 'Shane Muffat'
Cc: [EMAIL PROTECTED]
Subject: RE: a "mini" transaction service for implicit context data
I am not sure.
I would ask this on the JOnAS user mailling list.
Thanks
Christophe
Christophe Ney - mailto:[EMAIL PROTECTED]
Enhydra Project - http://www.enhydra.org
Lutris Technologies - http://www.lutris.com
>-----Original Message-----
>From: Shane Muffat [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, February 14, 2001 7:10 PM
>To: 'Christophe Ney'
>Cc: [EMAIL PROTECTED]
>Subject: RE: a "mini" transaction service for implicit context data
>
>
>Yes! Exactly! Is Jeremie available and plug-in compatable...with
>say...just about any EJB Application Server that supports RMI...in this
>particular case where we are testing...Weblogic 5.1...with Weblogics
>implementation of RMI???
>
>
>
>-----Original Message-----
>From: Christophe Ney [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, February 14, 2001 1:08 PM
>To: Shane Muffat
>Cc: [EMAIL PROTECTED]
>Subject: RE: a "mini" transaction service for implicit context data
>
>
>
>What you need is context propagation. This has not much to
>do with the TM except that context propagation is used to
>pass the transactional context.
>This is done with Jeremie that support attching any context
>to the rmi call. There is also an rmi version in jonas
>that patches the rmi stub to attach the context.
>
>thanks,
>christophe
>Christophe Ney - mailto:[EMAIL PROTECTED]
>Enhydra Project - http://www.enhydra.org
>Lutris Technologies - http://www.lutris.com
>
>
>>-----Original Message-----
>>From: Shane Muffat [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, February 14, 2001 5:52 PM
>>To: 'Christophe Ney'
>>Subject: RE: a "mini" transaction service for implicit context data
>>
>>
>>That is actually besides the point...it should be able to be any bean
>>type...we are trying to build infrastructure type context
>>passing here...and
>>when I talk about TM...it is just something similiar that I think does
>>things sort of like the way we need them. I don't care what type of
>>bean...a business developer creates...or how they implement an RMI
>>server...and I don't have control over either...I just need to
>>be able to
>>"piggy-back" a simple attribute onto each and every call in our J2EE
>>environent and have that data available everywhere...so maybe
>>I was being
>>misleading when talking about the transaction service...
>>
>>
>>-----Original Message-----
>>From: Christophe Ney [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, February 14, 2001 11:31 AM
>>To: Shane Muffat
>>Subject: RE: a "mini" transaction service for implicit context data
>>
>>
>>What kind of bean are you writting
>>session, CMP, BMP.
>>What kind of transaction attribute
>>
>>christophe
>>Christophe Ney - mailto:[EMAIL PROTECTED]
>>Enhydra Project - http://www.enhydra.org
>>Lutris Technologies - http://www.lutris.com
>>
>>>-----Original Message-----
>>>From: Shane Muffat [mailto:[EMAIL PROTECTED]]
>>>Sent: Wednesday, February 14, 2001 5:20 PM
>>>To: 'Christophe Ney'
>>>Subject: RE: a "mini" transaction service for implicit context data
>>>
>>>
>>>But...I really don't want a full-fledged distributed TM no matter how
>>>"simple" it is...I don't need to do any rollback...and don't
>>>need to manage
>>>resources...that all happens with a TM and causes overhead...I
>>>just want to
>>>implicitly pass a session id from component to component
>>>without changing
>>>any business interfaces!!!!
>>>
>>>
>>>-----Original Message-----
>>>From: Christophe Ney [mailto:[EMAIL PROTECTED]]
>>>Sent: Wednesday, February 14, 2001 11:19 AM
>>>To: Shane Muffat; [EMAIL PROTECTED]
>>>Subject: RE: a "mini" transaction service for implicit context data
>>>
>>>
>>>Hi Shane,
>>>
>>>In Enhydra Enterprise, services are pluggable and can be easily
>>>replaced with a simple configuration change. Now, I don't know
>>>if a distributed TM can be simpler than the JOnAS one.
>>>
>>>Thanks,
>>>Christophe
>>>Christophe Ney - mailto:[EMAIL PROTECTED]
>>>Enhydra Project - http://www.enhydra.org
>>>Lutris Technologies - http://www.lutris.com
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [EMAIL PROTECTED]
>>>>[mailto:[EMAIL PROTECTED]]On Behalf Of
>>>Shane Muffat
>>>>Sent: Wednesday, February 14, 2001 5:03 PM
>>>>To: '[EMAIL PROTECTED]'
>>>>Subject: a "mini" transaction service for implicit context data
>>>>
>>>>
>>>>Is there any way...to develop a transaction like service WITHOUT the
>>>>overhead to simply...implicitly pass a session ID from EJB to
>>>>EJB to RMI
>>>>Server...and possibly in reverse...??? The transaction service does
>>>>something like this...does it not? I've looked at everything
>>>>from dynamic
>>>>proxies...which really doesn't help because we need control
>>>>over development
>>>>of the business components...the IIOP layer...and the transaction
>>>>service...but am having a hard time with it. I am trying to
>>develop a
>>>>plugable framework here without having control over the business
>>>>development...this framework needs to track a user (session
>>>>ID) through the
>>>>entire application!!!
>>>>
>>>>Any help would be greatly appreciated!
>>>>
>>>>A perplexed java engineer,
>>>>Shane Muffat
>>>>----
>>>>This list is cross-posted to two mail lists. To unsubscribe,
>>>>follow the instructions below for the list you subscribed to.
>>>>For objectweb.org: send email to [EMAIL PROTECTED] and
>>>>include in the body of the message "unsubscribe transaction-group".
>>>>For enhydra.org: send email to [EMAIL PROTECTED] and include
>>>>in the body of the message "unsubscribe transaction-group".
>>>>
>>>
>>>----
>>>This list is cross-posted to two mail lists. To unsubscribe,
>>>follow the instructions below for the list you subscribed to.
>>>For objectweb.org: send email to [EMAIL PROTECTED] and
>>>include in the body of the message "unsubscribe transaction-group".
>>>For enhydra.org: send email to [EMAIL PROTECTED] and include
>>>in the body of the message "unsubscribe transaction-group".
>>>
>>
>
>----
>This list is cross-posted to two mail lists. To unsubscribe,
>follow the instructions below for the list you subscribed to.
>For objectweb.org: send email to [EMAIL PROTECTED] and
>include in the body of the message "unsubscribe transaction-group".
>For enhydra.org: send email to [EMAIL PROTECTED] and include
>in the body of the message "unsubscribe transaction-group".
>
----
This list is cross-posted to two mail lists. To unsubscribe,
follow the instructions below for the list you subscribed to.
For objectweb.org: send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe transaction-group".
For enhydra.org: send email to [EMAIL PROTECTED] and include
in the body of the message "unsubscribe transaction-group".
----
This list is cross-posted to two mail lists. To unsubscribe,
follow the instructions below for the list you subscribed to.
For objectweb.org: send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe transaction-group".
For enhydra.org: send email to [EMAIL PROTECTED] and include
in the body of the message "unsubscribe transaction-group".
