SOA Videos

I read a posting by Collin Smith which included some YouTube videos. This gave me the idea to do my own posting on SOA videos. This also gives me the opportunity to reuse my keywords 'Monkeys' and 'Lego' which so far I have only used once each. My most popular posting so far has been 'Chasers War on Wikipedia' which is more about entertainment than SOA. This posting may be similar.

First, here are some YouTube videos. They have obviously all come from the same source but I am not sure who takes the credit for these.

SOA is like Lego Blocks, http://www.youtube.com/watch?v=sbd_1G8Kqjs&eurl=http%3A%2F%2F
I have a previous posting on this analogy. Like other commentators for some reason they have not used real Lego blocks in the video. Instead they have used a pale imitation. At least they have called them 'Building Blocks' rather than 'Lego'.

SOA is like Music, http://www.youtube.com/watch?v=zV860odGN5Y
This fits with discussion on SOA orchestration but still does not do a lot for me.

SOA is like choosing what wear, http://www.youtube.com/watch?v=dyHWAiG6c-Y
This analogy took me by surprise and it does not really work for me, but the girl is pretty.

Greg the Architect, http://www.gregthearchitect.com/index.html
If you have not seen 'Greg the Architect' yet, then you are missing out. This is the pinnacle of SOA satire, even if it is the pinnacle of a very low heap. It is produced by the people at http://www.soanowjournal.com/. At the time of writing there are four episodes.

• Greg the Architect SOA
• Greg the Architect ROI
• Greg the Architect Focus Pocus
• Greg the Architect - Off the Grid

SOA Monkey, http://www.youtube.com/watch?v=cM31qu9T3Iw
This one appealed to me. It is seriously off the wall. This monkey knows a bit about SOA though.

The following videos are more informative than entertaining.

There are some good interviews with SOA people of note at http://tv.sys-con.com/read/category/1260.htm . These interviews have advertisements though. I liked one I found on YouTube with the advertising removed 'SOA Power Panel with Jeremy Geelan'. There were a couple of good things I got out of this hour long video. Firstly the quote "Think different. Don't think too long" and secondly eight service characteristics of SOA:

• Loose-Coupling
• Contracts
• Manageability
• Versioned
• Discoverable
• Addressable
• Distributed
• Point to Point (None of the speakers seemed to agree with this one)
• Self-Describing (This was a ninth one that was added by a speaker)

Tarrant County implements SOA for criminal justice agencies, http://www.youtube.com/watch?v=JIpLllGl1fc
This is advertising for Progress Software but I liked it because I work for a justice agency.

SOA - Service Oriented Architecture Introduction, http://www.youtube.com/watch?v=sRFwswaJpD0
This was a good SOA definition but turn down the sound because the speaker sounds like she is reading a children's story.

Another good source of SOA video is http://www.infoq.com/. I have mentioned these in earlier postings. In the posting 'ESB or not ESB?' I referenced some videos from Mark Richards (http://www.infoq.com/presentations/Enterprise-Service-Bus) and Sandy Carter (http://www.infoq.com/interviews/sandy-carter-soa). In 'AOP: The worst form of Coupling' I use Jim Webber's comments about MEST from http://www.infoq.com/news/2007/08/jim-webber-interview.

Sometimes after a hard day at the office reading pages of IT jargon I find the videos easier to absorb than more text information. I hope you can find something here that is either entertaining or informative.

SOA and Metadata: Where you can Put It

This is a sequel to an earlier posting in which I described our developers drowning in metadata. Some basic governance has stopped it getting out of hand but more work has to be done as we adopt SOA. Todd Biske unknowingly describes our organisation accurately in his posting:

Organizations that are solely focused on design time discovery of services still wrestle with whether they even need a registry/repository prior to reaching some critical mass of services.

Here I present some brief insights into the metadata repository and service registry as a start to some research into what my organisatoin needs and when we might need it.

