Wednesday, 12 November 2008

Migrating Weblogic to JBoss (4)

Ok, so now you have some fairly respectable, though not yet perfect, style sheets, but how do you apply them to hundreds of deployment descriptors, potentially repeatedly as you refine the stylesheets?

Ant, is the simplest answer. Ant is widely used to build and deploy J(2)EE applications and includes a very hand XSLT task which fits the bill perfectly. For .Net-ers, there is NAnt

For example...

Share:

Thursday, 6 November 2008

Migrating Weblogic to JBoss (3)

My XSLT skills are coming on pretty nicely, but the real battle in all of this is finding equivalent features for those Weblogic application server specifics that we've used. So far I've been able to map most features 1-1 between the respective deployment descriptor files, but today I encountered one that doesn't fit this pattern. In Weblogic, entity-cache is in the weblogic-ejb-jar.xml, whereas in JBoss its equivalent is in the jbosscmp-jdbc.xml not jboss.xml, so XSTL becomes tricky.

I'm also pondering moving to XDoclet since it would allow us to maintain one source going forward and still target multiple application servers, but that would mean redoing all our Weblogic descriptors and involves some element of risk, particularly as I'm not certain all the features we use are covered by XDoclet.

If you've not used XDoclet before, it allows one to embed deployment configuration within Java and then generate XML deployment descriptors using an Ant task. For example see below (notice the use of @ejb, @jboss, @weblogic and @websphere tags.) An additional benefit of this approach is it enables one to see clearly which open and which app server specific JEE features are being used.

/**
* This is a teller bean. It is an example of how to use the XDoclet tags.
*
* @ejb.bean name="Teller"
* description="Teller example bean"
* jndi-name="ejb/bank/Teller"
* type="Stateless"
*
* @ejb.ejb-ref ejb-name="Account"
* ref-name="ejb/bank/Account"
*
* @jboss.ejb-local-ref ref-name="File"
* jndi-name="blah/File"
*
* @ejb.ejb-ref ejb-name="Customer"
*
* @ejb.security-role-ref role-link="Administrator"
* role-name="admin"
*
* @ejb.permission role-name="Teller"
* @ejb.permission role-name="Administrator"
*
* @ejb.transaction type="Required"
* @ejb.transaction-type type="Container"
*
* @ejb.resource-ref res-auth="Container"
* res-name="jdbc/DBPool"
* res-type="javax.sql.DataSource"
*
* @jboss.resource-ref res-ref-name="jdbc/DBPool"
* resource-name="MyDataSourceManager"
*
* @jboss.container-configuration name="Standard Stateless SessionBean"
*
* @jboss.ejb-ref-jndi jndi-name="ejb/bank/Account"
* ref-name="bank/Account"
*
* @weblogic.pool initial-beans-in-free-pool="1"
* max-beans-in-free-pool="3"
*
* @weblogic.stateless-clustering stateless-bean-call-router-class-name="Whatever"
* stateless-bean-is-clusterable="True"
* stateless-bean-load-algorithm="Whazzup"
* stateless-bean-methods-are-idempotent="Sure"
*
* @websphere.bean timeout="239"
*
*/
Share:

Wednesday, 5 November 2008

Agile SOA?

SOA promises business agility, so the question naturally arises whether Agile methodologies (as in XP, Scrum etc) are better suited to SOA development than more traditionaly (albeit iterative) methodologies such as RUP.

If you're not familiar with Agile principles you've probably been marooned on an island somewhere. Agile is the slated answer to the software development crisis. To quote the Agile Manifesto (http://www.agilemanifesto.org/principles.html):

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

Share: