marCh 2008 · Service Architecture and Engineering ISSN 1745–1884 marCh 2008. Editorial Assembly – The Final Frontier Separation of software manufacturing and assembly is an important

CBDIJournal2 Editorial

Assembly – The Final Frontier?

4 SOA Methodology ReportService Composition

One of the key ideas of SOA is that of assembling services into solutions. In this article, we shall lay out some of the

key concepts and patterns of service composition, and provide some strategies for managing service design that

enables reuse and assembly. We shall also look at some example technologies that enable composition and assembly.

By Richard Veryard

16 SOA Best Practice ReportSharing and Reuse Patterns

The provision of shared services is often put forward as one of the core motivations for adopting SOA, as an efficient

mechanism to deliver business consistency and reduce costs. However, to be really effective, reuse must be addressed in

many ways and at many levels. Services are not a substitute for software reuse, rather an important architecture and

design approach that complements more conventional practice. In this report we look at the broader topic of

sharing and reuse and provide pattern based guidance.By Lawrence Wilkes

Independent Guidance for Service Architecture and Engineering

ISSN 1745–1884

marCh 2008

Editorial

www.cbdiforum.com

Assembly – The Final Frontier

Separation of software manufacturing and assembly is an important concept that is crucial to delivery of SOA goals. However we need to be really careful not to jump to conclusions about what assembly really means.

I note Eric Newcomer’s comments1 in which he warns against parallels with Henry Ford’s concept in which assembly is portrayed as the easy part of the process. Rather Newcomer suggests “The Ford analogy has played out in software typically by positioning the assembly problem as the easy part of the job and creating reusable services for assembly as the hard part of the job. I can’t tell you how many times I’ve heard business process modeling and orchestration tools pitched at “business analysts” only to discover the proper use of the tool requires someone who can actually code. But almost by definition the Ford analogy can’t work. You cannot really get lower skilled, untrained developers to tackle sophisticated problems such as component reuse. They can create simple objects incorporating business logic, and to use one description, the plainer the old Java object (POJO) the better.”

Now whether Newcomer is right about the service creation task (supply side) is another matter. Just think about issues of abstraction, generalization and concurrency to name just a few. Frankly I don’t think the POJO will get you too far. But he is right about assembly insofar as it is a complex area – and it’s very hard to generalize.

One of the challenges for Service Assembly is that business unit developers may have a hard time consuming services for all sorts of reasons2. They may be the wrong granularity, there is no governance, or the right services don’t exist. So the conventional response to service based solution assembly is to layer even more complexity into the stack comprising more middleware, orchestration tools and portals.

But the correct response is an architectural one – if a service is suitably generalized, abstract and genuinely loose coupled, and conforms to a sensible reference architecture framework, it can be easily consumed to support many different contexts.

Assuming that this is the case, there is considerable merit in the idea of a client side programming model that allows us to implement process logic and easily make asynchronous calls to the server while managing the presentation of the Web Page, without all the additional reuse infrastructure complexity that is becoming ubiquitous3. This is the premise behind mashup tools such as AJAX, which permit the easy demand-side composition and consumption of services with the minimum additional infrastructure, particularly for relatively simple or narrow focused applications and processes.

We maintain a healthy skepticism

around assembly and composition. Like all enterprise computing challenges, there is no

free lunch

cbdi journal © Everware–CBDI Inc, March 2008 �

“AJAX, shorthand for Asynchronous JavaScript and XML, is a Web development technique for creating interactive Web applications. The intent is to make Web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire Web page does not have to be reloaded each time the user makes a change. This is meant to increase the Web page’s interactivity, speed, and usability.” Source: Wikipedia.

But beware! A primary issue with composite applications and mashups will also apply to AJAX based service consumption – it’s essential to avoid coding “business” logic into the client layer. The need for a solid reference architecture is paramount. The reference architecture must provide clear guidance (policy) on the purpose of each layer, permitted behaviors and dependencies. The same reference architecture must also guide the identification and design of services so they provide a useful capability that can be easily reused and specialized with the minimum amount of overhead. Some may call this granularity, but in reality it’s nothing to do with size, it’s all to do with creating designs that are fit for purpose.

The second major concern with demand-side composition is that of security. IBM has a mashup security initiative called SMASH, and is donating the code to the OpenAjax Alliance. Hopefully this will stimulate other initiatives in this area.

The third major concern is configuration and testing. How do you manage and test all the combinations of services that are brought together dynamically from multiple disparate parties?

Looking forward, we expect growing interest in more complex composition. We use the term collaborative composition to refer to composition that is not directed from a single point of control – either from the supply side or from the demand side – but needs to be negotiated between multiple players. This creates what researchers at the SEI refer to as a double challenge – the challenge of agility and the challenge of governance.

However we ourselves maintain and recommend a healthy skepticism around assembly and composition, that like all enterprise computing challenges, there is no free lunch. Mashups, collaborative compositions and the like will work for

simple assemblies. But for everyday commercial transactions it’s going to be more complex.

In our Journal articles this month we explore this topic area from two perspectives. First Richard Veryard examines the broader space of Service Composition and provides some methodological guidance that hopefully will help you sort the wheat from the chaff. He also looks at the various standards, protocols and some examples of the technologies. Secondly Lawrence Wilkes looks at patterns for reuse.

Noteshttp://blogs.iona.com/newcomer/archives/000554.htmlJohn Crupi, AJAX plus SOA – the next killer app? SOA World Magazine, September 2007. http://webservices.sys-con.com/read/329790.htmDavid Sprott. SOA plus AJAX? CBDI Forum February 2007. http://www.cbdiforum.com/cbdi_blog/?filter=full&id=48&display=SOA%20PLUS%20AJAX?

David Sprott, Everware-CBDI, March 2008

1.2.

3.

SOA Methodology Report

� cbdi journal © Everware–CBDI Inc, March 2008

By Richard Veryard

Service CompositionStrategies for Achieving Rapid Assembly of Applications and Business Processes

One of the key ideas of SOA is that of assembling services into solutions. In this article, we shall lay out some of the key concepts and patterns of service composition, and provide some strategies for managing service design that enables reuse and assembly. We shall also look at some example technologies that enable composition and assembly.

BackgroundIn previous articles1 (April 2006, November 2007), I’ve talked about some aspects of the emergence of lightweight solutions, based on simple service composition. Dion Hinchcliffe calls this the “DIY Phenomenon”, and has published a taxonomy of DIY approaches (see Table 1).

Meanwhile, there is some effort among SOA platform vendors to produce tools and platforms to support service composition. There is wide divergence between the various tools and platforms on offer, some of them adhering to a range of different standards (including BPEL and SCA), while others appear to be entirely proprietary.

Simple Medium Complex