It is easy to focus on reuse as the main benefit of a repository but there are other reasons a repository is valuable.

Even without reuse, meta data can provide substantial benefits, namely system-wide change management and impact assessment.(Ambrosio)

There are a number of ways of classifying the metadata associated with SOA. We have already looked at the runtime and design time metadata. Some metadata is focussed on providing enterprise information while other metadata is provide for a particular solution. With good governance however solution metadata becomes part of the enterprise metadata assets and is given every chance of being reused. Metadata can be structured or unstructured. Cardwell discusses unstructured "tag-and-post" XML approaches and structured XSDs (XML Schema Descriptions).

The SOA Practitioners Guide discusses in detail what a SOA repository should provide. It summarises:

The SOA repository is the system of record for all enterprise metadata, service definitions, and dependencies. All metadata generated by the tools used by the architect/designer is uploaded to the SOA repository

Below is list from Stefan Tilkov of what you might find in the repository to assist design development and Governance.

• What services/operations are available?
• What is the message format?
• Which versions? (What changes?)
• Who is responsible?
• Who uses which service?
• What is the impact of change?
• Are services reused?
• Is documentation & usage compliant?
• Are SLAs being met?

The SOA Practitioners Guide is more specific the list provided there is:

• SCA models, BPEL, XPDL, JPD, and WSRP
• business processes, business rules, policies, and services
• architecture framework documents, enterprise and application models, and standards
• Source code
• Product specific metadata for configuration as well as service execution
• Java documents
• Release notes
• network topology
• service deployment network
• service dependencies and SLAs along with CMDB for capacity planning and network topology development
• Database Schemas
• CWM (metadata modeling notation of data warehouse) and XMI
• SLAs, QoS, and runtime performance metrics

The following list provided by Tilkov is metadata that is checked at runtime:

• What is the service endpoint (address)?
• Is a service running?
• Can consumer and provider policies be matched appropriately?

This runtime information can be either be stored in the service itself and made available through WS-MetadataExchange or be recorded in a service registry. In general a service registry is for runtime metadata and uses more structured metadata. The design time metadata is added to the repository and can be a combination of structured and unstructured metadata.

The SOA Practitioners Guide explains that

The service registry is based on UDDI and the system of record for all deployed services. It contains metadata including service definitions, service dependencies, and service interfaces.

Metadata has been played an important role in software development even before the advent of SOA. Part of the importance of Enterprise Architecture is to foster reuse and this is also the goal of SOA. The runtime use of metadata in SOA is significant because it assists in the loose coupling that is its hallmark. To best achieve the reuse in SOA is important to provide an effective repository and good governance.

References
Ambrosio, Joanna, The next step for meta data: Application integration http://www.adtmag.com/article.aspx?id=8838&page, 2/1/2004

Ballinger, Keith (and 21 other authors), Web Services Metadata Exchange (WS-MetadataExchange), http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-mex/metadataexchange.pdf

Biske, Todd, Is Metadata the center of the SOA technology universe?, http://www.biske.com/blog/?p=268, September 13th, 2007

Cardwell, Rob, Metadata Challenges in a SOA Environment, http://www.afei.org/5af3/documents/RobCardwell.pdf, September 13, 2005

Durvasula et al., SOA Practitioners Guide, Sept 2006, http://colab.cim3.net/file/work/SOACoP/2007_05_0102/SOAPGuide/

Tilkov, Stefan, The Central Role of Registries: Managing SOA Metadata, http://www.innoq.com/blog/st/presentations/2006/20060921_The_Central_Role_of_Registries.pdf, 2006

SOA and So Much Metadata

Everyone probably knows that metadata is "data about data". This concept has been around throughout the short history of information technology and before. The library catalogue is the archetypal embodiment of metadata. Data structures and then databases need description and these were more technical type declarations, schemas and Entity-Relationship diagrams. XML deserves special mention in this one paragraph of metadata history as it has revolutionised the way metadata is done. Now those library catalogues, those data structures alike can be described in XML.

