Enterprise Object Broker

Overview

Welcome to the post-J2EE era. This open source application server cherry picks the best from J2EE (Servlets) and completely ignores the arguable worst (EJB).

Memes

What is Enterprise Object Broker? Think of it as one of these:

A bean server with transparent distribution for Java objects via their interfaces.
A simpler alternative to EJB; or EJB-lite
A bean server that uses .Net style remoting for Java (remotable Java beans instead of EJB).

Tell me more...

It is like EJB in that it has beans and supports remote access, but has a few differences:

EOB does not use RMI concepts in its interface definitions. It uses normal Java interfaces and normal Java objects.

It has nothing to do with CORBA or RMI (or the intersection of both of those - RMI-IIOP)

There is no distinction between 'local' and 'remote' objects. The developer does not have to consider whether the bean would be used locally or remotely. AltRMI is used to connect beans locally and remotely.

JNDI does not have to be used for lookup of other 'things'.

It has lifecycle methods/concepts along the lines of 'Inversion of Control' (IoC) pattern.

No formal definitions of 'Home' interfaces and methods.

No formal definitions of 'Entity' and 'Session' beans and methods.

Hosted bean applications do not need to implement or extend any EOB interface or classes.

The default implementation runs on top of Apache's Avalon-Phoenix server framework along side other server applications.

This is a level closer to normal class models than EJB is.

When would you use this?

As with any three-tier application server, you would use it when you have a proven need for RPC. If you are considering a J2EE container, commercial or not, you might want to consider EOB instead.

Note - If you don't have a proven need for RPC, you should make an application that entirely exists in a WAR file and runs happily (threads and all) inside a servlet container. This does scale - if you can use an affinity based load balancer. This is common advice now.

Demo apps

Entperprise Object Broker's demo applications are hosted from time to time at http://demo.enterpriseobjectbroker.org:8080

What does this mean for you?

You can model using normal Java interfaces. Use multiple inheritance in the interface definitions if you want.
Your implementing objects can share inheritance too. Divide the functionality of your solution in to a tree of classes as you see fit. ..........

Interface ( no more no less, if that is what you want ) -

interface StockQuoteService {
BigDecimal getLastSalePrice(String stockCode);
}

Server-side impl ( no more no less, if that is what you want ) -

class DefaultStockQuoteService implements StockQuoteService {
BigDecimal getLastSalePrice(String stockCode) {
return new BigDecimal(Math.random);
}
}

Server-side use in another bean, local or remote ( no difference ) -

class SomeBeanImpl implements SomeBean, Serviceable {
private StockQuoteService mStockQuoteService;
public void service(ServiceManager sm) throws ServiceException {
    mStockQuoteService = (StockQuoteService) sm.lookup("MyStockQuoteService");
}
void someMethodOrOther() {
BigDecimal sunwLastSale = mStockQuoteService.getLastSalePrice("SUNW");
// etc.
}
}

Sample client side usage, in another VM or another machine -

class SomeMainable {
public static void main(String[] args) throws Exception {
    Factory factory = new ServerSideClassFactory(false);
    factory.setHostContext(new SocketCustomStreamHostContext("somemachine.com", 7124));
    StockQuoteService sqs = (StockQuoteService) factory.lookup("MyStockQuoteService");
System.out.println("Sun's last sale price was " + sqs.getLastSalePrice("SUNW"));
System.out.println("Microsoft's last sale price was " + sqs.getLastSalePrice("MSFT"));
  }
}

A manifest for the bean -

<?xml version="1.0"?>
<beans-info>
<bean-info name="MyStockQuoteService" facade="StockQuoteService" impl="DefaultStockQuoteService">
</bean-info>
</beans-info>

A manifest for the whole application -

<?xml version="1.0"?>
<application-info>
<publish-info type="SocketCustomStream" bind-to="somemachine.com" port="7129"/>
</application-info>

Whether you are using JDBC of file based XML for storage is your business, though we will provide reference implementations The design of any cluster and which beans go where can be decided after development, by the team deploying the application. You'll note that there are no EOB classes to extend or EOB interfaces to implement.

What is this Avalon-Phoenix thing?

It is an application framework that can host multiple other servers within the same virtual machine. In the same way that a bean can lookup other beans, it can lookup a webserver (Jetty) that it can then use for publication of web-applications. Other Phoenix hosted applications are JAMES (a mail server) at Apache, JabberServer (unsurprisingly a Jabber instant messaging server) and others.

Avalon-Phoenix takes server application distributed in "Sar" form. This is like Jar but for server applications. In the case of EOB, the sar contains the EOB server but no application beans to run. The application beans come in .EOB files (se below)

EOB files

EOB files are similar in concept to EAR files for EJB. They contains jars which are beans, some manifests to tell Enterprise Object Broker what is to be done. An EOB file may also contain an WAR file if it is going to mount web-applications.

Examples

Please read our requirements page if you are interested in compiling EOB or running it.

See Examples for the examples that come with EOB.

Downloads

See Downloads for a comprehensive list of downloadables.

$Revision: 1.47 $ $Date: 2003/10/14 16:41:17 $