Zachman and SOA

I had the benefit today of sitting down with our Zachman zealot and discussing how we were sailing according to this popular architecture framework. Zealots or champions have an important role in introducing any new concepts to an IT shop (see earlier posting on passion of programming). I am to deliver a paper in about a month explaining the role of enterprise architecture in SOA so I thought I better start by asking where our enterprise architecture was at and in particular do this in terms of the Zachman framework.

The Zachman framework is a grid of artefacts used to describe an enterprise architecture. This is illustrated with this posting but is also available from http://www.zifa.com/. I have heard it being referred to by one commentator as a caretaker's key holder. The key holder is a large rack where the caretaker hangs all his or her keys. Zachman does not require the whole grid filled. Nor is it necessary for only one artefact to correspond to each hook. It is therefore a fairly messy key holder. Nevertheless it is pretty handy. It prompts the architects to think about what is needed in a particular grid position. This is put well by Zapthink:

Well, the Zachman Framework has a little secret: few if any enterprises are able to flesh out more than a small handful of the 30 models associated with the boxes in the Framework. Instead, the Framework represents a best case, providing guidance for enterprise architects to tackle different aspects of their organization as the business needs dictate.

While we would not regard our organisation as mature in its enterprise architecture capability we have developed over the last few years. We have something to show for many of positions on the Zachman grid and we are using Telelogic System Architect to store and present some of these artifacts.

