Will BPM be the Savior of SOA?

My friendly Software AG representative recently gave me a copy of the "BPM Basics for Dummies". This was an interesting little book pitched at the Executive level. It would not help an IT person to get started with any particular product set but would help them understand what all the fuss was about.

BPM (see note below) has been with us since at least the 1980s. It used to a paper process of writing up the process and then getting a team of programmers to build it, then implementing it on usually a big computer that could handle it and then have the computer operators monitoring it.

In the 1990s Business Process Reengineering (BPR) was an approach which changed an organizational process. It involved process diagrams, IT change and business change.

The excitement with BPM is that some of the leg work involved in actually building systems can be removed if the components of the business process are already established. In this case the components are Web Services enabled through an SOA.

What interests me about this is that some of the concepts behind BPM are a lot easier to explain to the business than SOA. You can get out the Lego blocks and explain the benefits of agility until you are blue in the face but you are still only talking in analogies and expecting the business to take a leap of faith. If you show the business a diagram of one of their business processes and then tell the business the cost of changing that business process then that makes sense in terms the business understands. Of course there is a significant investment in infrastructure, tools and services to establish before you get to that point. It is this significant investment that the IT executive wants to sell. If you are pushing a plan to buy infrastructure, tools and establish services then the plan will make more business sense if the objective is BPM rather than SOA.

I think Software AG understands this and that is why they are giving out "BPM Basics for Dummies" and not "SOA Basics for Dummies". I think the business will get behind BPM before they will embrace SOA. We may see more push for BPM to business executives and SOA may take a back seat. The IT department however knows it needs SOA to get BPM to work. That is just how it meets the business goal of BPM.

Note:

BPM stands for Business Process Management, but you would excused for thinking it stood for Business Process Modeling. The "Management" implies that we are doing a lot more than mapping out the processes. The "Management" moves beyond documenting the processes to making them happen and monitoring their effectiveness.

This is not to be confused with BPMN (Business Process Modeling Notation) where the "M" stands for "Modeling". BPMN however can move beyond an aesthetic model to an operational system by converting it to BPEL.

References:

http://www.ebizq.net/hot_topics/bpm/

http://www.bpmn.org/Documents/Mapping%20BPMN%20to%20BPEL%20Example.pdf

http://en.wikipedia.org/wiki/Business_process_reengineering

Kiran Garimella, Michael Lees and Bruce Williams, "BPM Basics for Dummies (Software AG Special Edition)", Wiley Publishing Inc. 2008.

Book Review: J2EE and Weblogic

I was drawn to reading the book "J2EE Web Services on BEA Weblogic" by Anjali Anagol-Subbarao because my organization has purchased the Weblogic platform and I wanted more detail about how to make the best use of the tools available in this suite. General books on SOA can tell you about the principals and standards but without actually talking about specific tools there is a big gap between theory and practice.

"J2EE Web Services on BEA Weblogic" was published as part of the Hewlett-Packard Professional Book Series. While the Weblogic content the descriptions of some of the management functions of HP Openview were a bit alienating as I have not used this product. However it did also talk about some useful utilities and open source products that were not provided by either BEA or HP.

While the description of the tools were fairly high level and probably could be translated into similar functions in other suites I do not expect this book attract users of other SOA platforms suites.

The book style is fairly easy to read with some good diagrams and examples. The SOA standards and principles are covered well with a focus on the WS-*, SOAP and WSDL standards.

The basics of J2EE and EJBs are explained and some fundamentals of the Weblogic platform. This is not an evangelistic book about SOA or Web Services but goes into a bit about the technology of how to bring it about. The SOA benefits are there but the SOA story gets a bit lost amongst the instruction on how to use the BEA tools.

Some of the material reads like BEA marketing literature. I would have liked more practical tips on what to use and what not to use. In a book like this we need information that we can't glean from the manuals. This provided the high level overview with out some of the more practical "dos and don'ts".

There is good information on versioning and a good section on evaluating WS management tools. Also the book provides some practical approaches to performance issues.

