[aspectj-users] Fwd: [weblogic-aspects] Re: AOP Talk in 'Files' NYWLUG -

[Nicholas Lesiecki <ndlesiecki@xxxxxxxxx>]

I thought this might be of interest to the aspectj-users group...

Cheers,
nick

Begin forwarded message:

> From: "Bob Hathaway" <rjhiii2002@xxxxxxxxx>
> Date: June 10, 2004 9:50:43 PM MST
> To: weblogic-aspects@xxxxxxxxxxxxxxx
> Subject: [weblogic-aspects] Re: AOP Talk in 'Files' NYWLUG - Aspect-Oriented Programming
> Reply-To: weblogic-aspects@xxxxxxxxxxxxxxx
>
> From:  "Bob Hathaway" <rjhiii2002@xxxxxxxxx>
>  Date:  Fri Jun 11, 2004  12:45 am
>  Subject:  Re: AOP Talk in 'Files' NYWLUG - Aspect-Oriented Programming
>
>  --- In NYWLUG@xxxxxxxxxxxxxxx, Michael Poulin <m3poulin@y...> wrote:
>  > [...]
>  > 1) does the concept of AspectJ say it is supposed to work with
>  OO legacy code only?
>
>  While Aspects accommodate after-the-fact logic for code reuse and
>  agility, simple features like logging and
>  performance monitoring benefit from the coherence of the crosscutting
>  aspect and ease of upgrading and
>  changing without modifying source code, benefits available in new code
>  as well as old. Aspects for more
>  advanced uses such as use case flow additions or modifications and
>  patterns could be done within OO
>  hierarchies or in Aspects. Aspects, or concerns (as in separation of
>  concerns), always exist whether
>  explicit or not, by making them explicit they can be upgraded or
>  refactored or combined more easily,
>  and if they exist across class hierarchies then Aspects can promote
>  them to first class support.
>
>  Whether to use Aspects from the start is a matter of style. A strong
>  AOP style would use Aspects from the
>  beginning and potentially even divide logic within classes right from
>  the start. Further uses would include AOP
>  design patterns, in which new code is created from the start with
>  Aspects - an advanced subject I
>  alluded to in the talk but didn't have details in the presentation.
>
>  > 2) if I develop a new Java code and have intention to use
>  AspectJ, should I limit my Java code with just an
>  > implementation of some sort of data transformation logic while
>  delegating method invocation logic/flow to the
>  > AspectJ, i.e. operate at the level of C-like functions ?
>
>  I see Aspects as augmenting functionality and not determining flow,
>  although there may be other opinions
>  or uses. An interesting point is the use of implicit or explicit use
>  of introductions, or added superclasses,
>  methods and fields. These can be implicit, or only invoked from
>  intercepting Advices. They could also
>  be explicit, in which case other non-Aspect code can explicitly invoke
>  them.
>
>  Another way to use Aspects by design is to encode crosscutting logic
>  in Aspects that otherwise would have to
>  be manually coded and if forgotten would be a defect. In
>  'Aspect-Oriented Programming with
>  AspectJ', crosscutting by design, checking a user is logged in is
>  handled by an Aspect 'around' a
>  servlet's doStartTag and throwing an exception if a session is null in
>  any method taking an HttpSession
>  as an argument. This is useful because if a programmer forgot to code
>  the manual check in any servlet
>  then security is breached. This is clearly using Aspects as part of
>  the original application design.
>
>  However, that is what front-controller type J2EE patterns with input
>  chain checking are useful for and also
>  servlet filters, which is how I would code that application (see Core
>  J2EE Patterns or Object FAQ HLD for
>  an example). But this is much more sophisticated than a set of JSPs
>  or servlets with checking done
>  by an Aspect - the choice of solution depends upon the application's
>  requirements and architect/development team's preference or style.
>
>  > 3) if consider the AspectJ as a language of higher level of
>  abstraction than Java, C++, C#, do you know >
>  > about any practice of development process organization that defines
>  the roles and responsibilities for OO >
>  > language developers and aspect-developers, and incorporates them
>  into RUP or XP ?
>
>  I agree Aspect process patterns or standards are the next logical
>  step. From my library:
>  - Aspect-Oriented Programming with AspectJ
>  - Use Patterns - a very high-level look at AspectJ use
>  - Mastering AspectJ
>  - Patterns & Reuse - behaviour patterns, roles, bridge aspects for
>  decoupling, subaspects
>  - persistence, caching,
>  - Design patterns - ObserverProtocol,
>  - Aspect-Oriented Design, adapter aspects for component-based reuse.
>  GOF Patterns in AspectJ -
> http://www.cs.ubc.ca/labs/spl/projects/aodps.html (Prof. Kiczales)
>  - All 22 GOF Design patterns in AspectJ, from 12 reusable pattern
>  aspects.
>
>  AspectJ in Action
>  - Design Patterns and Idioms
>  - Worker Object Creation
>  - Wormhole pattern
>  - Exception Introduction pattern
>  - Participant Pattern
>  - Idioms
>
>  This is of course a very small partial listing and perhaps I can
>  create a more comprehensive summary
>  and catalog of available Aspect patterns to appear on Object FAQ at
>  some point.
>
>  But this represents available options, an enterprise standard for
>  Aspects would need to be developed picking
>  and choosing from among them. But I haven't even seen an enterprise
>  standard for design pattern or
>  architectural pattern usage, at least past a per project architect
>  preference such as J2EE Core and GOF patterns.
>  So for now that's what architect's are for, choosing from each of the
>  above: design, architectural, and Aspect patterns.
>
>  I could see dividing Aspect use into design and non-functional
>  categories and incorporating them into the phases/tasks of the
>  project lifecycle, with non-functional occuring at the architectural
>  level (quality attributes and trans/persist/distr/secur/etc.) and
>  then again around the technology/Ddesign/coding phase (e.g.
>  logging/performance monitoring/errors-warnings) and functional
>  Aspect use being a design phase activity.
>
>  > I have noticed that all use-case examples mentioned above are
>  already available as non-aspect commercial
>  > products. For example, here are several powerful distributed
>  debuggers are available; special monitoring/
>  > tuning systems compete on how minimal amount of their code they
>  insert into original code to calculate
>  > performances, etc. Yes, you have to pay some money for the quality
>  of results and the time somebody spent
>  > on the development. However, this "buy vs. build" frees you to
>  concentrate on your business implementation
>  > rather on palming, I think.
>
>  Absolutely. Where mature products and tools exist, I suggest using
>  them. Where they do not, then the Aspect toolbag can prove
>  invaluable, much like OO.
>
>  > Actually, my major question is this: What business value ( except it
>  is "almost free" ) the aspect programming
>  > offers today ?
>
>  By providing separation of concerns across classes in addition to OO's
>  vertical hierarchies, code quality
>  improves. By supporting modularity of concerns and modifiablity and
>  portability of code, these quality
>  attributes of enterprise applications are improved, the actual ROI or
>  cost benefit ratio depends on
>  your models but the results should provide significant values to
>  justify their use.
>
>  > When JDK 1.5 and J2EE 1.4 get public, do not you think that Java
>  meta-data would be mostly used for very low
>  > level programming ( like JAXM and JAX-RPC today ) ?
>
>  [I think that's J2EE 1.5/EJB3 with Spring/Hibernate like
>  functionality, J2EE 1.4 has been out with Web Services and
>  java.logging.]
>
>  Today Aspects are used for lighter weight EJB aspects such as
>  distribution, persistence, concurrency,
>  security, and transactioning and a number of design use cases and
>  patterns of Aspects are listed above.
>
>  > Please, be so kind to answer these question or refer me to the
>  resources that answer them ( at this point I am
>  > less interested in aspect programming syntax but more in how to
>  position this technology in the stack ).
>  > Thank you for your time and attention.
>
>  I hope I've helped. I believe AOP technology has a place in the
>  application technology stack (not to mention
>  non-functional utility use), the degree of which should be determined
>  at the project or enterprise level. Aspects
>  make a good addition to existing technology, primarily as
>  orthogonal to object-oriented hierarchies
>  through crosscutting separation of concerns.
>
>  Regards,
>  Bob Hathaway
>
>  > P.S. Next week, I am starting with JP Morgan as Sr. Architect in
>  their credit processing Middle-Office.
>
>  Congratulations and good luck.
>
>
>
>  > Unfortunately, I was not able to stay to the end on your
>  presentation and to ask you my questions in-person. So, if you
>  described following topics in the presentation, I do apologies for
>  bothering you again.
>  >
>  >
>  >
>  << Here is the thing. I am trying to learn and understand the
>  applicability of AspectJ ( I mean not the product but the technology )
>  besides "it is a cool thing" definition. From the explanations, I've
>  heard, I've got that the technology allows for operating with Java
>  "meta-data" available in JDK 1.3-1.4. That is, the things are
>  available like pre-, post-method invocation with additional
>  processing, method invocation monitoring ( for debugging and
>  performance evaluation ), even an alternative Java method invocation
>  flow execution ( alternative with respect to existing Java code ). If
>  I am correct at high level, at least, there are my questions: >>
>  >
>  > 1)
>  > [...]
>
>
>
>
>
>
>
> Yahoo! Groups Sponsor
>
> <x-tad-smaller>ADVERTISEMENT</x-tad-smaller>
>

>

> Yahoo! Groups Links
>
> 	• 	To visit your group on the web, go to:
> http://groups.yahoo.com/group/weblogic-aspects/
>  
> 	• 	 To unsubscribe from this group, send an email to:
> weblogic-aspects-unsubscribe@xxxxxxxxxxxxxxx
>  
> 	• 	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Nicholas Lesiecki
Software Craftsman, specializing in J2EE,
Agile Methods, and aspect-oriented programming

Books:
* Mastering AspectJ: http://tinyurl.com/66vf
* Java Tools for Extreme Programming: http://tinyurl.com/66vt

Articles on AspectJ:
* http://tinyurl.com/66vu and http://tinyurl.com/66vv