Hello,
This discussion is somehow strange because, and I agree with David: you
don't seem to be speaking about the same thing at the same time...
Asynchronous argumentation is hard to follow...
- I think we should have interceptors
- Yes, but the sky is blue
- No! Invokers can't handle DTM in this case
- You mean AOP?
I understand David's point of view. David loves orthogonal designs and the
idea to have somehow symetric interceptors (between the client and the
server), possibly with a null invoker in the middle of the chain makes his
design pleaseant. Nevertheless, where I think I agree with Bill is that we
first have to check if we don't go too far just for the beauty of it. Let's
take IIOP as an example. In the general case, IIOP can only transport the
same kind of data:
- invocations information (method name, arguments, etc.)
- arbitrary context information
In the arbitrary payload, you may find security information, transaction
information, etc. The question is: at the end of the day, do we really need
a stack of interceptors just to extract this set of information and populate
a JBoss invocation object? Couldn’t we more simply just extract "all this
stuff" and put it in the Invocation Object (and the server side Invoker
could do that).
I agree, it would look much smarter to have this "separation of concern" and
have each interceptor from a virtual-client-stack (i.e. client side
interceptors living on the server and mimic-ing client-side behaviour) put
only what is needed inside the JBoss invocation object. NEVERTHELESS, as
this information will always be similar, why not simply do that in a generic
way inside the invoker: in-mass population of the invocation with well-known
key names for well-known invocation content.
If you think about it, the invoker already does that: it extracts the target
MBean ObjectName from the invocation and push the invocation to it: if you
push your reasoning far enough, that's already a concern that shouldn't be
put in a pure "transport-focused invoker". But I agree, and as French say:
"Je pousse mémé dans les ortilles". Translation left as an exercise.
Cheers,
Sacha
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of David Jencks
> Sent: lundi, 24. février 2003 21:02
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] TxInterceptor split is still the
> best thing since sliced bread
>
>
> On 2003.02.24 14:35 Bill Burke wrote:
> >
> >
> > >
> > > Bill, what I find really boring and unpleasant about this
> discussion is
> > > that I can't find any evidence that you read most of my
> posts, or that
> > you
> >
> > Ditto.
> >
> > I thought I did read your stuff and replied appropriately. Maybe I
> > missed
> > something. What I saw you propose for non-Java and I'll quote you:
> >
> > "outside world >>> something corba and proxy-like > ci1 >
> ci2 > some kind
> > of
> > invoker-like thing > si1 > si2 > actual target object"
> >
> > My argument against this was that you would have to
> maintain 2 separate
> > interceptor chains on the server.
> >
> > For IIOP the chain would be (as you stated)
> >
> > IIOPInvoker > ci1 > ci2 > si1 > si2 > actual target object.
> >
> > For RMI/Java the chain would be
> >
> > DP > ci1 > ci2 > ---- network --- JRMPInvoker > si1 > si2
> >
> > I voiced a similar problem with AOP where the AOP
> interceptors would have
> > to
> > know whether the call had traveled through a remote proxy object.
>
> I wrote the lengthy description/picture below in an attempt
> to find out
> what you are talking about, since this argument doesn't make
> sense to me.
> I didn't see any response from you about it.
>
> I'll try to explain why, specifically, your argument makes no
> sense to me.
>
> I think interceptors all implement required functionality.
> If you put them
> in the chain, it's for a reason: they are doing something you need.
> Therefore, however many transport steps are in the middle,
> any invocation
> should go through the same (target specific) interceptors.
> (IMO transport
> layer interceptors on both ends are a good idea too, but
> that's a separate
> argument). If the interceptor chains have different
> interceptors, you will
> get different behavior, and you should be getting that
> through other means
> such as additional deployments.
>
> Therefore, for a conceptual interceptor chain of ci1 > ci2 >
> si1 > si2,
> this might end up as
>
> ci1 > ci2 > ||transport from client machine to server || > si1 > si2 >
> target object.
>
> or
>
> ci1 > ci2 > ||do nothing "transport" on same machine || > si1 > si2 >
> target object.
>
> It might be possible to arrange for
>
> ci1 > ci2 > si1 > si2 > target object but I don't see why
> you'd want to
> particularly.
>
> Furthermore, for corba,
>
> java-corba-endpoint on server > ci1 > ci2 > || possible "transport"
> translation layer whose need is questionable || > si1 > si2 > target
> object.
>
> To me these are all the same interceptor chain: they all have the same
> members, with the exception of the one missing any kind of
> transport. The
> chain has 2 entry points: ci1 and si1. If you regard this as
> more than one
> interceptor chain please explain your point of view. As I
> understand it,
> this is also essentially how we handle ejbs today: certainly
> we maintain
> both the client and server interceptor stacks on the server.
>
> It occurs to me that what you write is consistent with not
> having client
> side interceptors for aop. Is this your plan? If so, how
> will you gather
> the context information for the invocation? If not, why do
> you want to
> put limits on what the client side interceptors can do?
>
>
> thanks
> david
>
>
> >
> > > remember the reasons for my design decisions for more than about
> > > 5 minutes.
> > > I've written fairly detailed explanations of my views of both
> > interceptor
> > > architecture and corba integration and asked for comments
> or whether
> > you
> > > agree or disagree. I haven't seen any direct responses.
> > >
> > > At this point I don't want to read the same argument from
> you again.
> > > Please implement your idea for how dtm will work so we can discuss
> > > something concrete.
> > >
> >
> > I think I already have (see below), but will reread your
> posts to make
> > sure.
> >
> > Bill
> >
> >
> >
> > > thanks
> > > david
> > >
> > >
> > > On 2003.02.24 13:37 Bill Burke wrote:
> > > > Sure. The TxSupport class is a nice change and makes
> the code much
> > more
> > > > readable. I have stated this before. But....
> > > >
> > > > Merge TxSupport.clientInvoke and serverInvoke into one method.
> > Remove
> > > > all
> > > > logic from client interceptor except TX propagation.
> Propagate the
> > TX
> > > > always. Again, my reasoning is to isolate the EJB
> container from
> > the
> > > > transport mechanism. Currently, in 3.2, you can invoke
> on an EJB
> > from
> > > > any
> > > > protocol at the same time. With David's change,
> non-Java clients
> > that
> > > > support TX propagation would require that
> TxSupport.clientInvoke be
> > run
> > > > on
> > > > the server thus requiring us to have transport specific
> server-sdie
> > > > interceptor chains and a change to the current
> architecture. I think
> > > > that
> > > > this creates further complication in the server-side
> architecture and
> > > > will
> > > > further bloat configuration. All just to save a tx
> propagation for
> > > > NotSupported and RequiresNew methods.
> > > >
> > > > Or are you talking about the AOP stuff? Well, it is
> implemented, I
> > do
> > > > have
> > > > an API. I have written the AOP Tx interceptor and it is tested
> > within
> > > > the
> > > > testsuite. I am working on the Security one. So far, my
> > > design seems to
> > > > fit. The real test will be with the persistence
> metadata since this
> > is
> > > > much more complicated. I've made an attempt to explain
> my design
> > with
> > > > the
> > > > bootcamp slides and the crappy documentation I put
> together on the
> > > > website
> > > > /developers/projects/jboss/aop.jsp.
> > > >
> > > >
> > > > Bill
> > > >
> > > > > -----Original Message-----
> > > > > From: [EMAIL PROTECTED]
> > > > > [mailto:[EMAIL PROTECTED]
> > > Behalf Of Dain
> > > > > Sundstrom
> > > > > Sent: Monday, February 24, 2003 12:36 PM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Re: [JBoss-dev] TxInterceptor split is still the best
> > thing
> > > > > since sliced bread
> > > > >
> > > > >
> > > > > Bill,
> > > > >
> > > > > Where is you design? David's design looks totally
> obvious to me.
> > It
> > > > > is well understood, and based on our existing "real-world"
> > > experiences.
> > > > > To me it looks like you are the one invent "the perfect
> > design/API".
> > > > > So can you present you invocation chain as did and show us
> > > the error in
> > > > > our logic?
> > > > >
> > > > > -dain
> > > > >
> > > > > On Monday, February 24, 2003, at 09:39 AM, Bill Burke wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: [EMAIL PROTECTED]
> > > > > >>
> [mailto:[EMAIL PROTECTED] Behalf
> > Of
> > > > > >> David
> > > > > >> Jencks
> > > > > >> Sent: Saturday, February 22, 2003 11:48 AM
> > > > > >> To: [EMAIL PROTECTED]
> > > > > >> Subject: RE: [JBoss-dev] TxInterceptor split is still the
> > > best thing
> > > > > >> since sliced bread
> > > > > >>
> > > > > >>
> > > > > >> This is really boring and unpleasant, bill. We
> don't seem to
> > > > > >
> > > > > > I am sorry I am boring you. Summarized, my major concern
> > > with the TX
> > > > > > refactor is that it will not work for clients that
> cannot have
> > > > > > interceptor
> > > > > > chains (i.e. non-Java), but support Tx propagation
> (CORBA) for
> > all
> > > > > > trans-attributes (specifically, NotSupported, and
> RequiresNew).
> > I
> > > > > > thought
> > > > > > Marc's vision for creating these generic, transport
> > > specific invokers
> > > > > > was to
> > > > > > isolate the EJB Container from the transport layer,
> and I see
> > this
> > > > > > refactor
> > > > > > as breaking this vision.
> > > > > >
> > > > > > The only way I see this working is if we have separate
> > > > > > transport-specific
> > > > > > interceptor chains on the server to support
> non-Java clients. I
> > > > > > wanted to
> > > > > > avoid this because this is what has happened when I put in
> > support
> > > > for
> > > > > > multiple invokers. Client-side interceptor
> configuration became
> > > > > > bloated.
> > > > > > All this to avoid creating and passing over a TxId.
> See my point
> > > > now?
> > > > > >
> > > > > > ===========================
> > > > > >
> > > > > > As far as AOP goes, I'm hoping that as we implement
> services on
> > top
> > > > of
> > > > > > the
> > > > > > Framework and apply the framework to JMX and remoting, the
> > > > > > requirements and
> > > > > > API will be fleshed out as we iterate. I'd like the design
> > > of AOP to
> > > > > > be
> > > > > > driven by "real-world" requirements and applications rather
> > > than what
> > > > > > we
> > > > > > might think as the perfect (and probably bloated)
> > > design/API might be
> > > > > > currently. I'm not afraid of throwing code out or having to
> > modify
> > > > > > huge
> > > > > > amounts of code to iterate. Iteration is key.
> Allows us to get
> > to
> > > > > > market
> > > > > > quick and to quickly notice bad designs. Didn't
> somebody say
> > > > "Release
> > > > > > early, release often"?
> > > > > >
> > > > > > Bill
> > > > > >
> > > > > >
> > > > > >> have a shared
> > > > > >> understanding of how interceptors ought to work
> with local and
> > > > remote
> > > > > >> calls. Most of your comments make no sense to me,
> and I think
> > > > > >> contrariwise. I'll try to explain my view one
> more time, and
> > > > > >> I'll write an
> > > > > >> interceptor framework that satisfies my
> understanding of what is
> > > > > >> needed for
> > > > > >> mbeans, ejbs, remoting, and aop (which I don't
> understand all
> > that
> > > > > >> well).
> > > > > >> If you don't like it and I can't understand your
> objections,
> > I'll
> > > > let
> > > > > >> you
> > > > > >> indulge your previously expressed wish to write a
> transaction
> > > > > >> manager. You
> > > > > >> might also get that wish fulfilled if you say the
> following is
> > > > > >> obvious. I
> > > > > >> thought it was, but I don't think we have agreed on it.
> > > I'm writing
> > > > > >> it
> > > > > >> down to try to form a basis for discussion, which
> is currently
> > > > > >> missing.
> > > > > >>
> > > > > >> ==========================
> > > > > >>
> > > > > >> Dave's mental model for invocations.
> > > > > >>
> > > > > >> Lets assume first you already have something representing
> > > the object
> > > > > >> you
> > > > > >> are interested in (such as an ejb Remote interface
> object, mbean
> > > > > >> thingy,
> > > > > >> aop-ized object, or some kind of proxy). Items
> marked with a *
> > > > might
> > > > > >> be
> > > > > >> removed for non-remotable objects.
> > > > > >>
> > > > > >> Key to symbols:
> > > > > >>
> > > > > >> \/ interceptor chain "invokeNext()" calls.
> > > > > >>
> > > > > >>
> > > > > >> \/
> > > > > >> || method/field access/... calls whose nature may vary
> > > > > >> depending on the
> > > > > >> application and that are not part of the
> interceptor/invocation
> > > > > >> framework.
> > > > > >>
> > > > > >> \/
> > > > > >> \/ calls between "segments". These are of the form
> > > > > >> invoke(invocation)
> > > > > >> on a particular object found by the current interceptor.
> > > > > >>
> > > > > >> .......... sequence of interceptors in a chain.
> > > > > >>
> > > > > >> ||
> > > > > >> || transport mechanism. For a remote object,
> this is the
> > > > > >> boundary
> > > > > >> between client and server.
> > > > > >>
> > > > > >>
> > > > > >> ===========================
> > > > > >>
> > > > > >>
> > > > > >> Some program does something on the "object"
> > > > > >>
> > > > > >> \/
> > > > > >> ||
> > > > > >>
> > > > > >> The Object
> > > > > >>
> > > > > >> \/
> > > > > >> ||
> > > > > >>
> > > > > >> Something that knows about interceptor chains and
> metadata. It
> > > > looks
> > > > > >> at
> > > > > >> the method (or field access, ...) call and its
> environment and
> > > > > >> determines
> > > > > >> what interceptor chain to use. It constructs an Invocation
> > object
> > > > > >> that
> > > > > >> includes an iterator over the selected chain, the
> method call
> > data,
> > > > > >> and
> > > > > >> some metadata. Then it starts the invocation down
> the chain. I
> > > > will
> > > > > >> call
> > > > > >> this a Container. I believe it corresponds to your aop
> > Advisor(s).
> > > > > >>
> > > > > >> \/
> > > > > >>
> > > > > >> Several interceptors (client side interceptors
> specific to the
> > > > > >> object/class you are calling)
> > > > > >>
> > > > > >> .....
> > > > > >>
> > > > > >> \/
> > > > > >>
> > > > > >> * Transport selector interceptor. This examines
> the metadata
> > and
> > > > > >> picks a
> > > > > >> transport endpoint. It calls invoke(invocation)
> on the selected
> > > > > >> transport
> > > > > >> endpoint. It does not call
> invocation.invokeNext(), so this may
> > be
> > > > > >> the end
> > > > > >> of the use of the original interceptor iterator.
> > > > > >>
> > > > > >> \/
> > > > > >> \/
> > > > > >>
> > > > > >> * Transport endpoint. If this is a local "do nothing"
> > transport,
> > > > it
> > > > > >> may
> > > > > >> simply call invocation.invokeNext(). Otherwise,
> it replaces the
> > > > > >> interceptor iterator with one for the client side transport
> > > > > >> interceptor
> > > > > >> stack.
> > > > > >>
> > > > > >> \/
> > > > > >>
> > > > > >> * Several interceptors (client side interceptors
> specific to the
> > > > > >> transport
> > > > > >> endpoint you are calling. Examples would include
> the XAResource
> > > > > >> representing a remote jboss instance (whenever the
> branch is
> > > > created,
> > > > > >> you
> > > > > >> still need an XAResource, and it needs to know
> about the method
> > > > > >> calls), and
> > > > > >> the clustering thingy that picks a remote server)
> > > > > >>
> > > > > >> \/
> > > > > >>
> > > > > >> * client side end of the transport. I believe this is
> > essentially
> > > > the
> > > > > >> remoting framework.
> > > > > >> ||
> > > > > >> ||
> > > > > >> ||
> > > > > >> * server side end of the transport. This may
> include some kind
> > of
> > > > > >> relationship with a thread pool. Lets assume the work is
> > > > > >> dispatched with a
> > > > > >> thread, no matter how it is picked and how
> > > > > >> synchronous/asynchronous it is.
> > > > > >> Anyway, the reconstituted invocation object has
> its interceptor
> > > > > >> iterator
> > > > > >> replaced with one for the transport specific server side
> > > > interceptors
> > > > > >>
> > > > > >> \/
> > > > > >>
> > > > > >> * Several interceptors (server side interceptors
> specific to
> > the
> > > > > >> transport. In my current dtm implementation, one
> of these would
> > > > > >> import an
> > > > > >> xid in the invocation into the server side tm)
> > > > > >>
> > > > > >> .....
> > > > > >>
> > > > > >> * Target selector. Based on the metadata, this
> interceptor
> > picks
> > > > and
> > > > > >> locates a target object, and calls
> invoke(invocation) on it.
> > This
> > > > is
> > > > > >> the
> > > > > >> end of the transport specific server side
> interceptor chain.
> > > > > >>
> > > > > >> \/
> > > > > >> \/
> > > > > >>
> > > > > >> * Server side target object. This is analogous to
> the current
> > > > > >> server side
> > > > > >> ejb Container object. It replaces the
> invocation's interceptor
> > > > > >> iterator
> > > > > >> and starts it off by calling invocation.invokeNext().
> > > > > >>
> > > > > >> \/
> > > > > >>
> > > > > >> Server side interceptors. For non remotable
> objects and for "no
> > > > > >> transport"
> > > > > >> local remotable objects, the original interceptor
> chain would
> > > > continue
> > > > > >> here.
> > > > > >>
> > > > > >> .......
> > > > > >>
> > > > > >> \/
> > > > > >>
> > > > > >> Final interceptor. This uses the metadata and the method
> > > > > >> information to do
> > > > > >> something to the actual object instance we are
> working with.
> > > > > >>
> > > > > >> \/
> > > > > >> ||
> > > > > >>
> > > > > >> object of interest.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> Note that this requires, for remotable objects,
> being able to
> > get
> > > > two
> > > > > >> interceptor iterators: one for the client side
> iterators, and
> > one
> > > > for
> > > > > >> the
> > > > > >> server side iterators. For "local only" objects, you
> > > only need one
> > > > > >> interceptor iterator. For objects that can be
> local or remote,
> > > > > >> looking up
> > > > > >> the server side target object can be avoided if
> the client side
> > > > > >> interceptor
> > > > > >> iterator also includes all the server side interceptors:
> > > the (client
> > > > > >> side)
> > > > > >> Transport Endpoint would (after determining that
> the call is
> > local)
> > > > > >> simply
> > > > > >> call invokeNext() on the invocation.
> > > > > >>
> > > > > >>
> > > > > >> Lets see if we can come to an agreement on this
> much before we
> > > > > >> consider
> > > > > >> constructors or how to get something representing a remote
> > object.
> > > > > >>
> > > > > >> Please remember that I consider this very
> obvious, but I don't
> > > > think
> > > > > >> we
> > > > > >> agree on it: I think if we did your comments would
> make sense to
> > > > > >> me, and so
> > > > > >> far they don't. Saying something like "don't be
> obvious" will
> > > > > >> indicate to
> > > > > >> me that you are not interested in discussing this aspect of
> > jboss
> > > > > >> architecture with me, so I will take your
> recommendation and
> > stop
> > > > > >> working
> > > > > >> with interceptors, at least until my curiousity
> gets the better
> > of
> > > > my
> > > > > >> sense.
> > > > > >>
> > > > > >> david
> > > > > >>
> > > > > >>
> > > > > >> -------------------------------------------------------
> > > > > >> This SF.net email is sponsored by: SlickEdit Inc.
> Develop an
> > edge.
> > > > > >> The most comprehensive and flexible code editor
> you can use.
> > > > > >> Code faster. C/C++, C#, Java, HTML, XML, many
> more. FREE 30-Day
> > > > Trial.
> > > > > >> www.slickedit.com/sourceforge
> > > > > >> _______________________________________________
> > > > > >> Jboss-development mailing list
> > > > > >> [EMAIL PROTECTED]
> > > > > >>
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> > > > > >
> > > > > >
> > > > > >
> > > > > > -------------------------------------------------------
> > > > > > This sf.net email is sponsored by:ThinkGeek
> > > > > > Welcome to geek heaven.
> > > > > > http://thinkgeek.com/sf
> > > > > > _______________________________________________
> > > > > > Jboss-development mailing list
> > > > > > [EMAIL PROTECTED]
> > > > > >
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This sf.net email is sponsored by:ThinkGeek
> > > > > Welcome to geek heaven.
> > > > > http://thinkgeek.com/sf
> > > > > _______________________________________________
> > > > > Jboss-development mailing list
> > > > > [EMAIL PROTECTED]
> > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Jboss-development mailing list
> > > > [EMAIL PROTECTED]
> > > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> > > >
> > > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