This book has limited readership and will date quickly. Your best technical advice will always come from the product manuals but this book explains a bit about the suite is used as a whole. Published in 2004 this book is nearing its "use by" date but there is still some relevance to what it describes. Be quick though, with the acquisition of BEA by Oracle we can expect some changes to the BEA product suite.

Web Services versus the REST

Despite there being much discussion about the relative strengths on between SOAP Web Services and REST it is not actually that often that you make an explicit decision between the two. Once the die is set you will tend use one or the other. Alternatively it may be self-evident which approach gets used for what services.

The decision to use one technique or another is not made very often. Often such a decision is made in series of smaller decisions over a period time. For instance REST may be chosen to be used for some aspect of some project several times over before it assumes the role of accepted practice in an organisation. Often these decisions are not made in a formal way.

This week my organisation had one of those smaller decision points. The solution architect proposed that we use REST or SOAP Web Services for our services. To define the solution architecture fully we needed to decide which one we going to use.

The case for REST was:

• There would be less processing overhead
• It would a less heavyweight solution as far as programming effort
• Easy for service consumers to understand

The case for SOAP Web Services was:

• The project was already using SOAP elsewhere
• Web Services was a standard and REST was a "architectural style"
• Our partners were more likely to adopt Web Services than REST
• The explicit definition of service contracts in WSDL would be an advantage
• Can deal in standard fashion with reliability and transaction issues
• Better for modelling processes (verbs rather than just nouns)

Other points that were considered

• Our organisation is not particularly experience with either SOAP or REST
• We had used other "service" approaches (neither SOAP or REST in the past)

The decision is not a simply a decision between one or the other. An organisation can adopt neither, both for different circumstances or both in combination. Zapthink advises

… the debate about Web Services and REST is as pointless as arguing whether a
hammer or a screwdriver is a better tool.

W3C discuss a scheme for reconciling the two so that SOAP-based services can be used in RESTful ways.

The winner in this case discussed above was Web Services. This does not commit the organisation to using these technique in the future however this decision will influence future decisions to adopt Web Services in favour of REST. The "horses for courses" approach of choosing the best approach for the application will become less likely as the organisation developers expertise and confidence with Web Services.

Notes:
There is some argument about whether REST is Web Services or not. The use of Web Services Description Language (WSDL) in conjunction with SOAP and not REST suggests that SOAP and Web Services are inseparable. I will use Web Services (capital "W" and capital "S") to describe SOAP based services. Many commentators advocate using "web services" as a description of services developed in REST.

Some REST (Representational State Transfer) include

Daniel Rubio
http://www.webforefront.com/archives/2005/05/rest_-_represen.html

Joe Gregorio, December 01, 2004
http://www.xml.com/pub/a/2004/12/01/restful-web.html

Mark Baker et al
http://rest.blueoxen.net/cgi-bin/wiki.pl?FrontPage

More on ESBs

One of my for more popular postings has been "ESB or not ESB". I suspect the only reason was the word "ESB" appeared twice in the title and the Google search engine gave it a high priority when people searched on this acronym.

This was cited in an Italian language blog posting by Andrea Gumina which also cited a good posting by Steve Vinoski . Steve's posting is perceptive and has many good comments on it.

Steve is commenting on an earlier posting by Patrick Logan. Patrick describes the concept of an ESB as a "mangy mutt" because it is a " grab-bag of mechanisms that form no coherent whole". I agree with this assessment but feel that the ESB concept will mature. The ESB may be a mechanism to provide some plumbing. Many organisations SOA efforts need that plumbing because the system delivery has a number of leaks.

My organization was galvanized into inaction and has not yet bought an ESB. However we are fairly typical I would guess because we want the vendors products to do 'everything' for us. IT is not our core business and we do not want to worry about location or services, security, integration, messaging etc. We want our developers to focus on business logic and data models specific to the business. If the vendor came up with an ESB that really did remove the need to spend time on software infrastructure (and did not charge a fortune for it), then we would be interested.

