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...
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...
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...
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"
*
*/
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"
*
*/
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
That is, while there is value in the items on the right, we value the items on the left more.
The key principles of Agile methodologies include things like:
- Customer satisfaction through rapid, continuous delivery of functional software
- Working software, not documentation, is the principal measure of progress
- Change is welcomed
- Close, face-to-face daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Continuous integration of source code changes
- Simplicity
- Self-organizing teams
- Regular adaptation to changing circumstances
- Test driven development
Agile methodologies are in general suited to small teams of senior developers with rapidly changing requirements and an end user. Some work has been done to apply Agile on the larger scale but in general the larger the scale and number of interworking groups, the less agile is applicable "to the whole".
The last phrase is key, because certainly there is no issue with organising service development teams in an Agile manner, however Agile as a methodology for delivering enterprise SOA is surely inappropriate?
SOA is highly planned, requires a defined architectural and organisational framework in which to operate, needs lots of up front business modeling to help drive service requierments, needs formally defined and well-documented contracts, needs formal rigorous change management, and finally some measure of stability because of the cost of change to clients.
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
That is, while there is value in the items on the right, we value the items on the left more.
The key principles of Agile methodologies include things like:
- Customer satisfaction through rapid, continuous delivery of functional software
- Working software, not documentation, is the principal measure of progress
- Change is welcomed
- Close, face-to-face daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Continuous integration of source code changes
- Simplicity
- Self-organizing teams
- Regular adaptation to changing circumstances
- Test driven development
Agile methodologies are in general suited to small teams of senior developers with rapidly changing requirements and an end user. Some work has been done to apply Agile on the larger scale but in general the larger the scale and number of interworking groups, the less agile is applicable "to the whole".
The last phrase is key, because certainly there is no issue with organising service development teams in an Agile manner, however Agile as a methodology for delivering enterprise SOA is surely inappropriate?
SOA is highly planned, requires a defined architectural and organisational framework in which to operate, needs lots of up front business modeling to help drive service requierments, needs formally defined and well-documented contracts, needs formal rigorous change management, and finally some measure of stability because of the cost of change to clients.
Wednesday, 29 October 2008
Tuesday, 28 October 2008
Migrating Weblogic to JBoss (2)
Hmmm, I may have spoken a tad early.
The XSLT scripts I found only translate the very basic deployment descriptor elements. The remaining elements are usually of the vendor-specific performance optimisation type which often don't have a 1-1 equivalent, if they have one at all.
The JBoss community forums are very quiet on these fronts. Perhaps there is a conspiracy to drive me to JBoss.com's migration programme...
Grumble.
The XSLT scripts I found only translate the very basic deployment descriptor elements. The remaining elements are usually of the vendor-specific performance optimisation type which often don't have a 1-1 equivalent, if they have one at all.
The JBoss community forums are very quiet on these fronts. Perhaps there is a conspiracy to drive me to JBoss.com's migration programme...
Grumble.
Thursday, 23 October 2008
Migrating Weblogic to JBoss (1)
This is the first in a series of posts on the joys of migrating our JEE application from Weblogic to JBoss. Being JEE it should be trivial right? ;-)
The steps so far...
J(2)EE rocks and vendor extensions don't! Fortunately our app was built with portability in mind so it should have been this easy. Porting was an interesting exercise and much nicer than Powerpoint architecture for a change.
Initial JBoss impressions? Very favourable (apart from the imperfect documentation).
Now I have to get a cluster running and test messaging, but a cup of coffee beckons. first.
P.S. Happy to share some of the details with you if you email me
The steps so far...
- Stripped out a couple of EJBs from our application to port as a POC
- Jboss download from jboss.org and installation was very quick and painless.
- Read some of the documentation which is fairly good, and fine when supplemented with Google, but not as good as Weblogic's
- JBoss runs pretty much out of the box and is very quick. Needs Sun JRE - it didn't like JRockit (which is bundled with Weblogic)
- Setup Oracle datasources (non XA for now) and message queues and topics. Found the documentation clear as mud and had to get help from examples
- Rebuilt our JEE application against the Sun JRE and JBoss EE library and found that we were using some Weblogic classes. No more.
- Found a free set of XSLTs to transform our Weblogic EJB deployment descriptors to JBoss. Worked mostly but needed some manual tweaking. I'll fix the XSLTs sometime.
- Dropped our application EAR in to the deploy folder
- Started JBoss
- Removed the CreateException from our MDB ejbCreates. JBoss complained rightly that these violated the EJB spec and even gave the section number! How cool is that?
- Changed the JNDI properties in our application configuration files
- Application deployed pretty much first time which surprised me no end
- Ran a little test and got some cryptic SQL error (Invalid scale size. Cannot be less than zero) which after much hunting turned out to be an Oracle-Sun JDBC incompatibility issue resolved by using -Doracle.jdbc.J2EE13Compliant=true on the server
- And that was pretty much it folks!
J(2)EE rocks and vendor extensions don't! Fortunately our app was built with portability in mind so it should have been this easy. Porting was an interesting exercise and much nicer than Powerpoint architecture for a change.
Initial JBoss impressions? Very favourable (apart from the imperfect documentation).
Now I have to get a cluster running and test messaging, but a cup of coffee beckons. first.
P.S. Happy to share some of the details with you if you email me
Service Characteristics - Contract based
Software in general is required to conform to a defined functional interface, and services are no different in this respect. For example, web service interfaces defined in WSDL (Web Service Definition Language) allow the definition of data types, input and output messages, operations, invocation protocols, and even the location of services. WS-Policy may be additionally used to define additional elements of the interface such as security policies.
Interfaces are however very weak on the behavioural aspects (semantics) of services. A service could return structurally correct data to a consumer but still not meet its functional obligations. Ensuring that services satisfy the behavioural contract is best done through automated test suites in my experience. Perhaps one day we will be able to define pre- and post-conditions and have these verified by the service management software but I wouldn't hold your breath.
In addition to functional obligations, services also have operational obligations both the consumers but to their operators. In other words service contracts are much more like SLAs and OLAs than traditional functional interfaces.
Contracts should ideally be kept in the service registry/repository, and where possible in a machine readable format to be used by service management software to help enforce the contracts at runtime.
Of course such runtime enforcement of contracts comes with a performance penalty, but lets not spoil a lovely ideal with picky details... ;-)
Interfaces are however very weak on the behavioural aspects (semantics) of services. A service could return structurally correct data to a consumer but still not meet its functional obligations. Ensuring that services satisfy the behavioural contract is best done through automated test suites in my experience. Perhaps one day we will be able to define pre- and post-conditions and have these verified by the service management software but I wouldn't hold your breath.
In addition to functional obligations, services also have operational obligations both the consumers but to their operators. In other words service contracts are much more like SLAs and OLAs than traditional functional interfaces.
Contracts should ideally be kept in the service registry/repository, and where possible in a machine readable format to be used by service management software to help enforce the contracts at runtime.
Of course such runtime enforcement of contracts comes with a performance penalty, but lets not spoil a lovely ideal with picky details... ;-)
Subscribe to:
Posts (Atom)