What? Web desktopsBadgesBlogsWikisFeedsEnterprise 2.0

Simple mashupsSituational appsWidgetsWOA

Web appsEnterprise mashupsComposite appsOffice 2.0SOA

Who? Anyone Expert users Developers

How Many? hundreds of millions tens of millions Millions

Variety & Output Complexity & Sophistication

Table 1: Tracking the DIY Phenomenon (source: Dion Hinchcliffe2)


What is Service CompositionWhat exactly is the relationship between Composition, Assembly, Mashup, Orchestration, Encapsulation and other related concepts?

In this section, we shall define service composition and related concepts.

Is Composition the same as Orchestration?

Is Encapsulation Absolute or Relative?

CompositionComposition means putting two or more pieces together to create something new. What is created is a “composite” – for example, a composite data object, a composite service or whatever. But what do we call the original pieces? The obvious

•

•

term – “component” – would be misleading, because we aren’t always talking about things that are valid components in the more precise sense that has become widely accepted in software engineering over the past ten years or so. Nor can we call them “atomic” or “elementary”, because they may also be composites in their own right. So we shall call them the “composed” or “composable” parts.

We can classify composition in two ways – by what goes in and what comes out. Firstly, let’s classify composition by what is produced. Do we end up with a service, a complete solution, or something else? See Table 2.

Composite May be composed from Using Comments

Composite application

Process servicesData servicesUser interface

Presentation composition (Mashups)

Recommended standard – MDA plus SCA. (SCA is used to assemble work activities with resource lifecycles).

Composite service

Web servicesUnderlying services (which may not be web services)

Process composition (BPM) Recommended standard – SCA plus BPELBPEL can only orchestrate web services – so if we want to include other service-based assets, we may need to use adapters and other mechanisms to present these assets to BPEL in web service form

Composite object

Database tablesOLAP enquiriesEvent stream

Information composition (EII) Adapters / pipes / ETLRelational joinsMaster data management

Table 2: Classifying Composition by Result

� cbdi journal © Everware–CBDI Inc, March 2008

Service Composition continued . . .

Secondly let’s look at what goes into a composition – what things are composed together.

When we talk about service composition, we may be talking about homogeneous service composition – assembling two or more services to make a new service. But some composition platforms also support heterogeneous composition – for example, SAP Visual Composer allows for UI elements, business logic and data connections to be included in what it calls a “composite view”.

We often want to create compositions of compositions. Thus we may have a composition hierarchy, similar to a manufacturing bill of materials. And just as in manufacturing, we need to know not just which composed parts are composed, but how many instances, and how they are composed.

How are things composed? We are not usually talking about creating a single physical artefact to implement the composition. Instead, it is usually a question of specifying the composition at design-time, so that the composition itself actually occurs at run-time. There may never be a physical instantiation of the composite – instead, it only exists in some virtual distributed or federated world.

The logic of the composition may be specified in a script. For example, relational joins between data objects may be specified in a query language such as SQL, while procedural joins between services may be specified in an orchestration language such as BPEL.

Another important question for composition is the degree of abstraction. For example B might be “Google Maps” (the name of a specific service) or it might be “<any> maps” (where <any> denotes a set of similar services).

Some purists might argue that the identification of “Google Maps” does not belong in the Specification View – that “Google Maps” is merely one possible implementation of “<any> maps”. Therefore the specification view should define the composition using “<any> maps” as the abstract name of the service, and the selection of Google as the service provider belongs either to the implementation view or to the deployment view.

In the implementation view we then have a choice of binding strategy. An early binding strategy would fix the selection of “Google Maps” at design time, whereas a late binding strategy would leave the selection of “Google Maps” to some dynamic policy to be executed at run-time. (The choice of binding strategy depends on the nature of the composition and what

Isogeneous Putting together two or more instances of the same type. For example, marriage creates a composite object called “Married Couple” from two instances of “Person”. (This may be relevant to a CRM system, which may help to coordinate a company’s communications with husband and wife.) Or a banking ATM system may create a composite object called “Simultaneous Withdrawal” from two geographically separated instances of “Withdrawal”. (This would be relevant to fraud detection.) We may also have compositions that involve multiple instances of the same service being invoked. For example, in a manufacturing system, a bill-of-materials service might be invoked recursively

Homogeneous Putting together two or more objects of the same metatype. For example, assembling several services to produce a new service. Or a relational join between two data tables

Heterogeneous Putting together objects of different metatypes. For example, putting together a service wrapper, a data object and a legacy system

Table 3: Classifying Composition by Content

Composition Specification View Implementation View Deployment View

C=A+B C offers (integrates) the combined functionality of A and B

C has implementation dependencies on A and B

C exists as a real or virtual artifact at run-time (if not before), containing or linked to A and B

Table 4: Composition from different viewpoints


exactly you are trying to optimize.) But in any case, these purists would hold that the binding strategy belongs to the Implementation View and/or the Deployment View, not to the Specification View.

In practice, of course, there is often only one viable implementation of a given service, and pragmatists will wish to fix this in the specification. This is not helped by the fact that the technology for dynamic run-time binding is immature, both operationally and in terms of governance, which means many organizations are currently unwilling to contemplate this.

EncapsulationThe opacity of an interface. Encapsulation is often taken to mean that some person is not supposed to be able to see inside the design – where “inside” effectively means the implementation and deployment views. The opposite of encapsulation might be “design leakage”.

It is also taken to mean the converse: that a person responsible for the insides of a service (implementation and/or deployment) shouldn’t know anything about how the service is going to be used, lest this knowledge corrupt the technical purity and perfection of the service implementation.

Note that both of these define encapsulation relative to a particular person or role. (There are different degrees of opacity, from different viewpoints.)

The unit of use is the operation. The user of a service (which may be human or software) only needs to

•

know the specification of the operation(s) being used. (The user doesn’t even need to know that several operations are actually performed by a single service.)

The unit of delivery is the service. The purchaser of a service needs to identify and acquire whole services.

If a service calls other services, then the availability of these other services is a precondition for a successful deployment of the service. The installer, therefore, needs to know what calls are made to other services.

Most of the people who interact with a service can be satisfied with the above. Only the service engineer, charged with building, inspecting or modifying the internals of a service, needs to look inside it.

Although encapsulation is sometimes thought of as absolute (either it is or it isn’t, regardless of perspective), within a service-oriented paradigm it makes more sense to regard encapsulation as relative.

Orchestration versus Incremental CompositionSome researchers have proposed simpler alternatives to orchestration, which would be declarative rather than procedural. For example, the concept of Incremental Composition has emerged from the GIS (Geographic Information Systems) field. But see Table 5.

•

•

•

Figure 1: Encapsulation