I would also like our developers to settle on a "one best way" to develop applications rather than the organization investing in training and support for a multitude of programming languages and technologies. Steve advocates using the right language for the job and not being confined to one language. This is a noble cause but it is hard work learning another language and becoming proficient in it. Most developers I know have the one language that they would prefer to write everything in, just as most people I know don't communicate in anything but English. If I weren't so lazy I'd teach myself Italian so I could find out what that Italian site was saying about my blog posting. Similarly I think many developers can't realistically be expected to be truly multilingual when it comes to programming languages.

The discussion of Steve's posting gets a hijacked by the REST vs Web Services debate. This is unfortunate because the ESB discussion should be a separate issue. Using SOAP and Web Services does not require an ESB. ESBs have been conceived to assist with REST such as open source ESBs WSO2 and Mule. The more popular arrangements seem to be that Web Services use an ESB and REST does not, but this need not be the case. The REST vs Web Services argument is taken up elsewhere and in some people's minds have already been settled. Ronald Schmelzer of Zapthink states:

In many ways, however, the debate about Web services and REST is as pointless as arguing whether a hammer or a screwdriver is a better tool.

In the discussion in Steve Vinoski's posting I found myself agreeing with Jonas Ekstrom and Paul H that the ESB market is not yet mature. Jonas put this eloquently:

Religions give easy answers, but there are no easy answers. Natural selection will strike again and again until we have reached the perfect SOA.

Paul H puts a similar slant on this:

I look forward to the day when we’re in a similar stage of maturity … and there exists generally accepted, standardized, manageable, and self-federating mediation technologies … until then, we’ll all have to suffer through endless arguments along the lines of 'should I use a BEA ESB or a Sonic ESB? is an ESB really necessary, or can I get away with REST + Dynamic Languages?'

I will continue to wait until the need for an ESB (or some part of one) becomes self-evident. While an implementation of SOA can function without and ESB there seems little point in making the investment.

Binding and Coupling

From the Doug Kaye, the man who wrote the book on Loose Coupling

Loose coupling is like pornography. Everyone talks about it, but when challenged, few can tell you what it is. For some, it borders on a religion with the attendant fervor one would expect from the newly converted.

When I say he "wrote the book" I mean that literally. There is probably only one book dedicated to this subject and he wrote it.

• Loosely Coupled: The Missing Pieces of Web Services, Doug Kaye ; RDS Press 2003, ISBN 1881378241

I am not surprised it is possible to write a whole book on this. Firstly it is pivotal to SOA and secondly there are so many different aspects to coupling. Today I will discuss binding and Coupling but my postings on coupling probably will not be able finish until I read this book.

Binding is the time when a logical description of an attribute is tied to its physical value. For instance a service address can be bound when the source code is written, when it is compiled or when it is linked into an executable module. This is called ‘early binding’ or ‘build-time binding’. A service address can also be bound to its physical address when the message is sent, or when it is handled by intermediaries. This is called ‘late binding’ or ‘run-time binding’.

Some formats of payload can also be bound at build-time. For instance java objects (and serialized data objects) are bound at build-time. Therefore a receiver will reject a message containing a serialized java object that is not bound to the same physical representation of the object.

Generally in SOA, loosely coupled services are also considered to have all aspects of their messages bound at run-time. Having an address or payload that is bound at build-time reduces the run-time flexibility of these services.

Binding and coupling could be treated as independent dimensions of the separation between services. A build time dependency on a message is so significant however that I will roll it into the coupling dimension. This is appropriate as coupling is a combination of characteristics and not a single dimension anyway. By rolling build time dependency into our types of coupling it also enables us to keep our definition of a service clean without having to comment on binding between services.

This leaves me with another coupling type ‘Build-Time Coupling’ which I will add to my list of coupling types. It is more tightly coupled than most forms of message coupling. This list has been modified in my posting about Aspect Orient Programming and I intend to republish it again after I have made a couple more revisions.
'Build-Time Coupling’ is still a form of Message Coupling so I still include it as part of a service in SOA. It would generally not be considered good to have these dependencies and we would be justified in excluding build-time dependencies from the definition of a service.

