[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [aspectj-users] AspectJ, cflow and server side J2EE code.
- From: Ichthyostega <prg@xxxxxxxxxxxxxxx>
- Date: Thu, 06 Nov 2008 23:19:21 +0100
- Delivered-to: firstname.lastname@example.org
- Openpgp: id=A1DE94B2
- User-agent: IceDove 22.214.171.124eol (X11/20080724)
-----BEGIN PGP SIGNED MESSAGE-----
Tiwary, Amit schrieb:
> We want to send the User Context object containing name, product
> which he is using, client code etc to our server side code. ...Now
> from JSF Layer, using the Stateless Session Bean, the call reaches
> the server side. Server side we have many Spring managed POJOs called
> from Stateless Session Bean and JPAs. Now I want to send the User
> Context information transparently to the server side layer from UI
> Layer. I have implemented the WormHole pattern using cflow construct
> and pointcuts.
Yes, indeed, using the Wormhole pattern in some variant can be a nice
solution for this kind of problem. We did such in comparable situations
several times. For example, we were able to "mandantisize" an existing
application in record time and without massive intrusive changes to the
whole existing code base, just by adding some extensions and some aspects.
> a) Should I use AspectJ with EJB? Is it safe? b) Will my user context
> reach server side Spring Code (behind the Stateless EJB Layer) from
> UI using the wormhole correctly?
I will answer this questions from a more general viewpoint. Basically,
you should never use AspectJ to "subvert" a given architecture, only to
extend and augment it at well defined interfaces.
The net result of weaving an Aspect is that you have somewhat changed
your (compiled) Java code. As long as the resulting (compiled) Java code
is valid regarding to the EJB spec and as long as you could have
achieved similar results (albeit not so elegantly) by hand written Java
code, you are fine and the solution can be thought of as being "clean".
You should NOT (for example) use the wormhole to bypass an interface or
make a direct call from client code to some server entity which doesn't
go over some Business Facade. (In theory, if client and server are
running on the same VM, it is possible to do so. But the moment you
switch over to a distributed or clustered environment, the code will
break, because you effectively have killed your whole architecture)
Personally, I'd propose you do do the following (but other developers
may prefer other approaches, of course):
(1) on the client side, create a clear interface where the user context
can be retrieved, e.g. given you have some sort of invocation
context or request context. (You stated to have such)
(2) decide on how you want to pass the User Context information over
your server facade. This is highly dependent on the specific design
of your server. For example, you could extend every method on the
server interface to take the User Context as an additional (optional
or required) parameter. Or you could attach the User Context to some
processing context, task context, business process context by a
separate call to the server interface.
(3) decide which points in the *server* need to receive the UserContext.
Then, you' create *two* wormholes.
- - the first wormhole is triggered on the *client* side when the client
issues a call to the server proxy. This wormhole would reach up and
extract the User Context over the interface provided in (1) and will
use the means defined in (2) to pass this additional information to
- - the second wormhole is defined within the *server* and is triggered
at the points (3), i.e. when the UserContext information is needed.
This wormhole would reach up to the server sided implementation
of the server's business interfaces and extract the additional
UserContext information which was passed from the client by
the client sided wormhole.
And one final practical advice: take care that weaving the two
wormhole aspects doesn't interfere with your deployment. This
depends on your situations, but very commonly you want to deploy
the server and the client as separate packages, in which case
you should be careful not to introduce unnecessary package
dependencies between server implementation and client as
a sideeffect of introducing the two wormholes....
hope this helps
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----