Now metadata and XML has a particularly important role in SOA. Metadata is the glue that holds services together in SOA. WSDL and SOAP which are both based on XML are used at runtime to communicate with services. This is not the only importance of metadata in SOA though. Metadata has an increasing role during design time if you are going to get the most reusability from your SOA.

The amount of metadata require at design time is huge. To appreciate this it is instructive to have a look at the Zachman architecture framework grid. This 30 cell grid is full of architectures that use metadata models. Some might argue that some of the material from the top rows of the Zachman grid (scope and business model) is pretty far removed from working systems and should not be bundled in with metadata more directly relevant to implemented systems. Program code might not be considered by some as metadata but nevertheless it is an abstraction of data submitted to a CPU for execution. The point is that there is an awful lot of design time metadata in enterprise architecture. It might be XML, or UML, or other diagrams or lists but it should all be recorded and it all is interrelated.

The challenge has always been to store this metadata in a way that allows it to be easily retrieved, in a way that makes the connections to other metadata explicit and a way that can be discovered for new projects. Reusability has not been something that was discovered with SOA. Business process and data models have always been relevant over multiple projects and it has always been important to be able to find metadata when the need arises or when maintenance work needs to be done on old applications.

Finding a repository for all this metadata is not easy. Where these artefacts are stored with the tools that create them it makes it difficult to combine into cohesive store of information. Taking my organisation as an example, we use Telelogic System Architect for the higher level enterprise architecture document and Rational Software Architect for some of models used in our applications. We also have and issue register, a call logging system and diagrams done in Microsoft Visio. For data warehouse we use Oracle Designer and Oracle Data Warehouse builder. We store system information in CVS (software and document versioning), our file server, our intranet and our Wiki. No wonder we sometimes have trouble finding something.

How can I be sure that a developer has looked up all the previous work that has been done previously before the developer proceeds to develop a new service or interface? We could buy a metadata repository to hold all this information, but without good governance of the process of creating metadata this would be just one more data store in which to hide our artefacts. If it is clear what goes where then multiple repositories is not such a problem although it is obviously easier, the fewer different repositories you have.

In a sequel to this posting I will write more about registries and repositories, which are technical aids to solving the metadata flood. In this posting I hope I have established a need for dealing with metadata effectively.

AOP: The worst form of Coupling

I have just had the need to look at Aspect-Oriented Programming. The Wikipedia entry on this is very good and covers the benefits and risk well. The following provides a good summary of what AOP is all about:

…an aspect can alter the behavior of the base code (the non-aspect part of a program) by applying advice (additional behavior) at various join points (points in a program) specified in a quantification or query called a pointcut (that detects whether a given join point matches).

This offends my sense of what is good modularized code. AOP is done under the banner of "Separation of Concerns" but instead of separating parts of programming code in simple and visible ways, AOP is coupling it tightly. AOP is coupling code modules in ways a programmer would not expect from viewing the affected code. This is tight coupling of the worst kind. In my earlier posting on coupling I rated types of coupling from 0 to 14 from loosest to tightest. I will call this type coupling "code coupling" and give it 15, the tightest coupling index of all. The coupling is through the code rather than through data passed to the module. Code coupling is not new but I did not expect it to come up as modern programming paradigm.

Another form of code coupling is "inclusion coupling" which is explained well by Milind Shingade

Inclusion coupling is a form of coupling in which one component includes source code of another component. If the included component changes something on which includer depends or adds something that raises the conflict with something in the includer then the includer must change.

I see inclusion coupling as more benign than using AOP but I will still roll it into my "code coupling" category.

Control Coupling (coupling index 12) is pretty tight. This is where you pass a Boolean or control parameter to a procedure and have code in that procedure which checks the value and executes different logic based on that control parameter. This is one way of affecting the executed logic in the procedure but at least you can read the code and have some expectation of what the behaviour is going to be. With AOP an unsuspecting maintenance programmer may not have any idea that the program code is being affected by an "aspect".