It is good practice to pass version information in messages between services. Therefore a message may contain a version number or a build date so that another service can check it and take appropriate action. If a receiving service detects a change in the version of the sending service then this fact might be logged, or the metadata inspected or the message may be rejected. This is not a build time dependency described above. It is another metadata control. Rather than add ‘version coupling’ to a long list of coupling types I will combine the other coupling types that have similar metadata that control the behaviour of the services into ‘Process Control Coupling'.

I hope to revise my own list of Coupling Types shortly but in the meantime click on this link to look at the list developed by the man who wrote the book on coupling.

Footnote:
I have found and extended forum discussion on Passing Serialized Java Objects vs. Web Services . This features and appropriately named J. Cowboy who is railing against those bullies in management who want him to develop Web Services instead of passing (build-time coupled) serialized java objects around his system.

Conference Summary Served with Spaghetti

I presented at a conference “Achieving Interoperability in Systems Architecture” on Wednesday. The occasional get together of architects, managers and developers is valuable. You can grab the odd new insight and find new approaches but it is also good to see others attacking problems in the same way and validating your own approaches.

After the conference I thought I would finish this summary on the aeroplane home. I have always wondered how to spend the time on long flights profitably and I admired a couple of passengers using laptops on my previous flight. Unfortunately as I try to use the laptop in flight I am in a middle seat with no elbow room on either side, and now I am served dinner in middle of the flight. I am juggling my laptop and the worst Spaghetti Bolognaise I have ever tasted. Still, here is the summary.

Josh Graham of Thoughtworks kept time well and came up with the comment “Why should I expect straight lines on my Business Process Model when business is inherently messy.” He also introduced one of our New Zealand guests as coming from the land of the “Wrong White Crowd” which sounds like a political comment and spoonerism wrapped up into one.

Mark Murphy of Tower Aust Ltd advocated we start small with SOA. He quoted IDC showing growth in SOA from $3.5bn in 2005 to $33bn estimated in 2010. Mark looked at some SOA definitions and aptly described the current situation where people build silo applications and then expect IT to join them together. He showed a couple of models from Sun and Microsoft showing SOA models that illustrated logical SOA.

Stephen Smith of Arcbok presented a simple framework for assessing the readiness of an organization for SOA. The framework consisted of assessing an organization on the dimensions of Leadership & Culture, Business, Technology, Knowledge, Funding and Sustainability. Each dimension has a number of questions to ask about an organization to asses its readiness. The sustainability dimension described whether the organization had the appropriate support, operations and governance in place for sustain the SOA. This also could include appropriate operational monitoring, measuring and standards. A readiness assessment tool is about risk management. Beware vendor maturity assessments that are used as tools to sell more services.

Krist Davood of AGL and Sensis has achieved something that everyone in the room envied. He had success justified SOA as an initiative using fairly hard-nosed accounting principles. He had justified SOA because of its ability to avoid periodic failures in the business because of the current way of doing things. He had been able cost these failures and justify the project to introduce SOA into the organization. SOA as a strategy to eliminate risk had been demonstrated to be effective.

Centrelink is a huge SOA operation and it was good to hear from Rob Doughty who is their Applications Architect. I liked his characterization of users as “Human Task Delegates” in relation to workflow applications. It was interesting for me to hear about the legacy system challenges that Centrelink have, but also how their portal work in benefiting other government departments. The focus of the talk was the deployment of a portal product which they will be basing all their systems on. I liked the comment that “Portals bring people and process together”. Rob talked about the challenge of working with various IT groups to deliver on a particular pattern of use in relation to the portal. He advocated the use of an “Integration Competency Centre”.

I then presented on Enterprise Architecture and its links to metadata and SOA. Some of this material is already on my posting on SOA Definitions, SOA Metadata and the Zachman Framework. I will elaborate in a future posting.

John Fisher from the NZ Ministry of Education showed us some great business modelling techniques that had found favour with his users. The technique involved Business Element Models, Business Component Models, Business Role Responsibilities and Business Service Models. The models were focussed on producing requirements for widely federated (eg. For 2,700 schools) SOA systems. He introduced the analogy of using power adapter so could use a drill brought in the UK to explain SOA to users.