8 cbdi journal © Everware–CBDI Inc, March 2008


Orchestration Incremental Composition

Description Orchestration composes web services in terms of process flow.

Incremental Composition composes web services by declaring pairwise composition of lower-level services.

Advantages Support for various flow patterns, including sequential and parallel processes as well as loops.Easily visualized through process flow graph.

Business process logic contained in a separate script (BPEL file), which clearly separates the process logic from the description of the service.

Better encapsulation

Easily understood by developers with an OO background. Visualized in terms of a composition hierarchy.

Interchangeability at each level. Scalable and flexible. Straightforward reuse

No need for a workflow script

Disadvantages The whole BPEL process is reusable, but you can only reuse the subassemblies if these are also defined as BPEL services (with associated WSDL description).No explicit concept of components (though components can be emulated)

Each component consists of at most two services – therefore difficult to understand complex compositions. Intermediate subcomponents may not have any business meaning, and may not be interchangeable in practice.

Table 5: Orchestration versus Incremental Composition [Source: Nieto et al]


How Service Composition Produces Value

Economics of ScaleThe most obvious benefit of service composition is that it promotes reuse, by making it possible to build solutions and coarse-grained services from highly reusable small-grained decoupled services.

Economics of ScopeIn addition to reuse, service composition also promotes repurposing – using services in multiple contexts, thus improving flexibility.

One of the important prerequisites here is a robust service architecture and reference architecture. “Categorization supports composability by clarifying the roles of the different components, thus helping reason about component interrelationships.”3

Economics of GovernanceFinally, the latest service composition tools and techniques provide the ability to use best-of-breed services from multiple sources, thus allowing user organizations to escape from a single proprietary model

For example, use of adapters allows the composition of services from SAP and Oracle, rather than being limited to a single vendor.

Box 1Example: CalculateSalesTax

Invoked from several processes including Sales Forecast, Cash Flow Forecast, Order, Invoice and Quote. Sales tax regulations may change, and we should be able to anticipate different types of change. Some changes are simple substitution – “increase from 8% to 10%”. However, a very common pattern of change involves an increase in differentiation – “increase charge to £25 pounds if cartype = gas-guzzler and purchase date is > 2007 and tax due date > April 4th”. This means that the CalculateSalesTax needs some additional context or other information, not previously required. There are several possibilities –

1. Each process needs to be updated in order to pass additional contextual information to the CalculateSalesTax module.

2. Each process already passes a rich parcel of contextual information to the CalculateSalesTax module, most of which is ignored by the module. But when the CalculateSalesTax module needs some additional information, it is possible that this information is already included in the parcel.

3. The CalculateSalesTax module gets its contextual information from some other source, so the processes do not need to be changed. (Of course, one way of implementing this is that the process acts as a carrier – picking up a generic string of XML from somewhere and passing it on to the module.)

With a good SOA design, many changes will be forward compatible, and this is a key benefit of SOA technology. But even with incompatible changes, you still gain in terms of level of effort with a centralized service event though you have to change the process consuming the service.



Approach Description Example Platforms Comments

Solution Assembly Assembling a complete solution, using UI elements, services and other assets.

NextAxiomSAP CAF + Visual Composer

There are currently no standards that cover the whole area, so the available tools vary widely in style and functionality.

Process Composition A pure BPEL engine only handles web services.

BizTalk Adapters may be required to complement the BPEL engine.

Integration Converting syntax and semantics to aid integration and interoperability.Optionally may be driven by Master Data Management.

BEA AquaLogicI-wayYahoo Pipes

Adapters may perform several different functions:

Rendering legacy assets as web servicesRendering BPEL-generated services in other forms for alternative output channelsBridging between multiple SOA platforms

•

•

•

Table 6: Alternative Approaches to Service Composition

Figure 2: Alternative Approaches to Service Composition

Service Composition Architecture

cbdi journal © Everware–CBDI Inc, March 2008 11

Recursive Service SpecificationDecomposition and composition are recursive. We identify a large-grained service, and build a (rich) service specification that identifies one or more smaller-grained services, and then we build a service specification for each of these, and so on until we reach the smallest or lowest level of service. We then assemble them back and check that we have a solution (on paper) that completely satisfies the original business requirements. This is the first V in Figure 3. Then we switch from the world of models to the world of software – acquiring the lower-level services, creating and testing the units, then the sub-assemblies, and finally the whole composite service or solution. This is the second V in Figure 3.

In practice, many system testers will modify this approach by using stub services. A stub is a dummy version of a service which returns hard-coded or manually entered values, allowing

the overall composition and integration to be tested earlier in the testing process, rather than leaving the discovery of the biggest and most difficult problems until the end. This is of course an old software engineering trick, but is as valid as ever in the SOA world.

TestingHow do we know whether a given composition is going to work, and what kind of service level is going to be produced? It would be useful to have some way of predicting this from the solution/assembly model, but we currently lack tools and methods to support this. The alternative would seem to be to build the composition and run volume tests against it, to find out whether it delivers an acceptable level of performance. But for internet-scale applications, this approach would be immensely costly. (Who on earth has a test environment with

Figure 3: Double-V model

Service Composition Process

Decomposition and Composition



millions of machines?) So in practice, services are often put into production with limited knowledge of how they will perform, and the emphasis switches to close performance monitoring and rapid deployment of additional resources where required. It would certainly be useful if we had decent simulation tools, to predict the behaviour and performance of complex service assemblies.

Directed Composition and Collaborative CompositionDirected composition means the composition is controlled from a single design point. Most approaches to composition assume this. However, in the world of Web 2.0 and mashups, we can no longer always assume this. Instead, we have to consider the possibility of collaborative composition, in which the composition process is itself distributed or federated.

Of course, this also raises important questions about the governance of composition.

Service Composition Standards and ProtocolsIn this section, I shall briefly discuss the support for the concepts and methodology of service composition from the prevailing standards and protocols in this area – notably SCA and BPEL. There are several competing standards and protocols covering service composition.

Roughly speaking, we can regard SCA (Service Component Architecture) as a standard for what in SAETM we call Automation Units. In Figure 4, MyValueService is implemented

as an automation unit (“component”), which is a composite of CustomerService and StockQuoteService. MyValueService contains references to CustomerService and StockQuoteService – these references are linked to the services themselves using “wires”. We can regard a wire as an abstract implementation of a dependency, which will be replaced by a physical binding, when the composition is deployed.

There are some minor differences between the SAETM Automation Unit and the SCA Component. One question that comes up (and this has been incorporated into UPMS4) is the idea of 3-way (or more) services. That is, services that also have a third party as part of the protocol with the Consumer. This is different than just behavior required in order to implement the Service. It’s actually defined as part of the protocol. In these situations you can’t really tell which direction the Port is because there are both Provided and Required interfaces on it.