Unfortunately I have to grant there may be a place for AOP. Code for auditing, logging, exception handling, security and range of routine work that needs to happen along with the business logic can make it difficult to discern the main thrust of what program code is trying to achieve. There is a big need for control and proper governance of AOP. If it has to be used then only senior developers should implement the Aspects. It only should be used in very limited circumstances. Ideally there should be clear documentation in program modules affected by an Aspect.

This should not be a pervasive programming paradigm. The programming should not be Aspect Oriented at all. Code should normal, good Object Oriented code but if AOP is supported a developer may introduce one or two Aspects to influence this code.

In summary I think AOP may be a horrible necessity in some programs and should be used with extreme caution. AOP has given me another type of coupling to add to my list. I had expected the next entry to my coupling list to be in the looser coupling range. I recently listened to a Podcast from Jim Webber of ThoughtWorks. Jim claims that MEST uses looser coupling than WSDL. I would like to see that. I am hoping to blog on this soon.

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

SOA Best Practices: A Book Review

"Enterprise SOA: Service-Oriented Architecture Best Practices" is by Dirk Krafzig, Dirk, Karl Banke and Dirk Slama. These are three Germans from the banking and insurance sector who present a wealth of practical experience to the reader. They attempt to talk about SOA without favoring any particular technology which is hard to do. I would still say that there experience with EJBs and CORBA provided a certain slant to the discussions however they were also using SOAP, WSDL and XML examples in their discussions.

The book had the feel of describing the real world rather than discussing and ideal world. By contrast the book by Erl was from a Web Services purist's point of view and glossed over some practical issues like what to do about user interfaces, performance problems and legacy transaction integrity. On the other hand Erl had the advantage of not having to describe the concepts in terms of differing technologies.

Legacy integration issues were covered well by Krafzig et al. There was an excellent chapter on process integrity and a good chapter on infrastructure issues like Scalability, Interoperability and Security. They covered the range of process integrity techniques from "Eyes Closed and Praying" to "Two Phase Commit over a heterogeneous environments" and "SAGAs with complex compensation graphs".

Krafzig et al provide more of "Horses for Courses" approach. Their approach does not necessarily advocate the same approach for fine grain and course grain services. Their approach even accepts that synchronous as well as asynchronous service buses might need to work side by side.

One theme was the importance of the registry and repository for SOA. The book gives some practical suggest about what to put in these stores. Another theme is the importance of governance of the development process. This theme is taken up in a later chapter which discusses SOA-driven project management, configuration management and testing. The book also discusses a thin-thread approach to software development. This is accompanied by discussions on how to fund SOA development and how to manage the risk of these initiatives.
The climax and conclusion of the book is four case studies. These are real-life examples with solutions that had to meet compromises and struggled with incorporating legacy environments with their solutions. It would have been nice to have an example that was not a finance company but it seems that is where the money is when it comes to SOA (and any big information systems for that matter).

The book did not provide a motivating definition of SOA although the thoughts on architecture I found enlightening. Such as "architecture … is designed to last longer than one or two of these technology innovation cycles" and that its purpose is to simplify development. How easy it is to forget that our new inventions in IT are just to make the world a simpler place.
I enjoyed this book. It was good to read a European context on SOA. They referenced Niklaus Wirth (a hero to anyone who did computer science when I did it) a couple of times and referred to other European IT Gurus which is refreshing break from the US IT heritage. I commend it to those who want a technology-agnostic look at SOA.

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

Getting Independent Advice

Last Tuesday we got a couple of consultants from interstate to advise us on how my organization is sailing with its initial steps toward SOA. Their brief was fairly broad. They spent a couple of days meeting with various groups including management, legacy developers, java developers and architects.

