Orchestration vs Choreography?

I was going to write a post on this subject but found an excellent article by Mike Rosen instead.

Job done. :)

What do I put in my registry?

I'll talk later about asset management, but for now, what exactly belongs in a service registry?

Well, services obviously, stupid.

But what about stored procedures? Or legacy, remotely invokeable services? Or batch feeds? Or ETL (Extract Transform and Load)?

I would suggest that the answer to this is "yes". I know there is no fancy XML contract that can be enforced at runtime etc but so what?

SOA is about organising your enterprise as much as anything else, which is why I believe Enterprise Architecture is a pre- or co-requisite to SOA (but that's another rant), and if you are documenting and governing your services (of all types) then you're well on your way to the path of SOA enlightenment.

Standardisation of protocol and interface will follow.

We have a registry!

How exciting. At long last I am a working somewhere with thousands of services, a registry/repository, a service registrar and established governance processes around the use of services.

Could life get any better for an SOA believer?

Yes, because unfortunately some groups have decided that all this stuff is too much bother and have come to a peer-peer arrangement regarding the use of services.

So the registry is inaccurate.

So the whole house of cards collapses in a horrible, useless heap.

You see, reuse like recycling only works if the there are practical as well as ideological reasons for doing it. In this case either the governance was not strong enough, or the populace were not sufficiently bought into the enterprise benefit of SOA. Take your pick.

Lesson? A registry does not an SOA make, whereas an organisation (emphasis on organise) just might have a chance.

Competitive Services

I have been reviewing ITIL 3 with a view to updating my article on Service Management, and came across the notion of competitive services.

This is a very common notion when one looks at services in the usual, non-SOA sense where services are being offered in a market place and have to compete, but does it apply to SOA?

Well, clearly if you are looking at services offered in the internet by companies engaged in Cloud computing and such like, e.g. Google or Amazon, the answer is yes, but what about your typical corporate enterprise landscape?

I think the answer is still yes, but for different reasons.

Outside a corporation you expect multiple service providers to offer similar services, and to compete in terms of functionality, but within a corporation, the whole point of SOA is to eliminate redundancy, so we're not expecting there to me more than one service of any particular kind.

No, within a corporation, services are competing not against each other, but against the old way of building software. There is still a fair bit of resistance out there to the services way of doing software. Its a bit like recycling: wonderful concept in theory, after all who does not want to save the world? But the minute it gets inconvenient for the individual you see it going in the bin, so to speak.

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...

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"
*
*/

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.