Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] AspectJ, cflow and server side J2EE code. 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 server.
- - 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
Hermann V.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJE21pZbZrB6HelLIRAig1AJ9CR+jO2X5IVNiRmvGm1sNEOvGa7ACfRBpk
6VFLBoXtx0U7uE7Vr91q00M=
=+y1L
-----END PGP SIGNATURE-----

Back to the top