The idea was to get some idea of what we are doing wrong, what we doing right and what we should do in the future. This is a good thing to do if you can find respected practitioners who can provide this advice. It is easy to be insular and head off in your own direction without considering other options. This can apply to the organization, to groups of organisations and it can even apply to whole regions. I always object when the Federal Government or the eastern states regard South Australia as a regional outpost, but when it comes to best practice in IT we have to acknowledge that our expertise in major enterprise application development can be thin.

I was involved in a few of the meetings. I expect them to focus on our run-time stack, our development standards and development methodologies. The major focus was on our legacy software. This is a big problem and one which I was happy for them to take head on. We have many large systems written on the mainframe in technologies that are out of date and do not easily lend themselves to being accessed through services. The few tools that are available to assist are prohibitively expensive.

The report from the consultants has not come in yet but I was able to glean areas that the consultants seemed to be targeting. One was how to address issues such as Data Integrity, Process Integrity, processing exceptions and auditing in relation to making providing services using our legacy applications. These are the concepts discussed in chapter 8 of Krafzig et al "Managing Process Integrity". They are common application integration problems which pre-date SOA and they are the sort of problems that do not yield to simply adopting particular middleware or standards.

The other issue that the consultants were targeting was how much we were investing in our SOA. We are trying to fund SOA by paying for infrastructure and the development of skills out of project funding for the development of particular applications and enhancements. This may not be sufficient to get the critical momentum we need to get to a desired maturity with our SOA. It would be a good outcome if our independent advisers can report to our executive that we need more money specifically for SOA. It is a bit hard to do this from the perspective of the IT Department. The executive would suspect we were investing the money for no good business reason, perhaps just for buying new toys for IT. The opinion of the consultants may help to put our case.

Of course the consultants might be hoping we spend more money on them. We have to be on lookout for such bias in consultant findings. In general though it is always valuable to get a second opinion and I eagerly await the report from this exercise.

Reference

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

A Review of the SOA Practitioners Guide

The SOA Practitioners Guide is a thorough 3 part document covering all aspects of SOA. Much of what is discussed in this guide is not specific to SOA but a more general advocacy of best practices in IT development. Thus the Guide looks a development methodologies, portal technologies, support infrastructure, project planning and a number of aspect that are not pre-requisites to having SOA in place but support the establishment of successful SOA.

The three parts of the Guide are:
· "Why Services Oriented Architecture?"
· "SOA Reference Architecture"
· "Introduction to Service Lifecycle"

The first part was more a summary of what was to covered in the second two parts than a justification of SOA. I have read better and clearer justifications of SOA.

The Reference Architecture part is well presented and goes methodically through the layers explaining the various architecture options available. I am interested how different authors divide up an SOA. In the Guide the layers are:
· Web Application Tier
· Service Tier
· SOS Frameworks
· Application Tier
· Enterprise Security
· Business Service Management
· Services Oriented Infrastructure

Often when I read marketing literature or documents on IT tools I get the impression that these documents are written for global multinational organisation with huge IT budgets and hordes of technical people. This is one of those times. The array of tools a good SOA shop needs and the array of technologies an IT organisation is expected to master is mind-boggling. It is amazing that a medium sized enterprise gets any software development done at all. Occasionally I would like to see advice for small and medium organisations.

The third part of the Guide covers a number of design and development issues. It goes through the Software Development Lifecycle and looks at how SOA impacts on each stage. There is still a strong emphasis on tooling and technologies in this part. In this section there is an emphasis on Service Component Architecture (SCA). This is a fairly recent standard for bundling up services into components. According to Wikipedia version 1 of this standard was released in March 2007. I found a good summary of SCA was "Introducing SCA" by David Chappell.

The Guide is presented with a number of good examples, many dot-point lists and a huge number of references to other technologies and tools. A glossary of acronyms would have helped.

Writers on SOA seem to divided between those that focus on Web Services and those that embrace the diversity of different ways of doing SOA. The Guide authors (ten of them) are from the latter category. A number of alternate technologies and supporting technologies are discussed.

