J2EE Marketplace

advertisement
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
Download