porting from jboss?

brad4d,
We see a lot of this type of thing, and help customers in making the migration, so we have built up experience along these lines. Below are some of the types of things we do....

Migrating a J2EE (EJBs) application

Session beans:

1. Package the business interface (business delegate component) and the bean class in a jar.
2. Create a component definition xml to expose the component (all or specific interface methods)
3. Create a fabric application descriptor
4. Package the component defn., fabric appln defn, and jar in the .fabric file using fabric_pkg.
5. Deploy the fabric file.

Entity beans:

1. Entity beans could be used as domain objects (Java beans with getters/setters).
2. Entity Manager (and related code) could turn into plain Data Access Objects. Jar up these classes.
3. Create a component definition xml to expose the component (all or specific interface methods)
4. Create a fabric application descriptor
5. Package the component defn., fabric appln defn, and jar in the .fabric file using fabric_pkg.
6. Deploy the fabric file.

If you have custom code in any lifecycle callback methods and interceptors that is weaved in by the application server, this code could weaved in via AspectJ AOP (or Spring AOP) with minimal code changes. For example, @PostConstruct (EJB3) would be replaced with either @AfterReturning (AspectJ or Spring AOP).

Any object/resource dependencies that are injected in a Session/Entity/Message bean by the application container can be easily configured to be injected via Spring (if you are using Spring DI) or some other custom dependency injection framework in the business/data/message objects in the fabric.

Migrating a web application (war)

1. Assuming you are following a MVC design, the business delegates and DAOs would get deployed in the fabric i.e. package the jars containing these classes in the .fabric file.
2. Create a component definition xml and fabric application descriptor.
3. Package the component defn., fabric appln defn, and jar in the .fabric file using fabric_pkg.
4. Deploy the fabric file.

Presentation layer:
The View/Controller can remain in the war file on a servlet container such as Tomcat.
In the Controller code (for example, Action sub-class in Struts or Controller sub-class in Spring MVC) you can invoke the interface methods exposed on the fabric in ONE of following 2 ways:

• Using FabricProxyFactoryBean (you will need Spring dependencies) - see "Client Spring Bean XML" section under http://www.appistry.com/developers/wiki/display/eaf39dev/Hello+World+with+Spring+Beans

OR

• Using the IFabric class's execute/submit methods - see "Client Implementation" section under http://www.appistry.com/developers/wiki/display/eaf39dev/Hello+World+with+Process+Flows+and+Tasks

If you choose to use the IFabric class, you will need to create and package a Process Flow definition in the above .fabric file.

In the above approach, I've leaned towards defining the business delegates/DAOs as components rather than tasks .
You could choose to define them as tasks if you so desire. Generally it as simple as creating a task module definition file.

A cleaner approach would be to package the business interfaces and domain objects in jars which can then be included in the war file and in the .fabric file.
Package the business delegate and DAO implementations in jars separate from the business delegate interfaces.

I hope this helps. Please let us know if you have additional questions. We could discuss these offline if you so desire with.

- Rosh

In the approach detailed in my previous post, the war will only contain servlets and jsps. You would deploy the plain Java code (invoked from servlets) onto the fabric (as components described above). And then from your servlets, you would replace the plain Java code method invocation statement with the IFabric's execute/submit methods.

That will not be a problem.
If the servlets currently are invoking methods on custom data access layer, these calls would be replaced with the IFabric execute/submit methods.
If the servlets currently are invoking methods on some Plain Old Java Object that is acting as a facade between the servlet and the custom data access layer, then these calls would be replaced with the IFabric execute/submit methods.

Which version of Tomcat are you using? Presently you could use the session replication feature that Tomcat provides. See http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html.

I would love to say it would take a few hours :) But without looking at your code, I would basically be pulling out a number out of thin air :) On the other hand, we have worked with clients in the past on projects like these and have built prototypes (along with training) in a couple of days.

Hope this helps.

- R