I will explain what we have in each of the cells in the Zachman grid. I will first deal with the two rightmost columns 'Time' and 'Motivation'. My organisation has not developed these columns very far. At the scope level there are corporate documents and at the technology level there are some details in project documents but these are not consolidated into an enterprise architecture. If we were doing Event Driven Architecture (EDA) or a business rules based architecture (http://www.businessrulesgroup.org/) we would have more emphasis on these aspects. There is still an advantage for our organization to work in these cells but it is not a priority. At the
business level we have an ends/means model detailing the detailed business rules of what we do. This fits in the "Business Model/Motivation cell. This is a big diagram and adorns a wall in the corridor.

Our approach is to document the top two rows fairly broadly and this is supplemented by project-specific materials in the lower levels. To some extent projects will drive our architectural direction. On the business model level we will often have both broad enterprise documents and specific project business modelling.

At the top 'Scope' row of the Zachman grid we have broad category lists based on the business.
Data: High level information model
Function: Core Business functions as presented in corporate planning documents. (These are not IT documents at all)
Network: Is a list of key locations. Within those locations there may be key organizational groupings.
People: At this level we identify key business roles. This is our starting point to determining security profiles.

The 'Business Model' row gets more detailed. Some of the diagrams at this level adorn the walls of my office.
Data: The enterprise information model gets more detailed and more specific. A number of projects have resulted in information models being provided in detail down to entity level but other modelling remains at a higher level.
Function: This is described by a high level business activity model. This is described as a hierarchy going down three levels. Also here we have a number of documented business process that mostly have been developed for particular projects.
Network: We do not have anything formal in place for this. Zachman suggests we should model business locations and linkages.
People: We need more in this place. I have a few organization charts but our administration of roles needs improvement and we need a better handle on these roles so we can provide appropriate access to our systems. Zachman also suggests a work flow model based on the role hierarchy in this cell.

The 'System Model' row is where we get into our logical design of our systems.
Data: Here we have a logical data model. This is project driven. Our enterprise data model at this stage is just the aggregation of a number of data models created for projects.
Function: This is the application architecture cell where a lot is happening as we move to an SOA. We have not completed our service model yet and most of what is in this space is project driven system models. This is also the space for a number of project specific artifacts such as use cases.
Network: We do not have much of a documented Distributed System Architecture. As our history was legacy mainframe the distributed system architecture was not particularly exciting but the need of this is growing and especially with SOA this architecture becomes more important.
People: Human interface architecture becomes more of a separate issue with SOA. We have a number of project specific documents on human interfaces but adoption of SOA and the push towards a common portal approach should be the incentive to publish something in this space. We have recently put some effort in documenting our application portfolio which is
also important for SOA.

The 'Technology Model' row is where we get or more physcal models of our systems.
Data: Our Data Stores Model is being developed which includes security classification, availability and currency information.
Function: My Zachman zealot advises this is where the software stack belongs. There is also some project activity here which will get consolidated into an enterprise architecture.
Network: We have a number of deployment diagrams which show what applications and parts of applications are deployed onto what hardware. Some of this is on my office wall.
People: Presentation Architecture is still project specific although we do have some user interface standards. Our target Presentation Architecture is likely to involve using a common portal and specific presentation layer technology.

The 'Detailed Representations' are mostly the working artifacts of the architecture:
Data: Database schemas. In the legacy applications we have the Bachman diagrams in the new applications we have ER diagrams and class diagrams. Increasingly with SOA these data definitions are done in XML.
Function: This includes the program code and other low level specification of the program logic.
Network: Network Architecture documentation is available and tends to be specific to a domain. (eg. File and printer server network, midrange network, telephony network, external data connections)
People: Security architecture is evolving. In many cases authentication is done through the one LDAP directory. The organization is still developing this so that it can provide role information as well.

This has been quick look through Zachman key holder. Much of the architecture remains unchanged under SOA. Our enterprise architecture focuses on business processes rather than application silos and this in turn supports SOA. The Application Architecture changes with SOA and many of the architectures and models around it are affected by the choice of SOA. Some logical data modelling may change to support the modelling of the service contracts but the resulting data model is likely to be similar to the one developed conventionally. There is increasing importance in the distributed system architecture and technology architecture as distributed processing becomes much more important in SOA.

Footnotes
The analogy of the key holder is not original I think I owe this to Glenn Smyth of Adelaide Bank

This is not the first time I have come up with a good posting topic only to find the Zapthink has already covered it for me. See also Lego and SOA.

Don't get the staff you deserve, get the staff you need

I am working on a resourcing plan for my branch. The move from legacy mainframe applications to SOA requires new skills and specializations, but we need to maintain some fairly rare legacy skills as well. Here I explore a couple of rational models and tear them down again in order to justify my own approach which I plan to provide in a later posting.

If you are managing a group responsible for software development there are a number of options to accessing personnel to get your software developed. These include:

• Permanent Employment (A salaried employee with can be Full-time and Part-time)
• Term Appointment (Contract to the organisation for a fixed term)
• Personnel Contract (Usually contracted through an agent rather than directly to the organisation)
• Service Level Contract (This is for a particular service such as "keep the database server running within service levels" rather than a chunk of work)
• Work Contract (Contract to deliver a piece of work. This contract might be on a 'fixed price' or 'time and materials' basis)
• Product Purchase (A vendor produces a product, often to specification which is then purchased)

This list is ordered from most tightly bound to the least tightly bound to the organisation. The expectation is that the salaried employee will stay for a number of years, stay after the current project is complete and usually paid for by recurrent funds. A contractor on the other hand is not tightly bond to the organisation. The contractor is expected to be employed for the length of the project and funded capital allocations.

Of course these are expectations. In practice we may have employees who leave after a few weeks and we may have contractors who are essential to the organisation and we keep extending as new projects become available. What is important is that we have the roles in our organisation that will allow it to continue for the long term but we also have sufficient staff to get our current projects done.

How do we decide which are the permanent roles, tightly bound to the organisation and which are the contract roles?

First I will look at some rational ways of doing human resource planning. Imagine we are able to predict our resources requirements for, say the next 10 years. That is stretching the imagination a long way but let us do it for the sake of argument. We would come up with a nice chart with peaks and troughs in our demand for people. There are a number of models we could use for our human resources:

• Staff to meet peak demand. This is more a model for a call centre than a software development shop.
• Use permanent staff to meet the trough of demand (ie steady-state demand) and contractors to meet the peaks.
• Minimize the cost of staffing based on the human resource demand (see footnote).

To minimize the cost of staff we must assume contractors cost more than permanent employees. The contractor should have compensation for not having the benefits of permanent employment. To minimize the cost we must fund a permanent staff level somewhere above the demand trough level. The implication is that it is economical to pay permanent staff to be idle in times of low demand rather than pay a premium to bring in a contractor in more busy times.

This is of course, never the way it works in practice. We can't predict our IT projects very far into the future. The concept of an idle IT professional is foreign to me. There is always maintenance work to do, more enterprise documentation or more skill development to be done. We do not count human resources as simple numbers. There are skills and specialties we need. The costs of our staff and contractors are not uniform and the formula for getting value for what you pay for can be very muddied when you are talking about people and what they can deliver to the organisation.

The big killer for getting in the way of a rational approach is that I have very little discretion over the number of my staff anyway. Governments and many large organisations have fixed FTE limits. Especially for Government it tends to a be vote-winner to promise reduction in the number of public servants and the folks sitting in the back office, like IT staff, not delivering anything directly to the public are often on the agenda for cuts and freezes. The outcome is that we may end up with less staff and more contractors than is rationally based on models like the ones above.

I have to ensure that I have the right permanent roles moving forward. By 'roles' I mean positions. Max Weber has the dubious distinction of inventing the bureaucracy where every person is employed to fill a position. The position has certain duties and requirements. It is these duties and requirements that we described in position document and we try to fit people into these roles. As much as I would just like to get a bunch of talented people together in the expectation they could come up with something wonderful, each position has to be described in detail so that we have all bases covered and this is what has to drive my planning.

Footnote:
I did maths a long time ago but occasionally I like using the formula editor. The total cost of staff for a period of time T is

We minimise TotalCost with respect to the permanent staff level P.

Software Stack Springing from Nowhere

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

Putting a Face to SOA

There seems to be some things missing from much of the discussion on SOA. In a couple of books I've read SOA as touted as an all-encompassing approach to developing systems but issues on data modelling and user interface are almost completely ignored. These are pretty fundamental parts of or software. Early computer systems were nothing but user interface and database. Now there is so much in between such as business logic and middleware that this all needs to be regarded as the most important part of the architecture. So are there recommendations about how to do the data model and user interface in SOA?

Firstly, does SOA affect the logical data model compared with traditional architectures? My answer is that the method of obtaining the data model may be different but I'm not sure whether the resulting data model is any different from traditional methods. The focus has to be on the message format if the development is to be driven WSDL first. I will probably expand on this in later post but for now I will focus on the user interface for the rest of this post.

The book Service-Oriented Architecture: Concepts, Technology, and Design by Thomas Erl provides good description of SOA and web services but the issue of user interface is never broached. The reader is left to wonder whether the user interface is somehow built into the services or sits outside it. Another book Enterprise SOA: Service-Oriented Architecture Best Practices by Dirk Krafzig, Karl Banke and Dirk Slama explicitly states that the user interface sit outside the service. An article by some IBM authors provides both scenarios. They observe that " The Model-View-Controller (MVC) paradigm underlies most modern UI application frameworks. SOA operations provide the model layer, and UIs occupy the view layer". (Hepper et al)

The IBM article discusses Web Services for Remote Portlet (WSRP) to enable a portal to aggregate content from multiple sources. The intention of WSRP is so that "Content and application provider services can be discovered and plugged into standards-compliant applications without any extra programming effort". This described more succinctly in another article "A remote portlet is a portlet that's deployed in a different environment than the portal that actually uses it" (Ort). The approach assumes the software developer has a portal for the portlet deployment.

The IBM article also looks at the human workflow. If all human interactions can be managed by forms within a workflow product then programmatic user interfaces could presumably disappear. The human workflow is included in the BPEL process designed to orchestrate the SOA. This may be good for simple forms but this is not going to suit all purposes.

There seems to be a weight of industry acceptance behind Rich Internet Applications in general and AJAX in particular. This user interface for SOA uses makes good use of the XML used in web services messages uses asynchronous messaging and is sufficient rich to provide users all they need from a simple web browser. This approach seems to be supported by Zapthink, Tibco and Oracle.

A number of products seem to be appearing that target the SOA user interface space. BEA systems, Sun Microsystems, CapeClear Software, Tibco (see footnote) all plan to add Ajax tools to their SOA-centric products (Meehan). Other solutions will also become evident from vendors like Corizon that use approaches to SOA user interfaces that differ to the AJAX approach.

The combination of AJAX and WSRP seems well accepted by the industry. "These two technologies complement each other in terms of ease of sharing of aggregated content and better usability of such content" (Padmanabhuni et al). AJAX support will be included in WSRP version 3 (Dovey). These technologies have been included in both the IBM Websphere and BEA Weblogic portal products. AJAX allows the interfaces with sufficient richness to be developed for Web Service applications and WSRP allows interfaces to be deployed and aggregated into portals easily.

It looks like the choice to use SOA and the choice over interface technology will always remain fairly independent although not unconnected. This could be an advantage as it will mean that that good user interface technology can develop reasonably independently for the evolving web services standards. A portal seems a generally accepted starting point for an SOA user interface. AJAX and WSRP are popular technologies to take advantage of web services. The human workflow approach as way for users to interact with SOA is worth watching. This will be an effective way to build workflow applications that have simple form-based user interfaces.

Footnote
Comments received on this blog suggest that Tibco have already released Ajax tools for their SOA product offering.

References
Erl, Thomas, Service-Oriented Architecture: Concepts, Technology, and Design, 2005 Prentice Hall

Krafzig, Dirk, Banke, Karl and Slama, Dirk, Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall, 2004

Hepper, S, Liesche, S and Stockton, M, http://www.ibm.com/developerworks/library/ws-soa-progmodel5/index.html

Ort, Ed, What's New in SOA and Web Services? http://java.sun.com/developer/technicalArticles/WebServices/soa2/WhatsNewArticle.html

Meehan, Michael, Vendors look to Ajax to make SOA shine
http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1144429,00.html

Padmanabhuni, S, Kunti, K, Sahoo, L and Bharti, S, Coupling RDF/RSS, WSRP and AJAX for Dynamic Reusable Portlets: An Approach and a Use Case, http://doi.ieeecomputersociety.org/10.1109/SERVICES.2007.26

Dovey, Matthew, WSRP2 and JSR286,
http://www.nesc.ac.uk/talks/686/10-00_Dovey-WSRP2-JSR286.ppt

Seeley, Rich, Ajax tools from IBM and real-time Java for SOA from BEA,
http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1213063,00.html

Seeley, Rich, BEA bets its portal on WSRP, Ajax,
http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1198691,00.html

Davies, David, SOA at the user interface, http://www.looselycoupled.com/opinion/2006/davies-ui-dev0424.html

Tibco, Rich Portals: The Ideal User Interface for SOA,
http://www.tibco.com/resources/mk/rich_portals.pdf

Bloomberg, Jason, Corizon: Leveraging User Interface Services for Rapid Application Creation
http://www.zapthink.com/report.html?id=ZTZN-1216

Bragging Rights on Coupling

I am reading "Enterprise SOA: Service-Oriented Architecture Best Practices" by Krafzig, Banke and Slam and I have come across a section on "Tight Versus Loose Coupling". This is a topic of my recent post" Cohesion, Coupling and SOA.

In my earlier post I described the taxonomy from loose coupling to tight coupling provided in a Pressman textbook
· No direct coupling
· Data Coupling
· Stamp Coupling
· Control Coupling
· External Coupling
· Common Coupling
· Content Coupling

I then added to this Message Coupling which was suggested by Thomas Erl. Now Krafzig et al is suggesting there is more to message coupling than just a single category. The book describes seven dimensions of messaging coupling. The 'coupledness' created by messages will depend on
The physical link (eg. Whether messages are put on a queue or the communication is a point to point communication).

• The communication style (eg. Asynchronous or synchronous)
• The type system (eg. Is the type determined by the called service interface or the message payload)
• The interaction pattern (eg. A service is more loosely coupled if it receives a message, then processes it and then can forget about it such as a stateless service. Tight coupling is required if for example the service uses an internal variable to keep track of the state)
• Control of Process Logic (eg. Additional coupling can be added to impose transactional integrity)
• Service discovery and binding (eg. Are services discovered through UDDI or similar means or are they directly referenced? )
• Platform dependencies (eg. Tighter coupling results if the service must always invoked from the same technical platform).

This threatens to make a mess of the neat one-dimensional coupling spectrum but we must remember that the spectrum of coupling types is only a guide and that it was always possible to have combinations of coupling types. I develop a priority listing below.

What was meant by message coupling in my earlier post was focusing on the asynchronous nature of messages. All the Pressman coupling types assume synchronous procedure calling and this was proposed before the time of distributed computing so they all are fundamentally coupled by the fact the modules were running on the same piece of hardware. Distributed computing warrants its own sort of coupling. The new spectrum might look like (from loose to tight coupling):

0. No direct coupling
1. Services Registry Coupling
2. Message Payload Coupling
3. Queue Coupling
4. Asynchronous Coupling
5. Plane Old Message Coupling
6. Bind-Time Coupling (added from later posting)
7. Process Control Coupling
8. Creation Coupling (added from later posting)
9. Process State Coupling
10. Platform Coupling
11. Distributed Coupling
12. Data Coupling
13. Stamp Coupling
14. Control Coupling
15. External Coupling
16. Common Coupling
17. Code Coupling (added from a later posting)

Rather than use the dimensions of Krafzig et al I have used labels of describing and example of a a coupling category within that dimension. In most cases it is the looser coupling category. This is consistent with the earlier coupling types. Therefore I use 'Queue Coupling' for the 'Physical Link' of Krafzig et al and 'Asynchronous Coupling' is used instead of 'Communication Style'.

I have inserted "Plane Old Message Coupling" in at number 5. In fact all coupling types from 1 to 9 are message coupling. Coupling types 7,8 and 9 increase the coupling between services. Coupling type 1 to 4 loosen the coupling compared to a synchronous message, called using its inteface without the assistance of queuing or a registry.

As discussed in the earlier posting the classic coupling types are still relevant to SOA. If you use a tight coupling type then it does not matter what good things you have to decouple your services there will still be tight coupling.

The numbers in the above list can be used as score. A low score is good loose coupling. For example if you are sending messages with Boolean values that significantly effect the processing in the called services then you have control coupling and you score badly with a 14. It does not matter that you are using asynchronous message and type is based on the message payload. The services are still tightly coupled. Similarly if you send a huge amount of XML and the service only uses a part of this then this is 'Stamp Coupling' and can only score an 13.

Loose coupling in our ideal SOA applications requires our services to be recorded in a registry, to be driven by the message payload, to use queues to communicate, to be asynchronous, to not have overriding process control and to be stateless. These services are platform and hardware independent. The payload should not contain extraneous data, or control values. The operation of the services should not communicate using external methods or use common shared data areas.

If I ever write a software development text I think this would be useful content. Perhaps this can be used as bragging rights however I am not the sort of person to say something like "How many types of coupling do you know, I know 18".

References

Krafzig, Dirk, Banke, Karl and Slama, Dirk, Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall, 2004, Section 3.5

Pressman, Roger, Software Engineering: A Practitioners Approach, 1982 McGraw Hill

Erl, Thomas, Service-Oriented Architecture: Concepts, Technology, and Design, 2005 Prentice Hall

Web 2.0 Reaches Fever Pitch

This week I have had two acquaintances in South Australia evangelize about Web 2.0. The first was Mike Seyfang. He is interviewed in an article in "The Adelaide Review". from the world of Microsoft. The last time I was contact with Mike he was working for Microsoft in an Innovation Centre they had set up in partnership with the SA Government. The article focused on micro-blogging in twitter and facebook and did not really get to the heart of Web 2.0 which I feel is the collaboration and the easy combination of tools.

The second Web 2.0 evangelist was Kym Farnik from IBM. This is a man with huge credentials in serious IT and he was describing what big blue was doing in this space. Kym was presenting the Australian Computer Society, IT Architect SIG. He was focusing more on the tools to create product that can be used in mash-ups.

The message from both of these respected IT people was that Web 2.0 is ready to come in from the realm of the teenage hobbyists and the anarchic masses to provide some real business benefits. It is a hard message to sell. Instant messaging has been around for quite some time and does not seem to have penetrated the organizations I work for. A Wiki has found a place amongst a group of my IT people but it struggles to be recognized as an information store of any importance.

There is no doubting the utility of the Web 2.0. What is it about business that squeezes the life out of this technology? It could be the control that big business demands over its information assets. It could be the lack of freedom in relation to IT. It could be that web 2.0 succeeds in a world where people want to collaborate for the sake of collaborating. Collaboration in the business world has to be much more directed to some other outcome.

I think we'll see more applications of Web 2.0 in the business arena, especially as the power of Microsoft and IBM are behind its evangelizing. I look forward to this. Watch the mobile phone application space. This could be really big, however I do not think Web 2.0 itself will be seismic shift in the way most organizations do business. Expect a few neat add-ons to web applications to be developed with Web 2.0. I would also expect some workgroup collaborative tools that will have a fairly narrow focus rather than replacing the way we all work.

Reference
Beyond Blogging in "The Adelaide Review" , No 319, June 22-July5 2007, p8, http://www.adelaidereview.com.au/

Farnik, Kym, Making on-line communities and community collaboration real(Leveraging Web 2.0), http://sa.acs.org.au/it_arch/images/a/a7/ACS_Web_2.0.pdf

SOA Concepts, Technology and Design: Book Review Pt 2

I have enjoyed reading Service-Oriented Architecture: Concepts, Technology, and Design by Thomas Erl over the last couple of weeks. This posting is my main book review. I have also referenced the book in previous posts.

Erl takes top down approach to the writing of the book. He discusses management issues to start with and promises to deliver a lot more of the nuts and bolts of how to do SOA later on the book. It was a bit like pealing the layers of an onion away. I had some idea of what was to come but I had to be patient. This made me eagerly anticipate some of the detail that was later in the book. The middle chapters did not provide the detail and repeated some of the material in the earlier chapters. I found these middle chapters did not provide enough detail on the one hand and not enough new material on the other hand.

I prefer the style of book that presents code examples early on, usually to the complete bemusement of the reader and gradually unravels the mysteries of these examples as the book proceeds. Erl leaves the detail to last but he uses three ongoing examples with good effect throughout the book.

The genesis/history of SOA is not covered in any detail but there at least is some reference to SOAs precursors and a good summary of the standards organizations and what they are responsible for.

The scholarly tradition of referencing other books is missing. There some good references to other web-sites but not really much on other thought-leaders in this space. This is an introductory text so further reading opportunities would be valuable.

The approach in the book is logical and clearly mapped out by the reader. By the end, when it gets down to SOAP and WSDL examples the reader is asked to refer back to previous chapters to recall the motivation behind the syntax. This gets a bit difficult for the reader who is going through the book over a period of time.

Erl could have spent more time talking about the user interface and the persistent data. These are critical parts of any system and I was left wondering how these fitted into the service design.

Service-Oriented Architecture: Concepts, Technology, and Design by Thomas Erl is a long IT book (725 pages) it has about the same number of pages as "Harry Potter and the Deathly Hollows" (784 pages http://www.mugglenet.com/app/news/show/739 )? It does however have more pictures and diagrams than Harry Potter and also less violence and supernatural themes. If 725 pages is not enough pages for the reader, there are some material on a web site that supports this book (http://www.serviceoriented.ws/ and http://www.specifications.ws/ ) although I could not find all the material promised on these web sites. Like Harry Potter the ending is a bit of let down.

SOA is not an easy subject to write about. Erl has managed to pitch it at the right level for IT management, business analyst, architects and developers. This is book is probably not for the non-IT person though. Erl has managed to pick his way through the maze of standards and made it very clear that Web Services is the way to go and that there are a number of WS-* standards that are important for the organization.

This book focuses on the standards but rather than going through the specifications in detail we establish why the standards exist and give some simple examples of ways these standards are used. This is again provides a choice the writer. Erl has chosen to focus on the WSDL rather than vendor tools that may generate this WSDL. For instance we are given sample of WS-BPEL rather than shown a tool that generates the WS-BPEL from a business process diagram tool. This was a sensible choice given the dynamic nature of the industry in this area.

I read the book cover to cover but there are plenty of options suggested by Erl to skip bits that the reader is not interested in. Erl has a new book out (SOA: Principles of Service Design) according to Joe McKendrick it another good contribution to SOA http://www.soainaction.com/blog/2007/08/standardize_standardize_standa.php

This may well be the best book addressing this content. The presentation of the book looks excellent from the impression I got reading it on-line. The diagrams pictures and examples make a difficult subject easy to follow and Erl's writing is clear, precise and friendly. Above I make some quibbles about how the book is put together but in general I believe this is a book that is practical and will deliver value to people wanting to build software.

Cohesion, Coupling and SOA

I was prompted to review one of my university texts on program design when I was reading some material on how to develop good software under SOA. The text in question is "Software Engineering: A Practitioners Approach" by Roger Pressman. It gives and excellent account of cohesion and coupling apparently developed earlier by Larry Constantine. I note this is currently presented in Wikipedia (http://en.wikipedia.org/wiki/Cohesion_(computer_science) and http://en.wikipedia.org/wiki/Coupling_(computer_science) ).

Pressman presents a range of cohesion and coupling types and explains this as two linear scales (low coupling good, low cohesion bad). These do not seem to be used in any detail in the SOA literature that I have read which is a shame because knowledge of this concepts is relevant. There is a lot of discussion about loose coupling without much reference to its definition. In Pressman's terminology loose coupling between modules (or services) includes, 'No direct coupling' and 'Data Coupling'. When you get to 'Stamp Coupling' and 'Control Coupling' you are getting into the area of bad coupling which a developer may compromise on if there are good reasons (eg. Performance). 'External', 'Common' and 'Content Coupling' gets into the forbidden zone.

SOA adds 'Message Coupling' to the above list. 'Data Coupling' assumes a procedure call where the location of the recipient is known and the parameters conform to known format. Messages on the other hand do not require this detailed knowledge of the called procedure and therefore are usually lower on the coupling spectrum than 'Data Coupling'. 'Loose Coupling' is a term used often in SOA but it means more than just using messages to communicate between services. The other forms of coupling still can exist. You can pass control information by messages and still have control coupling. You can allow access to common persistent data and still have external coupling. Message orientation does not automatically mean you have loose coupling.

Cohesion is a term that is not seen as often in relation to SOA. Pressman lists different types of reasons that you might bring bits of code into the same module. Some of these are just as valid when you are building a service. The ideal cohesion is where a module implements a single idea 'Functional Cohesion'. The next best cohesion is 'Sequential Cohesion' where steps are included together because they have to follow each other sequentially. Both these forms of cohesion are usually too fine-grained to be implemented as services. Modules that exhibited this level of cohesion would however be good operations within a service.

'Communicational Cohesion' is the developing of modules around a data structure and this equates closely to 'Entity-Centric' services for an SOA. 'Procedural Cohesion' relates code that is included in a module because it belongs to the business process. This is similar to the 'Task-Centric' services for an SOA which are appropriate for business services but usually exhibit less cohesion than entity-centric services in application services. In the more scatter-brained rationales for cohesion we have 'Temporal Cohesion' for code which must be executed in the same span of time, 'Logical Cohesion' for operations that are logically similar and 'Coincidentally Cohesive' where the code is related loosely. These are scatter-brained approaches both in classical development and SOA.

Thomas Erl says that ideally
· Services are reusable
· Services share a formal contract.
· Services are loosely coupled
· Services abstract underlying logic.
· Services are composable
· Services are autonomous
· Services are stateless
· Services are discoverable
On the surface one might consider that the only relationship with this list to the concepts coupling and cohesion is the reference to loose coupling. In fact all the qualities except discoverability can be enhanced with an understanding of coupling and cohesion. Good cohesion and coupling allows services to be more reusable. A formal contract makes the relationship between services explicit and therefore less tightly coupled. If the underlying logic of a service has to be understood to understand the service then this probably means the interaction of the service is not going entirely through well understood messages. Autonomy is another way of expressing cohesion as service has control over its code and is not effected by outside influences. State in a service is a form of control coupling. A stateless service means that control is not being handled outside the service.
The important point here is that we can use some already tried and tested techniques to apply to quality service development. The design literature of SOA would do well to draw more on this legacy rather than use some statements about loose coupling that are left without clear definition. Another point of this discussion is to emphasize that old IT concepts are still valid, which gives aging software developers a warm feeling. We are still trying maximize cohesion and minimize coupling in our services just as we did in our Fortran subroutines.


References

Constantine, Larry and Yourdon, Edward, Structured Design, 1976

Pressman, Roger, Software Engineering: A Practitioners Approach, 1982 McGraw Hill

Erl, Thomas, Service-Oriented Architecture: Concepts, Technology, and Design, 2005 Prentice Hall