In conclusion I can recommend the SOA Practitioners Guide to anyone wanting to get a wide-ranging survey of current practice in SOA and software development.

Reference:

Durvasula et al., SOA Practitioners Guide, Sept 2006, http://colab.cim3.net/file/work/SOACoP/2007_05_0102/SOAPGuide/

Chappell, David, Introducing SCA, July 2007
http://www.davidchappell.com/articles/white_papers.html

SOA is not About Integration

I am reading "SOA Practitioners Guide" which is authored by a group of ten SOA Practitioners including Surekha Durvasula. This is available on the internet from
http://colab.cim3.net/file/work/SOACoP/2007_05_0102/SOAPGuide/.

I was interested in quote in the executive summary

"Traditionally, IT works with the business owners, who are influenced by application vendors. This results in IT strategies that are application or integration-focused." (Durvasula et al Pt1, p.6)

What this implies is that SOA is not integration-focused. This is an important point. In early days of a company's SOA maturity the impetus behind using Web Services or some other service technology may be to integrate applications. This is not an architectural approach. SOA is not a glue to stick applications together in an ad hoc fashion. It is an architecture in which a portfolio of applications can be built. To focus on the integration is tantamount to focusing on the siloed applications.

A quote from Erl (Ch 3.2)

Contemporary SOA supports, fosters, or promotes:
· vendor diversity
· intrinsic interoperability
· discoverability
· federation
· inherent reusability
· extensibility
· service-oriented business modeling
· layers of abstraction
· enterprise-wide loose coupling
· organizational agility

Integration does not get a Guernsey here. This is consistent with most benefits reported for SOA. Agility and Reuse are the big catch-cries.

What about 'interoperability' though? Is that just 'integration' in another guise? According to Wikepedia

The IEEE defines interoperability as …the ability of two or more systems or components to exchange information and to use the information that has been exchanged.

This sounds awfully like integration to me, but fortunately the issue is clarified a little later in the Wikepedia entry.

According to ISO/IEC 2382-01, Information Technology Vocabulary, Fundamental Terms, interoperability is defined as follows: "The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units".

James Snell (2001) puts this in web services terms

The fundamental goal of interoperability in Web services is to blur the lines between the various development environments used to implement services so that developers using those services don't have to think about which programming language or operating system the services are hosted on.

While integration is about passing information from one system to another, interoperability is getting services operating together despite being built in different ways. We do not integrate services, they interoperate as parts of a system. In what Erl calls contemporary SOA (which is based on Web Services) the services are intrinsically interoperable. This means services interoperate because they are part of the SOA not because we have built these services specifically to be interoperable.

I have purposely drifted from talking about integration to interoperability. I am presenting at a conference shortly and I wanted to explore a nagging feeling I had that the title of the conference "Achieving Interoperability in Systems Architecture" might somehow be antithetical to SOA. The original name of the conference was going to be "Capitalisng on Service Oriented Architecture".

I conclude that achieving interoperability is a valid aim for an enterprise architecture to have. This should be intrinsic interoperability and not ad hoc interoperability. Similarly ad hoc integration is not the aim of an SOA. The only objection I might have to the conference title is that it narrows the focus somewhat. This will not affect my presentation significantly.


References

Ark Group, Conference, Achieving Interoperability in Systems Architecture, http://www.ark-group.com/home/xq/asp/eventid.0CD5BD30-31D1-4E2E-AD40-50D4178087F5/qx/events/event.htm

Durvasula et al., SOA Practitioners Guide, http://colab.cim3.net/file/work/SOACoP/2007_05_0102/SOAPGuide/

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

Snell, James, Web Services Interoperability
http://www.xml.com/pub/a/2002/01/30/soap.html, January 30, 2002

Wikepdia on Interoperability, http://en.wikipedia.org/wiki/Interoperability