JBoss Bridging academia and industry through Open Source JBoss™ : A Few Facts JBoss 3. is an application server based upon J2EE 1.3 • LGPL (Lesser GPL) licence: JBoss use is FREE • A standard in the market – 2 million downloads in 2002 – Over 1 million downloads in first 4 months ’03 – 70% of JBoss users use it in production (Java Developers Journal poll/May ’03) JBoss™ : A Few Facts • Quality – JavaWorld Editors’Choice Award as best Java Application Server in 2002, beating BEA Weblogic and IBM Websphere – SDTimes 10 top innovators – Few bugs in production, Open Source – Academia involvement • Fully supported by JBoss Group JBoss Group Overview • JBoss Group was founded by Marc Fleury and Scott Stark in 2001 to provide supporting services around the FREE JBoss application server. • The company brings together the core developers of JBoss to form a new type of open-source consultancy, offering an unmatched « Back Office » operations model, where expert developers spend – 50% of their time in development – 50% of their time providing services • Manpower: – Employees: 2(‘01), 7(‘02), 30(‘03) – Developer community (RW passwords): 30(‘01), 50(‘02), 80(‘03) • Profitable, self-funded “pay as you grow” strategy, with 125% average monthly growth rate (at a standard deviation of 428%) CUSTOMERS (the tip of the iceberg) JBoss based on academic work • JBoss includes software developed in academia • java-groups: Bela Ban (Cornell/Fujitsu) – Group communication • javassist: Shigeru Chiba (Tokyo Inst. Tech) – Bytecode engineering • Oswego: Doug Lea – Concurrent package • Jacorb: Gerald Brose (Uni Berlin/Xtradyne) – IIOP engine Academic work is based on JBoss • NRMI: Tilovich, Smaragdakis (Georgia Tech) – Pass by copy- restore semantics • ROC: Candea, Fox, Patterson (Stanford/Berkeley) – Recovery Oriented Computing/ High Availability • GRID: Los Alamos Nat labs – GRID distribution and monitoring • Are you next? – Aspect orientation makes it easy Is JBoss for you? • Rapid prototyping based on JBoss – Give a reference implementation of your research • The market will pick what it wants with Open Source • Give your research a large audience • LGPL requirement JBoss 4.0: Availability • Developer Release: June 2003 • Production Release: Fourth Quarter 2003 • JBOSS 4.0 AN AOP APPLICATION DYNAMIC AOP: MIDDLEWARE NIRVANA? • JBoss 4.0 brings enterprise Java to a broader range of developers, borrowing from framework features of Visual Basic, .NET and CORBA, as well as J2EE, giving them a more intuitive way to interact with the system. • Application developers do not have to worry about system architecture. The system architect can manipulate and integrate legacy/standard Java applications into JBoss 4.0. USES RUNTIME AOP. • JBoss 4.0 combines the simplicity of standard Java with the power of enterprise Java. • GUI used OOP, Middleware uses AOP JBoss 4.0 Architectural overview • Microkernel design – Independent cycling and loading • Hot Deployment of services and applications – Unified ClassLoaders, total Class visibility/cyclability – Service Archives (SARs) for easy configuration and net deployment • AOP-enabled Services – – – – – – Persistence, cache, transactions, acidity, remoteness, security Orthogonal aspects weaved in at run time under the objects In use in JBoss since 2.x series Ease of debugging == STABLE Generalized for public AOP consumption in the JBoss 4.x series NO COMPILER, FULL DYNAMIC DESIGN (bytecode engineering) • CONTAINER DESIGN MADE EASY HTTP Grid loading http JBossMX JBossMX Computer 1 Computer 2 File File JBossMX JBossMX Computer 1 Web Server Computer 2 CLASSES Unified ClassLoaders • Shared classes and cycling of classes Deployer REPOSITORY JBossMX JBossAOP a new generation • System level aspects are by definition cross cutting to the applications (they are in fact orthogonal aspects). • Use Java, straight java and some XML • Define pointcuts easily – Either XML in class (useful for persistence, JSR 175) – Either XML in logical scope (e.g. instance (acidity, locking), class, application (security), VM (monitoring), cluster (ROC)) – Context based constructs are possible, thread association (Observer/Observable, READ-AHEAD) – DYNAMIC AOP ENABLES COMPLETE OBLIVION use of Advisable interface for cache, NO user input Fields, Methods, and Constructs public class POJO { private int privField; public float pubField; public static String pubStaticField; public POJO() {} public void somemethod() { privField = 10; } } Public class POJORef { { POJO p = new POJO(); p.pubField = 5; p.somemethod(); } } Pluggable CrossCutting Functionality • New behavior can be attached by writing a simple Interceptor class and inserting it into the chain of invocation Caller Tracing Monitoring Implements Advisable DYNAMIC! POJO Observer Notifications Metrics • POJO Orthogonal interceptors Aspect orientation Aspect Oriented Programming DESIGN Interceptors • • • • • Implement the org.jboss.aop.Interceptor interface Invocation object encapsulates method args or field values Hold reference to interceptor chain Driver of interception Resolves metadata public interface Interceptor { public String getName(); public InvocationResponse invoke(Invocation invocation) throws Throwable; } Metadata and Metatags • • • • • XDoclet and JSR-175 Metatags can define pre-packed Aspects Pluggable Java language keywords AOP is the glue Required interceptors automatically added when keyword applied /** * * @jboss-aop.metadata group=“transaction” trans-attribute=“RequiresNew” */ public void somePOJOmethod() { … } Dynamic API • Every POJO filtered through AOP has an extended interface • At classloading time, bytecode manipulation forces AOP POJOs to implement a standard AOP interface. • AOP interface allows you to define Instance-level metadata • Allows you to insert interceptors for a particular instance at runtime { POJO p = new POJO(); Advised obj = (Advised)p; //Typecast obj.insertInterceptor(new MetricsInterceptor()); … } AOP for Middleware • AOP simplifies applications with high degrees of reuse of cross-cutting concerns • Application Servers by definition provide cross-cutting SYSTEM-LEVEL aspects • Middleware is thus a perfect fit for AOP • The middleware aspects are themselves the killer application of AOP JBoss 4: Pre-packaged Aspects • J2EE a la carte, EJB like but no EJB API – Transaction demarcation – Role-based Security – Remoting – choose at runtime, SOAP, RMI, Sockets, IIOP – Clustered Remoting – invocation failover • Beyond J2EE – Transactional, ACID, Objects. Our Transactional Cache – Replicated Objects. Our Distributed Cache – Transctional Locking. Expanded Java “synchronized” • Persistence – JBossDO – JDO on JBoss J2EE a la carte /** * @jboss-aop.metadata group=“transaction” trans-attribute=“RequiresNew” */ public void somepojoMethod() { … } /** * @jboss-aop.permission role-name="Administrator,Tester" */ public void securedPojoMethod {…} Remoting • • • • Declare POJO remoted at runtime, as in .NET REMOTE Hooks into JBoss Remoting project (Jeff Haynie, Tom Elrod) URI based protocols (soap, socket, rmi) ONE WAY >>> JMS + MDB from a development standpoint // Server POJO remote = new POJO("hello"); Dispatcher.singleton.registerTarget(“objName", remote); // Client POJO proxy = (POJO)Remoting.createRemoteProxy(“objName", POJO.class, “soap://localhost:8080"); Clustered Remoting • Invocation failover with any protocol POJO pojo = new POJO("hello"); POJO proxy = (POJO)ClusteredRemoting.registerClusteredObject( “objName", pojo, "DefaultPartition", new RoundRobin(), “socket://localhost:5150"); Interceptors for clustering Client side proxy for clustering package org.jboss.invocation.jrmp.interfaces; /** * * JRMPInvokerProxy, local to the proxy and is capable of delegating to local and JRMP implementations * <p><b>2002/04/08: Sacha Labourey</b> * <ol> * <li>Pass a value with the invocation that allows any server side interceptor to know * when a call result from a failover (and the number of tries)</li> * </ol> */ The HA version contains a public class JRMPInvokerProxyHA extends JRMPInvokerProxy implements Externalizable list of invokers { // Public -------------------------------------------------------protected ArrayList targets = null; protected LoadBalancePolicy loadBalancePolicy; protected transient long currentViewId = 0; public static final HashSet colocation = new HashSet(); Client side proxy for clustering public Object getRemoteTarget() { if (targets.size() == 0) { return null; } synchronized (targets) { return loadBalancePolicy.chooseTarget(targets); } } /** * Returns wether we are local to the originating container or not. */ public boolean isLocal(Invocation invocation) { return colocation.contains(invocation.getObjectName()); } Pluggable load balance policies are responsible for picking the target Client side proxy for clustering public Object invoke(Invocation invocation) throws Exception { // we give the opportunity, to any server interceptor, to know if this a // first invocation to a node or if it is a failovered call int failoverCounter = 0; invocation.setValue ("FAILOVER_COUNTER", new Integer(failoverCounter), invocation.AS_IS); // optimize if calling another bean in same EJB-application We still collocate if if (isLocal(invocation)) { we are local return InvokerInterceptor.getLocal().invoke(invocation); } else { // We are going to go through a Remote invocation, switch to a Marshalled Invocation MarshalledInvocation mi = new MarshalledInvocation(invocation); // Set the transaction propagation context mi.setTransactionPropagationContext(getTransactionPropagationContext()); mi.setValue("CLUSTER_VIEW_ID", new Long(currentViewId)); Invoker target = (Invoker)getRemoteTarget(); DEBUG IS EASY! while (target != null) { try { HARMIResponse rsp = (HARMIResponse)((MarshalledObject)target.invoke(mi)).get(); if (rsp.newReplicants != null) { Server piggy-backs setTargets(rsp.newReplicants); information about the currentViewId = rsp.currentViewId; topology } return rsp.response; } // ALL CATCH JUST GOES ON We fail over here by taking a new target catch (java.rmi.ConnectException ce){} and looping on the while (target !=null) // If we reach here, this means that we must fail-over remoteTargetHasFailed(target); target = (Invoker)getRemoteTarget(); failoverCounter++; mi.setValue ("FAILOVER_COUNTER", new Integer(failoverCounter), invocation.AS_IS); } // if we get here this means list was exhausted throw new java.rmi.RemoteException("Service unavailable."); } Transactional Caching • • • • • POJOs become ACID State changes become transactional Done with Field interception Pessimistic cache Snapshot Isolation Version 4 Replicated Cache • Field interception again • State changes queued and replicated at transaction commit • Only fields that have changed are replicated DistributedTxCache cache = new DistributedTxCache(cacheSize, lockTimeoutInMillis, cacheName ); Address address = new Address(“Boston”, “MA”); Person person = new Person(“Bill”, 31, address); Cache.put(“bill”, person); tm.begin(); person.address.city = “Bedford”; person.age = 32; tm.commit(); QED & QA • DYNAMIC AOP BASED REFLECTIVE MIDDLEWARE IS SUPERIOR TO COMPILER BASED MIDDLEWARE GENERATION. • Ease of coding • Ease of debugging • Ease of deployment • Ease of testing • Leads to stable, easy to use Middleware that weaves system aspects. • Intuitive system-developer interface – Is UML the natural UI language to specify pointcuts? – Runtime analysis of application topology enables iterative development. • A new age of SYSTEM-DESIGN? – What system aspects are next? – Try providing a reference implementation for your research as aspect for JBoss – People will test it! Come help us! • • • • • • • TELL US about your work (marc@jboss.org.) Prototype on JBoss Contribute to JBoss Reach millions with your research Be used by millions “All your grad students are belong to us” Join the bazaar without leaving the Cathedral