Transcript J2EE Marketplace - Middleware 2003

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 ([email protected].)
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