Jan McConchie of SA Government ICT Services provided an overview of the challenges that she has to bring together the South Australian Government Services to present a common face to the South Australian citizen. This was interesting because the SA Government has established and Office of the CIO and this is showing the desire to coordinate and rationalise government IT activities. As one of the agencies involved, my organisation will be affected by standardisation and IT governance changes. Jan drew on research by Gartner and Saugutuck Technology to explain what SOA meant to her and discussed some initiatives in place for the SA Government.

Chris Howard was from the State Revenue Office of Victoria. Chris focused on risk and SOA and quoted Gartner, advising that it would take 3-4 years before investments in SOA payed off. He discussed a long term plan for legacy transition which was underpinned by full and frank statements about costs, benefits and risks with his business. Chris endorsed ITIL as an enabler of SOA.

Josh ran an interactive session where we discussed the issues of SOA and getting the business on board. It was never clear what you will find when you "turn over rocks" in the analysis process. We discussed what services to build first. It was not always best to do the low risk, high value project first. In the end it might just be business or legislative imperatives that help you make the decision. It was difficult to decide when to do those cross-cutting "hygiene" services.

George Cascales from Integral Energy discussed how he was implementing SOA in an out-sourced environment. He had a small group of architects and had succeeded in being able to develop new applications quickly using reused services. His group focused on standards and governance rather than the actual development. A set of tools and standards would be given to contract developers to develop the services and applications.

Rajat Chopra, the international speaker from Bell Canada provided a good description of how Bell embraced SOA. It was important for Bell to provide common services to serve its various customer channels for selling telecommunication facilities. Rajat provided us with a number of analogies for explaining SOA to management including Lego blocks, a car factory and diet. With diets, you can latch onto gimmicks but in the end it is lifestyle change that makes the difference. This is the same with SOA.

Alex Jouravlev representing the ACS presented twice. Alex’s first presentation was titled Prepare IT and Business for SOA. He traces the origins of SOA back to 1988. He made the point that our business cases do not really engage the business and we need to strive for simple messages using language the business understands to achieve a ‘mental ownership’. Alex supported the model driven architecture approaches but not for the reasons that they were developed. Business requirements should be developed with referencing any ‘system’ and should be modelled with Visual UML Models. Alex noted that several modelling practices that were usually acknowledged as important were often missed. These include Conceptual Business Modelling, Conceptual Data Modelling, Business Object Modelling and producing an Enterprise Ontology.

Later in the day Alex was able to present a model based on CMMI maturity model in an easy-to-understand fashion with the purpose of moving the SOA objective from IT to the business as an organisation obtains more SOA maturity. Alex was able to give us a realistic view of the limitations that would be expected at each level of maturity and provide an insight into how the role of key players like the Enterprise Architect and Business Analyst would change at the various levels.

Ram Kumar was from OASIS and provided an insight into the work of this organisation that is emersed in creating SOA standards. He discussed his role in developing the Justice Sector Information Interchange standard. This was of special interest to me because of my involvement in this sector. Ram emphasised the importance of XML governance and advocated this for successful SOA.

Josh summarised the conference and he may discuss this on his own blog site. Many themes resonated with me but one stands out as I wrestle with my in-flight dinner. We had slides from at least three of the speakers that showed insanely complicated maps of their existing systems. It seems we are all lumbered with integration spaghetti and our hope is that SOA will resolve this.

The Definitive SOA

The definition of Service Oriented Architecture (SOA) seems to cause some anguish and confusion. This is because

• There is no good definition,
• Every one is thinking a bit differently about what SOA is,
• There is no acknowledged ultimate source on SOA, and
• It is hard to be brief enough to fit any SOA definition on a bumper sticker.

I thought I would set myself the challenge of coming up with a definition of SOA that I liked. My favorite for the last 12 months has been from Chris Brown of Wachovia Bank. I like it because it has two perspectives:

