1 / 40

Efficient Middleware Design with Aspect-Oriented Programming

Explore the seamless integration of AOP within middleware, from interceptors to aspects, enhancing modularity and ease-of-use in designing middleware. Learn about transparent caching, AOP annotations, and leveraging existing JBoss architectures. Gain insights into implementing middleware using AOP for more modular and clutter-free designs. Discover how AOP simplifies extending behavior and system aspects, providing a consistent and easy-to-use framework.

windym
Download Presentation

Efficient Middleware Design with Aspect-Oriented Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementing Middleware with AOP JBoss Aspect Oriented Middleware

  2. Topics • Overview • From Interceptors to Aspects • J2EE a la carte • AOP + metadata • From Aspects to EJB3 • Proxy based AOP • AOP Domains • Annotations as Meta Model • XML + Annotations • Dynamic AOP • Transparent caching • JBoss Cache Demo • Designing a Cache

  3. AOP and Middleware • Middleware is but a collection of cross-cutting concerns • Most middleware already sort of aspectized • CORBA and JBoss heavy use of interceptors • Basing designs on AOP natural step • Expensive to use regular OOP techniques to mix/match configurations • Application is just configuration a set of cross-cutting concerns • Natural step is to implement middleware using AOP • More modular designs • Less code clutter

  4. AOP and Middleware • Aspect Oriented Middleware brings transparency • System aspects can be made orthonogal • Application code can free of system programming • Middleware can be made simpler to use

  5. AOP Makes things Easier • AOP to implement Ease-of-Use • EJB 3 and annotation library implemented with AOP • AOP for Ease-of-Extension • Ease-of-use frameworks written on top of AOP • AOP gives easy consistent way to extend behavior

  6. From Interceptors To Aspects JBoss 3.x to JBoss AOP

  7. JBoss 3.x Architecture • J2EE behavior expressed as interceptors • Detyped method invocations Server JVM • Internally invocation objects are routed within the kernel EJB Container MBean RemoteInvoker Port 1234 Client JVM EJB Container MBean Typed Interface Invocation JMX Microkernel Client RemoteInvoker 011101010101 Port 4321 Service MBean Client Proxy

  8. Cross-cutting Concern • <container-configuration> • <container-name>Standard CMP 2.x EntityBean</container-name> • <container-interceptors> • <interceptor>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.TxInterceptorCMT</interceptor> • <interceptor>org.jboss.ejb.plugins.CallValidationInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.EntityCreationInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.EntityLockInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.EntityInstanceInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.EntityReentranceInterceptor</interceptor> • <interceptor>org.jboss.resource.connectionmanager.CachedConnectionInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.EntitySynchronizationInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.cmp.jdbc.JDBCRelationInterceptor</interceptor> • </container-interceptors>

  9. Cross-cutting Concern • <container-configuration> • <container-name>Standard CMP 2.x EntityBean</container-name> • <container-interceptors> • <interceptor>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.TxInterceptorCMT</interceptor> • <interceptor>org.jboss.ejb.plugins.CallValidationInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.EntityCreationInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.EntityLockInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.EntityInstanceInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.EntityReentranceInterceptor</interceptor> • <interceptor>org.jboss.resource.connectionmanager.CachedConnectionInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.EntitySynchronizationInterceptor</interceptor> • <interceptor>org.jboss.ejb.plugins.cmp.jdbc.JDBCRelationInterceptor</interceptor> • </container-interceptors> Extract Aspects Extract Aspects

  10. Interceptors to Aspects • Aspectizing JBoss seemed like logical next step • Leverage pointcut expressions • Bring J2EE a la cart to plain Java • Leverage our existing interceptor design

  11. J2EE a la carte

  12. Transaction Demarcation • Transaction demarcation (method, field, constructor) • You can specify transaction boundaries within code • Tags can transparently interact with Transaction Manager • Begin, suspend, commit and rollback transactions • On method, field, or constructor execution • EJB adjectives used to specify transactional behavior • Required, RequiresNew, Supports, Never, NotSupported, Mandatory • Complete control over when a rollback is triggered • i.e. which thrown exceptions cause a rollback

  13. Transaction Demarcation • Annotations or XML metadata can specify annotation @Tx(TxType.REQUIRED) public void somepojoMethod() { … } • <metadata tag="transaction" class="org.jboss.test.POJO"> • <method name="somepojoMethod“> • <value>RequiresNew</value> • </method> • </metadata>

  14. Roled-based Security • Secured access to any method, field, or constructor • Only users of a certain role allowed to access • Authentication/Authorization integrated with JBoss Security • Various Security Domains (LDAP, RDBMS, SRP, etc…) • Access to username available within other interceptors

  15. Role-Based security JDK 5.0 Annotations are usable • @SecurityDomain(“other”) • public class POJO { • @Unchecked public POJO() {} • @Exclude public exlucedMethod() {…} • @Permissions({“admin”, “manager”}) • public void someMethod() {…} • @Permissions({“user”}) • public static int status; • }

  16. Role-Based security XML metadata can specify annotation • <metadata tag="security" class="org.jboss.test.aop.bean.SecuredPOJO"> • <security-domain>other</security-domain> • <method-permission> • <role-name>allowed</role-name> • <method><method-name>someMethod</method-name></method> • </method-permission> • <constructor-permission> • <unchecked/> • <constructor><constructor-params/></constructor> • </constructor-permission> • <exclude-list> • <description>Methods that connect be used</description> • <method> • <method-name>excluded</method-name> • </method> • </exclude-list> • </metadata>

  17. Metadata

  18. Metadata • J2EE a la carte examples show importance of metadata • Pointcut expressions aren’t always the silver bullet • Can be confusing to developers • Developers want simple, familiar ways of applying aspects • Some developers like annotations • Others prefer XML to externalize configuration • An AOP framework needs to be aware of both.

  19. Metadata • JBoss AOP requirements • Support annotations in pointcut expressions • Support annotation overrides at runtime • Support untyped metadata • Support metadata/annotation defaults • Support XML externalization of metadata • Allow metadata/annotations to be attached without modifying bytecode • Metadata changeable on a per-deployment basis through XML • Allow pointcut expressions to be aware of this attached metadata.

  20. Dynamic Metadata • Aspects can resolve metadata dynamically • The AOP Invocation object (ThisJoinPoint) gives hooks for this. • Metadata can be attached to a invocation and propagated • Aspects can pass information to one another locally or remotely • Metadata can be overridden on a per Thread basis • Change behavior per Thread • Provide simple mechanism to clear all Thread metadata (Thread Pooling) • Default values can be defined/managed per VM or per Cluster Invocation Thread Class VM Cluster

  21. EJB 3.0 and JBoss AOP An aspect-oriented EJB container

  22. EJB 3.0 and JBoss AOP • Can EJB be implemented using AOP? • “Traditional” AspectJ like weaving not possible • EJB is a proxy architecture by definition • proxy.someMethod() different behavior than this.someMethod() • Same class can be deployed in multiple containers • Mix/match of XML and Annotations • JBoss 3.x and lower showed AOP was the right approach • A Proxy-based AOP container was needed.

  23. EJB 3.0 and JBoss AOP • JBoss AOP binds aspects at class load time • Since binding is java.lang.reflection based • Very easy to create a proxy container a.k.a an EJB container Server JVM AOP Container RemoteInvoker Port 1234 Client JVM Typed Interface Invocation JBoss Remoting AOP Container Client RemoteInvoker 011101010101 Port 4321 Client Proxy

  24. EJB 3.0 and JBoss AOP • Why re-architect within an AOP Container? • Full pointcut expressions available • Per method advice chains • Pluggable annotations • Pluggable behavior • Reuse existing Aspect Library • Remember? • If middleware is easy to use… • …it should also be easy to extend • AOP allows us to easily extend EJB behavior

  25. EJB 3.0 and JBoss AOP • The next issue: • EJB Containers have similar, but different aspects • Stateless, Stateful, MDB (and JBoss extensions) • Proxies to these container types also similar but different • Needed a way to define a template for each of these types • Needed a way to define a template for proxy definition • Solution: • JBoss AOP “Aspect Domains”

  26. Aspect Domains • Advice Stacks: • Named chain of unbound advices • Proxies use these to understand what their advices should be • Aspect Domains: • Define a set of pointcuts, metadata overrides, and advice bindings • Containers reference domains for their advices • Domains can inherit from one-another

  27. Advice stacks • Containers reference advice stacks when they create proxies • Stacks are predefined and configurable • <stack name="SessionBeanClientInterceptors"> • <interceptor-ref name="org.jboss.aspects.remoting.IsLocalInterceptor"/> • <interceptor-ref name="org.jboss.aspects.security.SecurityClientInterceptor"/> • <interceptor-ref name="org.jboss.aspects.tx.ClientTxPropagationInterceptor"/> • <interceptor-ref name="org.jboss.aspects.remoting.InvokeRemoteInterceptor"/> • </stack>

  28. Aspect Domains • <domain name="Stateless Bean"> • <bind pointcut="execution(* @org.jboss.ejb3.security.SecurityDomain->*(..))"> • <interceptor-ref name="org.jboss.ejb3.security.AuthenticationInterceptorFactory"/> • <interceptor-ref name="org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorFactory"/> • </bind> • <bind pointcut="execution(* @javax.ejb.RunAs->*(..))"> • <interceptor-ref name="org.jboss.ejb3.security.RunAsSecurityInterceptor"/> • </bind> • <bind pointcut="execution(* *->*(..))"> • <interceptor-ref name="org.jboss.ejb3.stateless.StatelessInstanceInterceptor"/> • <interceptor-ref name="org.jboss.aspects.tx.TxPropagationInterceptor"/> • <interceptor-ref name="org.jboss.ejb3.tx.TxInterceptorFactory"/> • </bind> • <annotation expr="!class(@org.jboss.ejb3.PoolClass)"> • @org.jboss.ejb3.PoolClass (value=org.jboss.ejb3.ThreadlocalPool.class, maxSize=30, timeout=10000) • </annotation> • </domain> Annotations with behavior Default advices Annotation Override

  29. Dynamic AOP Transparent caching

  30. What is Dynamic AOP ? • Hot-deployment of aspects • Bind/unbind advices arbitrarily at runtime • Per-instance AOP • Add advices on a per instance basis

  31. What is JBossCache ? • Transparent caching • Local or replicated • Synchronous or asynchronous replication (using JGroups) • Transactional or non-transactional • Transactional • Replication at TX commit • DB isolation levels supported • Support for pluggable TxManagers • Non-Transactional • Replication after each modification • Pluggable eviction policies • Ships with time-based and size-based (LRU) policies • Cache loader • Persistent backend store (load - store)

  32. AOP Cache • Work with POJOs public class Person { String name=null; int age=0; Map hobbies=null; Address address=null; Set skills; List languages; public String getName() { return name; } public void setName(String name) { this.name=name; } ...} public class Address { String street=null; String city=null; int zip=0; public String getStreet() { return street; } public void setStreet(String street) { this.street=street; } ...}

  33. Interaction With Cache • tree = new TreeCacheAop();config = new PropertyConfigurator();// configure tree cache.config.configure(tree, "META-INF/replSync-service.xml");joe = new Person();joe.setName("Joe Black");joe.setAge(31);addr = new Address();addr.setCity("Sunnyvale");addr.setStreet("123 Albert Ave");addr.setZip(94086);joe.setAddress(addr); Use Pojos as Pojos

  34. Interaction With Cache • Joe’s state is automatically transactional and replicated • State replicated, synchronized at transaction commit/rollback • tree.start();  // kick start tree cachetree.putObject("/aop/joe", joe); // add aop sanctioned object • tx.begin();joe.setAge(41);joe.getAddress().setZip(95124);tx.commit();

  35. Demo JBossCache

  36. How does it work? • Classes must be prepared for field interception • This preparation creates AOP hooks • Any advice can be added where hooks are instrumented <?xml version="1.0" encoding="UTF-8"?> <aop> <prepare expr="field(* $instanceof{org.jboss.test.cache.test.standAloneAop.Student}->*)" /> <prepare expr="field(* $instanceof{org.jboss.test.cache.test.standAloneAop.Address}->*)" /> <prepare expr="field(* $instanceof{org.jboss.test.cache.test.standAloneAop.Person}->*)" /> </aop>

  37. How does it work? • Uses reflection to discover the structure of a POJO • Requires a jboss-aop.xml to declare user-defined class to be “advisable“ • Uses AOP to keep track of changes to a POJO • putObject() breaks an object apart and maps it to the TreeCache • Primitive fields are mapped to entries in a node's attributes • Complex fields are mapped to child nodes (recursively) • Transparent handling of object hierarchies • No need for one-to-one, one-to-many, etc relationship declarations • POJO inheritance hierarchy is preserved • We dynamically add a field advice to each complex object to keep track of state changes

  38. JBoss Cache - Advices • Each advice remembers the node to which it maps • On field read: advice returns the value from the TreeCache • On field write: advice updates the associated node's attributes, e.g. • person.getAddress().setCity("San Jose“) generates a put("/322649/addr", "city", "San Jose") • On TX commit: modified fields are replicated and written back to the POJO

  39. JBoss Cache - Design • Cache design itself can aspectized • Cache Aspects • CacheLoader, cache persistence • Replication • Transactionality • Cannot aspectize using class-level weaving • Same classes but configured differently per instance • Aspects can only be assembled if AOP framework support Dynamic AOP

  40. JBoss Strategy • Middleware is the perfect application of AOP • Transparency • Flexibility • Annotations for ease of use • AOP for ease of extension

More Related