SCA and BPEL are primarily used within the Implementation View and Deployment View, but there is a minor impact on the Specification View, as shown in Table 8.

Standard Body Purpose Issues

SCA OSOAOASIS Open CSA

Service composition and deployment

Focus on implementation and deployment views.

WSDL W3C Service description WSDL supports bi-directional interfaces but these are not permitted by WS-I.

WS-I Basic Profile

WS-I Provides interoperability guidance for web services

Doesn’t permit bi-directional interfaces.

BPEL OASIS Orchestration – creating a web service that orchestrates a number of lower-level web services (known as “partner” services).

Focus on implementation view.Limited to single point of control – in other words, supports orchestration but not choreography.

UPMS OMG UML Profile and Metamodel for Services

Under development

SMASH OpenAjax Alliance Mashup security New – not yet widely adopted

Table 7: Relevant Standards

Figure 4: Automation Unit (SAETM)

cbdi journal © Everware–CBDI Inc, March 2008 1�

Standard Aspect Specification View Implementation View Deployment View

SCA Composition Some aspects of the composition may be part of the specification (for example if you want to specify or constrain which components you are going to link to.)May be coded in WSDL.

In the implementation view, we specify how the composition is assembled.May be coded in BPEL

In the deployment view, we configure the run-time behaviour of an implementation, by setting various SCA values. These values are decoupled from the implementation itself, thus increasing flexibility and reuse. (The configured implementation is called a “component”.

SCA Encapsulation / Promotion

A composite service may expose the operations of its component services.The specification view defines what operations (behaviors) are available.

The implementation view defines how these operations are managed by a set of implemented services.

The deployment view defines how these operations are distributed and delivered across the network.

SCA Reference and Binding References are resolved within a composite using wires.

Binding must be defined for dependencies across multiple SCA domains.

Binding may be determined at run-time within a single SCA domain.

SCA Policy Intent Within SCA, the specification view of policy is provided by policy intent.Some core intents (such as security) may be standardized within the SCA platform. However, the specification view is supposed to be platform independent, and so these core intents must still be defined somewhere in the specification view, possibly in a common policy area.

The implementation view inherits the (business-driven) policy intents from the specification view.The implementation view may define some additional (technology-driven) policy intents.Policy intents are implemented using a lower-level policy description known as a policy set.Under some circumstances, policy sets may be defined in the implementation view. But this is not generally recommended – see next column.

Policy sets are technologically specific. The recommended practice within SCA is therefore to leave the policy sets to the deployment view.

BPEL Orchestration The external orchestration of a business process (BPMN) may be used to identify and specify process and other services that will be invoked within the process.

The internal orchestration of a process (or other) service is defined within the Implementation view.Use of BPEL belongs within the Implementation View.

BPEL code is deployed onto a BPEL engine.

Table 8: Multiple Views of SCA and BPEL

1� cbdi journal © Everware–CBDI Inc, March 2008


Service Composition TechnologiesThere is a wide range of products and services currently available to support various aspects of the composition (and decomposition) process. In this section, we only have space to mention a small selection of these products and services.

BizTalkMicrosoft Biztalk Server is now nearly ten years old, which makes it one of the oldest process engines on the market. Microsoft has participated actively in the development of BPEL (which represented a merger between Microsoft’s XLANG and IBM’s WSFL).

Although Microsoft now provides a series of adapters with Biztalk, it originally left the provision of adapters to partners. This created an opening for companies such as iWay Software.

iWayiWay Software is a wholly owned subsidiary of Information Builders, which older readers may remember as the developer of a fourth-generation language called Focus (now reincarnated as WebFocus).

iWay concentrates on providing adapters, and on composing large-grained services from smaller services. It does not compete directly with the BPEL engines, and does not do solution assembly. iWay offers a large number of specialized adapters.

iWay provides a way to be agnostic about web services standards – producing services that operate on multiple service channels and interfaces (JCA, XML, EDI, and so on). To avoid the architectural complexity of having a separate service instance for each channel, iWay decouples the source service from the multiple interfaces. The source service is one half and the multiple interfaces are other halves that can be paired with the source. iWay believes this is the simplest approach.

BEA AqualogicIn contrast to the iWay use of adapters, BEA Aqualogic uses XQuery as a complicated language for the manipulation of XML documents. AquaLogic creates a “virtual” XML database and uses Xquery to “join” data across multiple sources. This works out the same as using SQL and making every data source look like a relational table.

One concern with this approach is that too much of the matching and mapping of data at a semantic level occurs within the XQuery statement and may not be sufficiently flexible or reusable. This approach is useful for data extraction, but may

not be powerful enough for composed services at a business level, which also require insert, update, and delete functions across multiple systems.

It is often much easier to handle more complex composition within a simplified process flow with conditionals and looping, and the ability to manipulate and interact with data from multiple systems via APIs.

SAP CAF and Visual ComposerAt the solution composition end, the available platforms include SAP’s Composite Application Framework and Visual Composer, which supports mashups, Visual Composer is essentially a CRUD-oriented tool, while CAF is about sequencing steps in different SAP solutions. This provides a reasonable approach for Mashups. VC is actually quite similar in appearance to Yahoo Pipes, which produces mashups by performing composition at the level of the RSS or Atom feed.

There are many business problems that can be solved with a CRUD oriented presentation composition capability, but the remaining problems are going to need something a little more sophisticated. The CRUD approach is also brittle in the face of operational problems.

NextAxiom HyperserviceNextAxiom offers an impressive range of products that appear to cover the whole space – albeit in a fairly non-standard way. For example, NextAxiom eschews the use of XML for the sake of performance, although one wonders whether this also compromises flexibility.

ConclusionsThis area has been evolving over a fairly long time span, and some of the products and services have a distinctly “legacy” feel, despite the SOA gloss. Few of the vendors reference standards such as SCA, and the modeling and design tools offer a strange collection of notations. There is also a disappointing lack of interoperability between the products, and a reluctance in some quarters to exploit technologies such as master data management.

However, these problems will undoubtedly be resolved in the near future, and we may expect composition to become increasingly mainstream and mature.

AcknowledgementsThanks to John Taylor (CTO of iWay Software) and Jean-Jacques Dubray.


ReferencesJean-Jacques Dubray, Composite Software Construction, InfoQ 2007. http://infoq.com/minibooks/compositesoftware-construction

Adan Mercado Nieto et al, A Comparison between Incremental Composition and BPEL (EDU-GILA working paper, June 2004.)

Chung-Yeung Pang, SOA with MDA: Re-Engineering A Legacy Enterprise IT System, March 2007. http://soa.sys-con.com/read/346397.htm

NotesThe Lightweight Enterprise (April 2006) – http://www.cbdiforum.com/secure/interact/2006 – 04/The_Lightweight_Enterprise.php. Web 2.0 and Enterprise Architecture (November 2007) http://www.cbdiforum.com/secure/interact/2007 – 11/web_2.0_enterprise_architecture.phpDion Hinchcliffe, Tracking the DIY Phenomenon, February 2007. http://blogs.zdnet.com/Hinchcliffe/?p=81Shy Cohen, Ontology and Taxonomy of Services in a Service-Oriented Architecture, Microsoft Architecture Journal 11. http://msdn2.microsoft.com/en-us/arcjournal/bb491121.aspxUPMS Unified Profile for Modeling Services. http://www.omg.org/cgi-bin/doc?soa/06-09–09

1.

2.

3.

4.


SOA Best Practice Report

By Lawrence Wilkes

Sharing and Reuse Patterns

The provision of shared services is often put forward as one of the core motivations for adopting SOA, as an efficient mechanism to deliver business consistency and reduce costs. However, to be really effective, reuse must be addressed in many ways at many levels. Services are not a substitute for software reuse, rather an important architecture and design approach that complements more conventional practice. In this report we look at the broader topic of sharing and reuse and provide pattern based guidance.

IntroductionServices can enable reuse if they have certain characteristics that make them reusable. Interestingly some of these characteristics (or conformance with principles) also apply to more conventional software reuse of components, code blocks etc,

Generalized functionality

Modular (interchangeable without disassembly)

Autonomous (minimum dependencies)

Encapsulated (component)

Loose coupled (full separation of concerns enables pluggability)

Composable (designed to be part of one or more assemblies)

Documented (so others can understand it)

Documented interface (offers rich behaviorable specification)

Discoverable (so others can find the design or executable)

It’s important to remember that these characteristics are all discretionary – they represent good design practice. Also some characteristics relate to any artifact type, but some like documented interface and encapsulated, only apply to components. But there are other characteristics that are specific to a service

Discoverable (so others may find the endpoint and invoke it)

Invocable (available for run time reuse without deployment)

•

•

•

•

•

•

•

•

•

•

•


What’s interesting to note is that all the design related characteristics are equally applicable to design artifacts and services. Not surprising you may say, because these characteristics are implemented “by design”.

So our thesis in this article is simply to remind, explore and promote the idea that SOA is about more than simple services. Well formed services deliver reuse because they conform to certain principles, and this is equally true of all units of design. But reuse and or sharing may be achieved in many different ways.

We shall explore how these units of design may be appropriately reused or shared. But remember this only happens if the design is fit for purpose.

Reuse and Sharing in ContextWe recall the well known F1000 company that spent 2 years building a set of core business services. The services were fit for purpose, insofar as they met the business needs as defined by a core team of business analysts. As the services were rolled out to the project teams there was a high level of resistance because the services had been designed for reuse in a very simplistic manner. Further there was no guidance on matters such as assembly, composition, extension, release and version management. So the project teams took the source code and created their own specific versions! Effectively destroying the business case for the original core business service investment.

There was some attempts subsequently to develop new versions that incorporated LOB specific functionality, but the cost of incorporating new versions was considered to be unjustifiable.

We think it’s too easy to blame organizational, political, and cultural problems for this situation. What’s needed is a structured approach to sharing that recognizes a range of situations that require different solutions. For example copying certain classes of service may be entirely reasonable. Likewise an extension strategy whether through code extension, schema extension, composition etc all need to be thought through and considered in context with the business case.

Part 1 of this report proposes some patterns for sharing and reuse, in order to establish some common understanding. In Part 2 we suggest candidate policies relating to architecture layer.


Sharing and Reuse Patterns continued . . .

Part 1: Software and Service PatternsLet’s start with some basic patterns. Most readers will understand the notion of software reuse, where source code, software components or similar artifacts are copied into many different software assemblies. There are two variations on this. White-box reuse where the source is visible and accessible to the re-user, and black-box reuse where it is not. See Box 1.

Pattern: White Box Reuse

Summary: The software providing the functionality required is reused (as a component or code block) in many software assemblies, by copying the source code (or similar white-box artifact).

Synonym: software reuse, subroutines

Problem: Common functionality is re-invented in each software project leading to higher overall cost of development and inconsistent behavior in each instance.

Solution: The common functionality is developed once and then copied into each software assembly that requires it.Typically this is managed as a new asset though source code libraries, and the use of Source Code Management (SCM) software.Maintainability can be improved through configuration management products and techniques.

Figure 1: White Box Reuse

Advantages: Reduced implementation cost. Improved consistency. Time to solution. May be more performant than component and service-based approaches. Can be widely distributed without creating dependencies between instances. Access to source code allows variations to be developed (but with negative consequences for consistency and maintenance)

Disadvantages: This creates many instances of the source code. Over time there can be a tendency (intended or unintended) for them to diverge as maintenance takes place. Direct access to of the source code, and just visibility of its behavior tends to lead to very tight coupling making it difficult to replace the implementation with an alternative.

Box 1: White Box Reuse


The disadvantages created by visibility of, and access to the source code can be overcome by distributing the functionality in a “black box”, where the interfaces to the software provide the only visible indication of the functionality and the contents cannot be changed. See Box 2.

Pattern: Black-box Reuse

Summary: A software component (or similar black-box artifact) is reused in many software assemblies, by copying the component.

Synonym: Component-based Development, component reuse

Problem: Common functionality is re-invented in each software project leading to higher overall cost of development and inconsistent behavior in each instance. Making source code (or similar artifact) available for reuse leads to inconsistency and difficulties in maintenance as the instances diverge.

Solution: The process of software reuse is improved by following a Component-based Development approach that encourages the encapsulation of the common functionality into a component that is then only accessed via the component interfaces, not by directly branching to a code location or database within the component. When the component is delivered as a “black box” there should be less divergence between the instances over time. However, it may still give rise to multiple inconsistent versions being in operation at the same time.This is also a related pattern where the software assembly itself containing the common functionality needs to be instantiated many times, such as deployed onto multiple nodes of the network, or packaged software that is distributed to many organizations.

Figure 2: Black Box Reuse

Advantages: Reduced implementation cost. Improved consistency. May be more performant than service-based approaches. Can be widely distributed without creating dependencies between instances.

Disadvantages: Instances can still diverge as multiple versions of the component come into use. Dependency on common technology platform. Requires upfront investment to deliver a generalized component that can be widely reused. The black box may not be an exact match for the functionality required, leading to white box reuse.

Box 2: Black Box Reuse



In many cases, the common functionality is not duplicated by copying into each assembly, but must be shared by many assemblies. This is more often the case when the data encapsulated by the component must be shared by many systems. See Box 3.

Pattern: Shared Software

Summary: A single instance of a software artifact is shared by many other software assemblies

Synonym: Reusable Component

Problem: Common functionality, and the data it encapsulates, is duplicated leading to inconsistencies and higher costs. Multiple instances of the common functionality become inconsistent over time. Replication of data introduces reconciliation delays, and inconsistent data leads to business process failure, and potential drop in customer satisfaction

Solution: The common functionality and data is provided as a single instance of a shared component, that is accessed by all software assemblies that require it. The shared component provides access to the shared data it encapsulates.

Figure 3: Shared SoftwareAdvantages: Reduced implementation cost. Improved consistency. Single source of information. No divergence between instances.

Disadvantages: High volumes may make it less performant. Dependency on common technology platform, or middleware. Creates dependency on the shared software which make increase risk and degree of coupling. For example, dependency on common technology platform, or middleware. Or dependency on a specific implementation of the common functionality. The single instance can become a single point of failure, though appropriate provision for failover safeguards against this.

Box 3: Shared Software

cbdi journal © Everware–CBDI Inc, March 2008 21

Some of the disadvantages of using shared software can be overcome by using a shared service. See Box 4.

Pattern: Shared Service

Summary: A single instance of a provided service is shared (used) by many different service consumers

Synonym: Reusable services

Problem: Shared software creates unwanted dependencies. See disadvantages of the Shared Software pattern

Solution: The shared software is only accessed via a published service. The service is then used (shared) by many different service consumers.

The shared service is designed so that it does not “leak” any implementation detail, as well as using a combination of message based communications, XML and Web Service protocols to reduce implementation-specific and technology dependencies.

The software that is shared via the service is termed an automation unit by CBDI Forum in recognition that the actual implementation being shared may take many forms – including being another service, or an existing legacy application.

Figure 4: Shared Service

This pattern is improved when the shared service is provided via a “service broker” that is able to broker requests from service consumers to different automation units depending on context. For example customer information may be maintained in more than one automation unit (e.g. different existing systems). Incoming requests must be routed to the appropriate automation unit based on the customer type. However, this implementation detail is hidden from the service consumer by the service that encapsulates both automation units.

Similarly, the Service may be able to aggregate and consolidate information from several underlying systems.

This becomes a useful pattern for the transformation and consolidation of the software portfolio, as different automation units can be retired, merged, or replaced without impacting the service consumer.

Figure 5: Service Broker Pattern

Advantages: Reduces dependencies (coupling) between providing and consuming software resources. Provides a basis for software portfolio transformation and consolidation. Enables aggregation and consolidation of information

Disadvantages: High volumes may make it less performant. The single instance can become a single point of failure, though appropriate provision for failover safeguards against this.

Box 4: Shared Service



Hence, the software in the automation unit used by the shared service may be exactly the same “Software Component Z” as shown in shared software pattern, but it is now encapsulated behind the service and tightly coupled dependencies are reduced.

However, services are not always shared across the network. There may still be requirements to create multiple instances of the software assembly for distribution, but services might be used within the assembly to provide more flexibility. See Box 5.

Pattern: Service-based Software Reuse

Summary: A service-based approach is used to reuse software components within software assemblies

Synonym: SCA or BPEL components

Problem: Software components once integrated into a software assembly are difficult to replace without impacting the whole assembly. Software components within the assembly are tightly coupled to specific implementations and technologies. Whilst component-based development helps, it is difficult to make real-time upgrades without replacing the whole assembly.

Solution: The software component offers published services. Other software components within the assembly consume (use) the component only via its published services, following the basic service pattern. However, the service is not shared by consuming components in other assemblies, only by the components within the assembly. Consequently there are multiple instances of the service as well as the software component.

Figure 6: Service-Based Software Reuse

The software assembly becomes more of a logical assembly as there isn’t a single executable. Hence the different components still need to be packaged up into a single deployment unit. See also the “multi-deployment” pattern.

Advantages: Improved maintainability of the software assembly. Software component can be replaced in “real-time” without impacting consumers. Can be deployed as multiple instances. The distribution of the components within the assembly could be changed to improve performance for example.

Disadvantages: Components of the assembly might get “lost”. i.e. the integrity of the deployment unit may not be as good as that of a single executable for the software assembly. It may not be as performant as tightly coupled software reuse, though operational platforms are increasingly optimizing this. Instances may still become inconsistent over time.

Box 5: Service-based Software Reuse


Whilst it might seem ideal that each service has its own corresponding automation unit this is not always the case. Data integrity might be simplified when more than one related service is provided by the same automation unit. See Box 6:

Pattern: Shared Automation Unit

Summary: Multiple Services share a single automation unit

Synonym: Shared Implementation

Problem: Data integrity can be difficult to achieve if each service individually encapsulates its own data. For example there may be a lack of referential integrity and difficulty in coordinating distributed transactions.

Solution: A single automation unit provides all the services that have a common data integrity requirement.

Database technology can be used to provide the data integrity automatically.

Data is still “embedded” within the automation unit and should only be accessed by one of the provided services

Figure 7: Shared Automation Unit

Advantages: Data integrity is simplified

Disadvantages: Additional effort to decoupling the services should that be required at some point in the future

Box 6: Shared Automation Unit



Often an existing coarse-grained automation unit might be the most pragmatic way to provide several services. This might be an existing or “legacy” system, or an acquired packaged application (COTS). See Box 7:

Pattern: Service-Based Existing System Reuse

Summary: An existing system (or systems) is reused by building a “wrapper” that provides the capabilities of the existing system via one or more services

Synonym: current system reuse, legacy reuse, package reuse, wrapper, facade

Problem: An existing system contains functionality and/or data that is required in new solutions but it is undesirable or difficult to access it via its existing technical interfaces, as this may create further “tight coupling”

Solution: A “wrapper” is built that provides transformation between the existing system(s) and the required service(s).The wrapper “decouples” service consumers from the existing system(s) by abstracting away any implementation specific detail that might normally be exposed by the technical interfaces of the existing system.The wrapper can also serve to aggregate information and behavior from several existing systems. The wrapper can also provide a more generalized service than the individual existing systems making them more easily shared across new solutions.

Figure 8: Service-Based Existing System Reuse

Advantages: Loosely coupled access to existing system improves overall system flexibility. Aggregation of several existing systems into a single generalized service that is more widely applicable and easier to share. Provides a basis for transformation and reconciliation of the existing system(s)

Disadvantages: The wrapper needs to be separately maintained if changes are made to the existing system.

Box 7: Service-Based Existing System Reuse


In the “service-based software assembly” pattern earlier, the service and its software component within the software assembly may be considered as a unit of deployment in Meta Model terms. However, that pattern considers both the service consumer and provider software as a single entity that is distributed, whereas sometimes the requirement is just to distribute the deployment, which is independent of any potential service consumer. See Box 8.

Pattern: Multi-Deployment

Summary: Many deployments of the same service and automation unit, each access via a different endpoint

Synonym: Distributed services, deployment reuse, virtualization

Problem: A single instance of shared service may not provide the quality of service (QoS) required in terms of scalability and throughput required, or in itself doesn’t have adequate provision for failover. Alternatively, potential network issues of latency, bandwidth or failure make it desirable to place a deployment close to the service consumers on different nodes of the network

Solution: A Deployment is created containing the automation unit. This is copied to multiple processors in a cluster, or distributed to multiple nodes on the network. Consequently each instance has a unique endpoint address. Clearly each endpoint offers the same behaviorEither the service consumer must resolve the address of the endpoint it requires – which may be straightforward where they are collocated on the same network node – or it is the responsibility of some service broker. The broker may be performing the role of a load balancer where the deployment is for scalability, or a broker in the network may always try to route message to the closest deployment instance to reduce latency and minimize network traffic.

Endpoint 1

Endpoint 2

Figure 9: Multi-Deployment

Advantages: Enables QoS requirements to be met. Can still be shared by many service consumers, and assembled into new solutions.

Disadvantages: Managing the multiple instances.


Box 8: Multi-Deployment


Specification PatternsA shared service doesn’t necessarily mean there is only one instance of the service within an organization. Consider the example below. Here there are two instances of a customer service. They both support the same notional business service, are both shared services, but each one only provides information about a discrete set of customers.

Service consumer B needs information from both, and hence must know which customer is accessible via which service. It can be argued that a single service instance is a better solution for this as illustrated within the shared service pattern where a service broker mediates between the different providers and

consumers, but this is not always possible. The benefits of a single service pattern were highlighted in a previous report1.

In this example, whilst service 1 and 2 might be both designated as a “customer service”, is there any guarantee they offer the same signature or behavior (at the operation level)? If they were built individually by the different lines of business (LOB), then possibly not, making life difficult for service consumer B.

To solve this, another kind of reuse or sharing is required that applies at design-time. See Box 9.

Pattern: Shared Service Specification

Summary: Multiple Service instances conform to the same service specification and consequently offer the same signature and behavior.

Synonym: standardized service.

Problem: Different individual services instances support the same business service (in a business model), but offer inconsistent signatures and behaviors.

Solution: Individual services are built to conform to the same shared specification. The Service Specification is decided in advance, and all providers then agree to deliver services that support the shared specification.Though there may be many instances – not just within an organization, but also provided by many different organizations – they all offer the same signature and behavior. They each encapsulate different information that is specific to the particular provider, though this is not always the case.

Figure 11: Shared Service SpecificationAs a simple example many different weather forecasting agencies offer a forecasting service that each conform to the same specification. This might be an industry standard schema, or simply an agreement between multiple agencies. Agencies may differentiate on price, geography, currency, target consumers (shipping, general consumers, business – e.g event organizers, ice cream manufacturers etc)In some markets, conformance with an industry standard service specification may be a condition of entry. See the “Standardized Service” pattern from a previous report.1

Advantages: Consistent service behavior across many providers. Flexibility and choice for service consumers. Reduction in development and maintenance efforts for both provider and consumer. Industry compliance (and certification)

Disadvantages: May require extra design effort to deliver specializations of standard services. A statement of compliance is not a guarantee it is, so may require additional certification activities.


Box 9: Shared Service Specification


Figure 10: Multiple Customer Services

As stated, Shared Service Specification is a form of design-time reuse. White-box and black-box reuse are also examples of design-time reuse – but are primarily applied during the implementation stage of development (black-box can also be run-time reuse).

Some artifacts such as models might be shared or reused at the analysis and design stages before coding begins. Equally, some models may also directly drive code generation (in full or part) and be used in the implementation stage. The models might be architectural, in that they contain several objects and their relationships, or might contain the detail of just a single artifact. A service specification might itself be provided in some

Pattern: Standard Model

Summary: The specification of required behavior is shared or reused in model format. The model is not adapted or modified, and artifacts derived from it should conform rigorously to the model.

Synonym: Model-Based Reuse, Shared or Common specification, design-time reuse

Problem: The software artifacts themselves cannot be shared or reused directly, but instances of them should all provide the same behavior. For example there may be no common software platform, or the use of a particular software instance cannot be mandated. Such as when different organizations participating in the same industry need to implement the same standard behavior to provide B2B connectivity, but have no desire to share the same software or platform.

Solution: The specification of required behavior is provided in model format. The model may be used to generate, in part or full, further software artifacts. The more complete the model and/or the more complete the generation, the more easily conformance with the model can be achieved.Artifacts derived from the model may have to be submitted to a certification program to test their conformance to the specification.A model may identify specific “plug points” where any extension or customization should occur, so that the integrity of the base model is protected.

Figure 12: Standard Model

Advantages: Platform and implementation independence. Consistent software behavior.

Disadvantages: Unless the model is locked in some way, it may be changed or adapted and no longer rigorously conform to the original. It may be hard to verify absolutely that any artifacts derived from the model conform rigorously to it. The model still may not be complete at the detail level (e.g. business logic)

Box 10: Standard Model


form of model. Also both white-box and black box software might be accompanied by models to explain their behavior.

With a Shared Service Specification the intent is very specific. Each Service instance must conform exactly to the specification. The specification is also very precise and complete. This intention is also implied with the following Standard Model pattern in Box 10. That is, whilst the specification of the required behavior is disseminated via a model and the solutions based on it are themselves not shared, the intention is that any artifacts derived from it still conform rigorously to the model.

However, with some models and architectures the intent may be just to provide a common starting point, rather than enforce a precise definition of the end deliverable with rigorous conformation to the model. That is, the models and architectures may be freely adapted to suit the specific need.

The model may only cover part of the overall requirements. They help ensure that concepts are consistent, but the models may be incomplete or generalized, and so require additional work to specialize them for a specific instance. See Box 11.

Whilst a Common Framework might be designed to be adapted and extended, it is normally a model of a particular domain. For example, a model may not dictate the complete detail of a sales order, but will specify the structure of the sales order in that it should be composed of a sales order header plus one or more order line items.

Often, structures like these will be recognized as a pattern that can be applied in many domains. For example a class model or business type model may contain several one-to-many structures similar to the sales order, and usually there is required behavior that is common across those structures. Such as listing all the

Pattern: Industry Model

Summary: A model or architecture containing concepts or structures that are common to many systems is supplied as a framework that is intended to be adapted and completed to meet a specific requirement.

Synonym: template reuse, architecture reuse

Problem: Many systems are built by different organizations, or organizational units, to support a similar requirement. Though each system instance is unique and different, it is necessary that parts of the systems embody the same concepts, or follow the same structure, to improve consistency, follow best practice, and also reduce time and effort to deliver.

Solution: The common concepts and structure are provided as a framework, or template. The framework contains a model or architecture that is designed to be adapted or extended , or levels of detail that require completion, in order to meet a specific requirement.A framework may identify specific “plug points” where adaptation or extension should occur, in order to try and protect the integrity of the base framework.

Figure 13: Common FrameworkAdvantages: Improvements in consistency (though not a guarantee of). Reduction in time and effort. Dissemination of best practice (even though the derived instances might diverge substantially from the original)

Disadvantages: Trying to control the extent of permitted adaptation might be difficult unless the model is only used in a tool that manages this. Difficult to demonstrate conformance with the original model once it is adapted (though there may be no requirement to do so).


Box 11: Industry Model


line items for a header, not allowing “orphaned” line items, or the ability to re-associate a line item with a different header, and so on. Hence it is useful to make these structures and the associated behavior available as a pattern.

Many readers will of course be familiar with architectural patterns such as “model-view-controller”2, and the many design patterns3 used in software engineering. However, organizations

might wish to extend these with patterns they feel are specific to their organization or industry (but still patterns as opposed to models or specifications). See Box 12.

Pattern: Pattern-Based Reuse

Summary: A structure and the associated behavior is made available as a pattern so that it might be followed in several different domains.

Synonym: design pattern , architecture pattern

Problem: Models, frameworks and specifications are usually domain specific, so cannot be used outside that domain. Even within a domain, structures and their associated behavior are often re-invented, not always in a consistent way.

Solution: A generalized pattern is provided at a higher level of abstraction than typical models, frameworks and specifications.The higher level of abstraction allows the pattern to be followed across many disparate domains.

Figure 14: Pattern-Based Reuse

Advantages: Consistent behavior across multiple structures in many domains. Best practice is followed.

Disadvantages: Effort of difficultly confirming a derived instance conforms to the pattern. The pattern may exist just as documentation, and is not directly useable, and hence there may be inconsistent translation of the pattern into reality.

Box 12: Pattern-Based Reuse

�0 cbdi journal © Everware–CBDI Inc, March 2008


Part 2: Sharing and Reuse in the Layered Service ArchitectureFigure 15 provides an example of how different patterns of sharing and reuse might be used across the layered service architecture.

Solution Layer: Software assembly for the solution demonstrates service-based software reuse pattern where component A uses component Z via its published service.

Process Service Layer:

The deployment for a process service demonstrates the multi-deployment pattern, where multiple instances of the deployment unit for the process service are each deployed close to the client to make it more performant by making it part of the software assembly.

•

•

Two process services follow the shared service specification pattern. The instances in this case might be in different organizations, but both follow an industry standard.

A process service follows the shared service pattern and is used by multiple solutions

Core Business Service Layer:

A core business service follows the shared service pattern and is used by multiple process services.

A software component follows the black-box reuse pattern and is reused in many automation units

An automation unit follows the shared automation unit pattern and provides several core business services

•

Figure 15: Sharing and Reuse in the Service Architecture

cbdi journal © Everware–CBDI Inc, March 2008 �1

Utility Service Layer: A utility service follows the shared service pattern. Note that the software component reused in the core business service layer example may also provide a utility function. However, as this is not provided as a utility service, it does not get mapped into the utility service layer. Rather it just part of the automation unit for the core business service

Underlying Service Layer: An existing system is made available by following the service-based existing system reuse pattern using a wrapper to provide the underlying service. This is used by Automation Unit A in the core business service layer.

SummaryThere is no one ideal pattern of sharing and reuse. As illustrated below, a more generalized artifact, delivered at a higher level of abstraction might increase the flexibility, and hence opportunity for sharing and reuse, yet conversely typically involves more effort to reuse as it requires specialization and transformation into the necessary lower level of abstraction needed in the final system.

Now that we have established some patterns for sharing and reuse, in a subsequent report we will return to some of the other issues raised in the introduction to this report. Considering for example,

Funding and business case

Designing for sharing and reuse

Governance and Asset Management

•

•

•

•

•

NotesService Benefit Patterns. CBDI Journal March 2006. http://www.cbdiforum.com/secure/interact/2006 – 03/SOA_Service_Benefit_Patterns.phphttp://en.wikipedia.org/wiki/Model-view-controller http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29

1.

2.3.

Figure 16: Higher level of abstraction increases flexibility, but requires more effort

The CBDI Journal is published 11 times a

year and is the primary research vehicle for

Everware-CBDI developing and documenting best

practices in all aspects of Service Architecture and

Engineering..

For more details see: www.cbdiforum.com

About CBDICBDI Forum is the Everware-CBDI Inc. research capability and portal providing independent guidance on best practice in service oriented architecture and related delivery processes. Working with F1000 enterprises and governments the CBDI Forum research team is progressively developing structured methodology and reference architectures for all aspects of SOA.

CBDI ServicesA CBDI Forum Subscription provides a corporation or government department with access to a unique knowledgebase, ongoing continuous practice research guidance materials and hotline access to CBDI Forum experts. The monthly CBDI Journal provides in-depth treatment of key practice issues and guidance for architects, business analysts and managers. Members are encouraged to interact by commenting on CBDI Reports and Knowledgebase content, interacting in CBDI blogs and participating in CBDI reviews.

CBDI Forum provides:

• Gold Membership – enterprise subscription to the CBDI Journal

• Platinum Membership – enterprise subscription to the hosted SAETM Knowledgebase plus CBDI Journal

• Silver Membership – individual, independent consultant’s subscription to the CBDI Journal

• Education Workshops and Seminars – providing indepth education on architecture, process and practice. Public and In-house classes are available.

• Consulting – guidance in all aspects of SOA adoption, architecture, design, implementation and management

Contact UsFor further information on any of our services contact us at: [email protected] or +353 28 38073 (International)

IMPORTANT NOTICE: The information available in CBDI publications and services, irrespective of delivery channel or media is given in good faith and is believed to be reliable. Everware-CBDI Inc. expressly excludes any representation or warranty (express or implied) about the suitability of materials for any particular purpose and excludes to the fullest extent possible any liability in contract, tort or howsoever for implementation of, or reliance upon, the information provided. All trademarks and copyrights are recognised and acknowledged.

Independent Guidance for Service Architecture and Engineering

Documents

marCh 2008 · Service Architecture and Engineering ISSN 1745–1884 marCh 2008. Editorial Assembly – The Final Frontier Separation of software manufacturing and assembly is an important