• From a business perspective, SOA is a construct and discipline whereby new business requirements are evaluated holistically against a backdrop of processes and functions that are currently in use by other business solutions. A common process or service that has been previously created, and paid for, is then augmented or reused, in whole or in part to create a new and/or improved process.
• From a technical perspective, SOA is a software architecture model where loosely coupled software components, representing granular but complete technical or business functionality, are accessible through known platform independent interfaces and transports over a network.

This is good for me because it speaks to the business in language they can understand. For the purposes of talking to the business I am happy to abandon technical precision. As for the second part of the definition I have recently had cause to question its precision. Terms like 'loosely coupled', 'granular functionality' and 'complete business functionality' are too ambiguous for a good technical definition.

It should be clear from a good definition that some applications do not apply to SOA. Some definitions I have seen would have to admit well structured COBOL applications as complying with SOA.

The reason it is important to have a definition is that now there seem to be a number of different interpretations to SOA. SOA to some people is Web Services, SOAP and WSDL. SOA to some is having a discipline around component reuse and not much more. SOA to some can also be as vague as basing software on business services. These interpretations of SOA can be useful in certain circumstances. This just means that when I talk about SOA it is necessary to declare what I mean.

I have looked through a number of definitions referenced below. Of special note is the research done by SearchWebServices.com that documented 12 different definitions supplied to it by technical celebrities who were asked to keep there definition to 50 words.

The things I want to include in my definition are:

• Distributed Computing
• Message Coupling
• Platform Independence
• Implementation Hiding or Abstraction

I should mention that I interpret "Loose Coupling" to be relative term. What is loose coupling in one context could the tight in another context. I have an earlier posting on the subject of coupling which emphasis the wide range of coupling types. I think we need to be precise about exactly what coupling we are talking about so I will use the term 'message coupling' in my definition.

The things that appear in some definitions that I want to leave out of my definition are:

• Web Services, SOAP, WSDL (too specific)
• Reference to Clients and Servers (It does not matter in SOA)
• Benefits of SOA (Reuse, agility etc.)
• Higher order concepts (Quality of Service, Security, Orchestration, Repositories)

So here it is. I resort to defining SOA and then a service.

SOA is a software architecture where the business logic is encapsulated in services and a single application may be distributed over many processors.

A service in this context is a software component which
· Hides its implementation,
· Is based on standards,
· Is location transparent,
· Is message coupled, and
· Is accessible through defined platform independent interfaces.

It would have been no good for SearchWebServices.Com because it is 59 words and it certainly will not make a good bumper sticker. However, it works for me now and like the rest of my thoughts on SOA, it is sure to evolve.

References:
My previous Postings on coupling: Bragging Rights on Coupling, Cohesion, Coupling and SOA

Brown, Chris, Transforming Business Process through Effective SOA Implementation, Conference Paper for Service Oriented Architecture 2007: Synchronising Business and IT to Drive Performance, February 26 - March 1, 2007, IQPC Conferences

Mimoso, Michael, A defining moment in SOA, http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1017004,00.html, SearchWebServices.Com, 20 Oct 2004

Some More Definitions of SOA:
OASIS: http://en.wikipedia.org/wiki/Service-oriented_architecture
XML.COM: http://www.xml.com/pub/a/ws/2003/09/30/soa.html
Webopedia: http://isp.webopedia.com/TERM/S/Service_Oriented_Architecture.html
TechEncyclopedia: http://www.techweb.com/encyclopedia/defineterm.jhtml?term=soa
OMG: http://colab.cim3.net/cgi-bin/wiki.pl?OMGSoaGlossary%23nid34QI
OASIS: http://colab.cim3.net/cgi-bin/wiki.pl?OasisSoaGlossary%23nid34QP
OpenGroup: http://colab.cim3.net/cgi-bin/wiki.pl?OpenGroupGlossary%23nid34QT
W3C: http://colab.cim3.net/cgi-bin/wiki.pl?WwwCSoaGlossary#nid34R0
WhatIS: http://searchwebservices.techtarget.com/gDefinition/0,294236,sid26_gci929153,00.html
Gartner: http://www.ipt-group.com/download/SOA_IG/SOA_IG_CS_2007_08_28.pdf

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

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.