This week I decided it was about time my organization documented its software stack. By 'software stack' I mean one of those neat diagrams that start at the database layer and build layer on layer until you get to the user interface or browser at the top. I liken it a multi-layer cake. The ones the vendors show always look very neat and fit easily onto a powerpoint slide. The ones us real people prepare are usually more complicated and difficult to represent because we have options, legacy tools, in-house software frameworks, interim standards and the like.
I started with a big current project. The data storage for the system for this project involved two mainframe DBMS technologies and some J EE software so it is pretty well stretching us to provide appropriate technologies and is a good place to start to work out what our target software stack should be.
First of all, it turned out that I did not understand how the mainframe gateway software was working. The gateway technology I had represented in my stack had been replaced two years ago. Then I learnt that that we had moved away from using Enterprise Java Beans (EJBs) in this project and had got heavily into the Spring framework so now were using POJOs and wrapping these in Message Driven Beans (MDBs) to provide a JMS messaging interface between services. Still we succeed to get a generally agreed picture of the current project software stack.
From this I wanted to build a 'target software stack' this would be the architecture for some future major project. Maybe this would not be the next project but a couple years down the track I would be hope to see this approach in a project. To produce the target software stack I took some long term objectives. These were
- to communicate using SOAP to other agencies and across platforms to other services
- to use JDBC and SQL to get data from our (non-relational) mainframe databases and move the legacy business logic into J EE.
The reason behind the second point above is to allow the organisation to move to relational databases (mainframe or midrange) at some future time.
The Swing thing bothered me a bit. We have big integration challenges and I want to push forward with Web Services but my developers want to use Swing which offers more efficient messaging between fine grained services. After some googling and reading I have decided that a Swing approach seems compatible with Web Services. Swing provides a good declarative style using XML. The developers can continue to use their POJOs and MDBs for the finer grained services to avoid the overhead of SOAP messaging but for the courser grained services, and particularly werecommunication with other organisations is concerned, Web Service and SOAP is the appropriate standard.
One news item that gave me some optimism was the announcement of Spring Web Services 1.0 two days ago in SOA World. I am glad to read the Spring will support Web Services and therefore make the above approach more common.
So in our target stack we have (from the user interface at the top of the cake)
Internet Browser over HTTP
AJAX (for rich client – may be optional for some projects)
UDDI (for service discovery – we have not got this yet)
LDAP (authentication)
Audit Tool (we have not got this yet but it is important of us)
WS-* (as required), Spring, SOA Discipline (I have called this level 'advance structure' for want of a better term)
WSDL, SOAP (Course grained services)
POJO, MDB, JMS (Fine grained services)
J EE
Hibernate, Oracle (Relational Data)
JDBC, SQL Adapters, ADABAS, IDMS (Legacy Data)
That is the target anyway. It will change before we hit it, but the organisation needs a target even if it is only a straw man to be ripped apart and put back together in new and better ways. The exercise of defining this has been useful and helped me talk with developers and architects about what we are doing today and plan to do tomorrow.
Reference
SOA World Magazine News Desk, SOA World - Spring Web Services 1.0 Launched,
http://au.sys-con.com/read/419023.htm
No comments:
Post a Comment