inside - CBDI Forum › public › downloads › LzStd › journal2003-03.pdf · The Back-End:...

March 2003We commence a new series on

Service Oriented Architecture with

Part 1 - The Foundation

CBDIJournal3 Editorial

4 Best Practice ReportServices Oriented Architecture -Part 1 - The FoundationIn this first part of our series on SOA we providedetailed guidance on where to start. We show how thesame architecture can address B2B, B2C, Workflow,Legacy Wrapping, and provide the scalable EnterpriseServices needed.By Oliver Sims

15 Vendor InsightSun Microsystems Manages theServices StackWe examine the evolving Sun stack and assess hownew management functionality strengthens theiroverall competitive position, and provides some toughchallenges for their competitors.By David Sprott

22 Vendor InsightMicrosoft’s Trustworthy ComputingWe discuss the progress Microsoft has made in thisarea, and provide a framework model for assessing andmanaging trustworthy capability – not just for Microsoftbut for the whole industry.By Richard Veryard

inside...

Insight for Web Service & Software Component Practice

Moving to Web Services?Learn from CBDI with our Consultingand Workshops

CBDI provide a variety of educational and consulting services based on our deep and narrow

focused knowledge acquired in the analytical process. The new services are designed to help

you work smart and make the right decisions, as you move into Web Services. There are

products applicable to enterprises and software organizations.

Product Area CBDI Education Consulting ApplicableSpecialist Workshop Products Enterprise

Areas Or Industry

1. Web Service Understanding Y 1 Day Enterprise

2. Web Services Strategy and Roadmap Y YEnterprise

And Industry

3. Service Based Business Analysis and Design Y 1 or 2 Day Y Enterprise

4. Web Service Architecture Y 1 or 2 Day Y Enterprise

5. Business Process Design for Web Services Y Y Enterprise

6. Web Service Design YEnterprise

And Industry

7. Web Services Security Interop Y 1 Day YEnterprise

And Industry

8. Web Services Management Y 1 Day Enterprise

9. Information Modeling for Service OrientedY 3 Day Y Enterprise

Architectures

10. Web Services Integration Platforms Y Enterprise

11. Selecting a Web Services Toolkit Y Y Enterprise

12. Process Design for Service and ComponentY Enterprise

Delivery and Consumption

13. Software Vendor Product Management Review Y Y Industry

14. Software Vendor Marketing Support Y Y Industry

15. Venture Capital Support Services Y Industry

To find out more see our product catalog at:http://www.cbdiforum.com/public/services_bro.php3

To discuss how CBDI can assist call us on: +353 28 38071 or 73

Insightfor WebService &SoftwareComponentPractice

Subscribe to theCBDI Journal

The CBDI Journal is

published monthly. In

addition to the CBDI

Journal, subscription

includes electronic access

to all back numbers that

now represent a significant

resource library. There are

individual and corporate

subscriptions schemes.

Corporate subscription

includes access to our

workshop materials.

For more details and to

subscribe see:

www.cbdiforum.com

Register for your owncopy of the CBDI Journal now atwww.cbdiforum.com

There’s been lots of talk about Service Oriented Architecture

or SOA over the past few months. We have referenced SOA

in many of our reports and presentations. In our survey,

which we will report on during March, many respondents

made it clear that SOA is an important architectural

direction for them. So what exactly is SOA?

Editorial

CBDI JOURNAL © CBDI Forum Limited, March 2003 3

www.cbdiforum.com

In this month’s CBDI Journal we arepleased to announce a new series ofreports by Oliver Sims, which will drilldown on various different aspects ofSOA. Oliver is well known as a consultantand author, and in particular as the“father” of the term business objects.His books include Business Objects,Building Business Objects (with PeterEeles), and the Business ComponentFactory (with Peter Herzum).

We all know that there’s not much that’sreally completely new, and in fact in theIT world today most of the new WebServices technologies and concepts aredirect evolutions of work that has beenin process for many years. At CBDI wefully agree with Oliver that SOA is firmlybased on good CBD and CBSEpractices, but with extensions that caterfor the more formal separation ofprovider and consumer and the extendedWSXX interfaces.

So we have asked Oliver to author aseries of reports in which he updates hisguidance documented in his variousbooks, and to provide a similar level ofexplanation. We commence the seriesthis month with Part 1 - The Foundation,where Oliver examines how thearchetypal enterprise needs to evolve itsinternal architectures. Many members tellus this is precisely where their prioritiesare today. In subsequent reports Oliver

will address Service Based Development,Federation and Collaborative ServiceDelivery, The Technology Platforms andfinally Business Impacts.

Also in this month’s Journal we report onSun Microsystems and in particular itsstack. Over the past few years wehave both predicted and tracked theprogressive consolidation of the majorplatforms, and commented on howreduction in choice is concomitant with agradually maturing industry. In our reportthis month we observe on how Sun ismarking out a quite different strategyfrom its direct competitors that increasesthe vertical integration from top tobottom, including hardware and software.

In our third report, Richard Veryard takesanother look at Microsoft’s TrustworthyComputing initiative. Back just over ayear ago we reported on Microsoft’scommitment in the trusted systems area,and it is an appropriate time to revisit thisissue. In his report Richard provides amodel for assessing progress in thetrusted systems arena, which of courseis equally applicable to other vendorsand also enterprises and serviceproviders, and controversially gives hisassessment of Microsoft’s scorecard.

Regards, David Sprott

[email protected]

This month we commence

a new series of reports by

Oliver Sims, which will drill

down on various different

aspects of SOA.

4 CBDI JOURNAL © CBDI Forum Limited, March 2003

By Oliver Sims Introduction to the SeriesThis series is about the effectivespecification, design, and delivery ofservice-oriented applications andbusiness processes in the enterpriseenvironment. It assumes thatapplications must integrate not only withlegacy, but also with each other, in orderto avoid creating tomorrow’s stovepipelegacy. In particular, we address themajor “choke points” from end-to-endof the development lifecycle, andend-to-end from front to back of thedistributed enterprise system.

In five parts, the series looks at thefollowing areas, each article building onits predecessor.

1. Foundation.The Back-End: Enterprise Service-Oriented Architecture (SOA) as anideal mixture of CBSE and WebServices. CBSE is the best approachto building business systems, andthe web service approach canprovide a single service definitionand invocation technology not onlyexternally but also internally, whetherwe’re talking B2B, B2C, A2A,wrapping legacy, or providingenterprise services to internal users

2. Service Design.Application Development: Specifyingthe Services - system-orientedbusiness modeling as the basis for

The Service Oriented Architecture provides the essential

foundations for flexible applications. We recommend that

every organization needs to evolve and upgrade its core

systems portfolio in order to easily support internal and

external Web Services, as well as have much greater

adaptability in basic application upgrade, BPO and other

business driven initiatives. In this first part of our series on

SOA we provide detailed guidance on where to start. We

show how the same architecture can address B2B, B2C,

Workflow, Legacy Wrapping, and provide the scalable

Enterprise Services needed. An example will be given of a

simple SOAP-based web service (B2B), and how it’s

implemented through service-oriented components. It will

be shown how workflow and B2B can very usefully be

thought of as components - not the middleware, rather the

specifications, which typically are interpreted at run-time.

Services Oriented Architecture

Best Practice Report

between major enterprise components,and enable inherently more adaptableback end applications. In this report weexamine how these same conceptscan enable effective collaborationintra and inter enterprises.

4. The Technology Platform:Providing a Service-Oriented platformthat helps deal with technologycomplexity and churn, both at thefront-end and at the back-end. This


Service design, where the “businessmodel” maps one-to-one tocomponents in the IT system, socapturing far more precise businessrequirements as well as much betterbusiness-to-code traceability.

3. Federation.Collaborative Service Delivery: InPart I - The Foundation, we showedhow Service Oriented Architecturecan establish better separation

continues...

describes the “glue” often needed ontop of commercial middleware.

5. The Service Based Business:If Enterprise SOA is a worthy goal,how does the IT organization getthere? This report looks at a processfor transitioning to enterprise SOA, sothat the business’ goals for IT can bebetter met.

is, how are the implementations ofthese services best designed, structured,and built?

Of course, some services will be providedby suppliers outside the enterprise.However, most enterprises know thattheir competitive advantage depends ontheir core systems and processes. Theyalso believe it would be foolhardy to cedecontrol of these, and more importantlythe valuable in-house business domainknowledge, to some third party. Hencethese core services will continue to beprovided in-house (although parts of thedevelopment may be out-sourced).However, the enterprise is also facedwith huge flexibility and time-to-marketpressures for their systems. This meansthat internal development of serviceimplementation must be such as to meetthese pressures.

For this reason, enterprise ITorganizations are increasingly looking toESOA to meet these challenges.

This report discusses the two majorconcepts, and in the final part bringsthem together to show how they can not

IntroductionEnterprise Service-Oriented Architecture(ESOA) is an architecture centred on twomajor concepts:

● Services offered over the weband within the enterprise usingstandards based on XML forspecification of invokeable services,and for the message flows involvedin providing those services

● Implementation of services usingcomponent-based softwareengineering (CBSE), which notonly addresses structuring newapplications, but also coverslegacy wrapping, and workflowand B2B specification

The first of these the concepts isbecoming well-known. However, it issometimes thought that SOA meansbuilding applications by composingother people’s services. However, evenif this were to be possible for somebusinesses, someone somewhere hasto build the code that provides thoseservices. A key question often overlooked

only deliver the promise of serviceorientation, but do so in such a way as todeliver much greater simplicity andflexibility to enterprise IT development.

Web ServicesWeb services have been standardizedthrough the World Wide Web Consortium(W3C). The specifications producedmainly use XML as their “alphabet”.1 Thereason for their success over the pastfew years is that the specifications are:

● Platform-independent

● Effectively, a single platform-independent type system

● International standards

● Freely available

These standards provide a highlyeffective “lingua franca” for inter-systemcommunication. The two standards ofconcern for this report are at the heartof web services, and are:

● WSDL (Web Services DescriptionLanguage)

● SOAP (Simple Object AccessProtocol)

Part 1 - The Foundation

1. As a standard for carrying not only data but also the names of that data, XML provides for a degree of resilience in the face of “format creep”; however, moststandards do not make use of this capability, insisting on a precision that is often, in our opinion, somewhat over-specified.


Services Oriented Architecture - Part 1 - The Foundation continued...

within the enterprise and outside.User sessions, often long-running,are also managed here. Thesessions make requests forservices to the Core EnterpriseSystem. For scalability reasons,these requests are typically “one-shot” requests, such as “updateorder” or “get stock details”.

● A Workflow Engine managesautomated workflows, and is alsoresponsible for storage of workflowspecifications and their execution.There may be more than oneworkflow engine. Such enginestypically provide a user interface sothat users can see and manipulatetheir work list, and so that thework items can be managed.

● User Systems are typically PCs onuser’s desks, and are included herefor completeness. Some accessthe core enterprise system directlyusing a client/server style ofinteraction.

The typical interactions between theseparts of the IT environment are shown bythe dotted arrows.

WSDL and SOAPWe show how web services workthrough a simple (and thereforesomewhat unrealistic) example. Considera B2B service that allows products to beordered. The service specifies that arequest containing customer number andproduct number should be sent, uponwhich the product will be ordered, andthe purchase order number will bereturned. Error conditions are notconsidered in our example.

The CORBA IDL interface for the orderplacement function might look like this:

interface Ordering {

void placeOrder(in string

CustNum, in string ProdNum,

out short PONum);

..

};

However, in the web service world, theinteraction is described using WSDL,and the WSDL file is stored by theenterprise’s Web Services IntegrationBroker.3 A highly simplified version ofthe WSDL file is shown in Figure 2, withthe purpose not of explaining WSDL,but merely to illustrate the kind of thingit is. Note, however, that the Place Orderservice is handled by two separatemessages – one incoming to theenterprise providing the service(“PlaceOrderRequest”, and oneoutgoing to the requesting system(“PlaceOrderResponse”).

The WSDL file not only defines theservice provided, but also defines whatSOAP messages will flow. Of course, it isassumed that the external organizationwill build an application that sends the

Enterprise IT and Web ServicesThe main parts of an enterprise IT systemthat provides and implements webservices are illustrated in Figure 1, andare as follows:

● The Core Enterprise System isthe set of custom applications andbought-in packages that form theheart of the IT system and that runon servers and/or mainframes.Security and scalability are ofmajor importance here. The CoreEnterprise System is protectedby firewalls and other securitymechanisms. The code thatprovides web services is here.

● The Web Services IntegrationBroker is the set of middlewareresponsible for handling B2Bcollaborations with externalsystems.2 This includes storage ofthe collaboration specificationsand their execution.

● Web Servers handle user andB2C requests from browsers, both

Figure 1: An IT view of the enterprise and its partners

1. For an excellent white paper on the internals of this, see [Cummins].

2. This repository is indexed using another web standard, UDDI (Universal Description, Discovery and Integration), whereby the service defined in the WSDL file canbe found when potential users of the service do not know its web location. In our example, we assume the location is known, and so UDDI is not used.


continues...

Figure 2: WSDL fragment for an “Ordering” Service

appropriate SOAP request message, andreceives the response message. Creationof the code that does the mapping of(say) Java to SOAP, and the actualinvocation, is handled by tools, asdiscussed in the next section.

The (simplified) SOAP messages thatflow across the wire would looksomething like Figure 3.

Just as tools generate proxy code, so theserver end – an adapter – can also begenerated. The adapter receives SOAPmessages and maps them (in variousways according to the particular webservices integration broker middleware)to the native language (e.g., Java) codethat implements or provides the service.Responses follow the reverse path.

Creating and Accessing aWeb ServiceWithin the enterprise’s IT organisation, adeveloper first defines the service using aWSDL tool, and stores the resultingWSDL file in a repository managed bythe Web Services Integration Broker. Thisis shown as step 0 in Figure 4 (thedeveloper is shown at a “user system”: adeveloper is a user too – of developmentenvironment system). Part of this task isidentifying the module within the coreenterprise system that will actuallydeliver the service.

To access the service, a developer in theexternal enterprise:

1. Uses a tool to retrieve the WSDL file

2. The tool then generates a proxy forthe service in the programminglanguage of choice. The proxy is aprogramming language class thatprovides a friendly interface, in theprogramming language of choice, forthe developer to invoke the service.Generated code inside the proxyhandles SOAP formatting based onthe WSDL specification and

Figure 3: SOAP messages on the wire



design of the service interfaces and theuse of web standards such as WSDL. Itis not only about the structure of the WebService Integration Broker (which is notdiscussed in this report). SOA is alsoabout the design and structure of theinternals of the service, and the extent towhich service orientation using webservices technology can be usefully

applied elsewhere in the enterprise ITsystem.

The Beginnings of Enterprise ServiceOrientationConsider the service interface providedby the Web Services Adapter in Figure 5.Now consider the service provisionmodule in the same figure. This modulealso has an interface of some sort –otherwise it couldn’t be called. Otherparts of the enterprise IT picture alsohave their own interfaces – workflow,B2B as a service to internal parts, EAIsystems that integrate legacy and/orpackaged systems, etc. There are in factmany different interfaces that developersmust deal with.

Consider now the advantages of webservices listed previously. There is noreason why these should not apply insideenterprise IT as well as outside. Theresult would be a single kind of interface,using the same technology, for allinternal systems that provide a service.Many existing systems would need to bewrapped of course. And performancewould have to be considered. However,the potential advantage of a single

communication with the systemproviding the service. The proxy(and the application containing it) isinstalled on the external organization’ssystem.

3. When the application runs, it callsthe proxy, which does everythingnecessary to map the native languagerequest made to it to SOAP requeststhat go across the wire to accessthe service.

4. When a request is received by theenterprise’s Web Services IntegrationBroker, it is mapped to a specificservice provider (the implementationof the service – the thing thatprovides it) in the core IT system.This could be a legacy application,an EJB, or some other application.Once serviced, a SOAP response issent back to the requesting system.

With proxies and adapters in mind, ourpicture of enterprise IT is now as shownin Figure 5. The adapter effectivelyprovides an interface to the serviceprovider. The two together make up “the service”. But SOA is not only about the

Figure 4: Creating a web service

Figure 5: Web Service Proxies and Adapters

Modules of mature

CBSE have been

service-oriented from

their beginning.


● CORBA from the Web ServiceIntegration Broker

● MQ from a workflow instance

● JMI from the web server

● COM from a PC using client/server

Each of these has its own programmingmodel, and this is often visible in theapplications making the requests.Wrapping all of these mechanismswith web services not only providessimplicity for the application developers,it also separates the communicationsand messaging infrastructures fromapplications. This means they can beevolved without impact on applications.

So far we’ve treated the core IT systemsas if they merely implemented services.But what about their own internalstructure? For this, we turn to CBD. Notthe hyped “components” of third-partyoff-the-shelf plug-n-play modules, butthe much more realistic and valuablemodules of mature CBSE (Component-Based Software Engineering), whichhave been service-oriented from theirbeginning, which was some time beforethe terms came into use.

interface type, that maps to manyprogramming languages, is a hugesimplifier for enterprise systems. It’s likea common hub – indeed, considering anumber of other technologies that gowith web services – such as messagequeuing, it’s almost a must – a highlycompelling simplifier. And simplificationmeans effort reduction which means costreduction and/or faster response tobusiness needs.

Figure 6 shows web service interfaces(green “lollipops”) not only on the B2Bcollaborations (our WSDL/SOAP examplewas an extremely simple example of aB2B service), but also on the coresystem modules that provide orimplement services, and also wrappedaround the workflow engine so thatworkflow instances can be kicked offusing a web service interface.

Note that this also reduces the variety ofinvocation mechanisms. For example, inFigure 5, the order placement serviceprovided by the core enterprise system isinvoked using quite possibly four differentmechanisms; for example:

continues...

Figure 6: Internal Web Service Interfaces



things such as “customer”, “order”,“trade”, etc. But at this point, somethingwent grievously wrong. OO wasimplemented through programminglanguages. But a programming languageaddresses the inside of a module – howyou code the internals. The result wasthat the “objects of the problem domain”disappeared inside an amorphousmodule which itself did not representanything recognizable by domainexperts.5 Some modules were a wholeapplication. We were back to the single-module application of the 50s and 60s!This is illustrated by Figure 7, where theimportant6 concepts in the problemdomain are seen at the first stages of thedevelopment lifecycle (labelled“Analysis” here), after which, if goingdown the traditional “application” track,start to become successively buried inthe opaque deliverable which is an“application”. Mature CBSE, on the otherhand, refines the domain concepts anddelivers them as software modules thatare invokeable through their interfaces,and which can plug autonomously intothe platform.

Now there’s nothing wrong with theconcepts behind OO, What went wrongwas that these concepts were notimplemented by sensible middleware – itwas all left to the application programmer.What a difference it would have made ifthe software objects had been each aseparate module, each module relatingto a real thing in the problem domain,and independently pluggable into asystem. But such plugability needssomething to plug into – a softwaresocket – provided by the middlewareplatform.

Components, then, are objects writ largeand done properly, with appropriate

Software Engineering (CBSE). It is thisthat forms the foundation for preferredservice implementation within enterpriseIT. Best-practice and mature CBSE isquite a different animal from the CBD sohyped in the late 90s (for example, see[Herzum] and [Hubert]).

Mature CBSE is primarily a way ofthinking about application design (andthen applying that thinking of course).How you think about design is probablythe most important design choice of all.For example, forty years ago manyapplication designers thought of anapplication as a kind of written report, analgorithm that started at the beginning (ofthe coding pad), went on until it reachedthe end, and then stopped. A few stillthink this way. Since this structure didnot match the problem domain that theapplication was trying to implement, theresult was reams of spaghetti code.

The history of software has been one of asearch for better ways to think aboutapplication design structures. First therewas the idea of splitting applications intoseparate programs. In the 70s cameinsight into the program internals, so thateach program that made up theapplication was split into modules,based on its function. Inside eachmodule, code was organized accordingthe four main structured programmingconcepts.4 This structure was well-suitedfor the batch systems of the time, but didnot suit the event-driven systems thatstarted to become prevalent in the 80’s.

Object orientation, introduced in the 80s,promised much. The concept was right – modules of code each of whichimplemented a clear business “thing”,and which were event-driven. The ideawas to represent in software the “thingsof the problem domain”. These were

Components and SOABackgroundIn the past, there has been much of themarket hype about components asthings bought from third party suppliers,so that application developmentbecomes merely the assembly of thesethird party components. This was neververy likely, outside of technicalinfrastructure. Components were alsoseen as a technology (COM, EJB,CORBA Component Model), wherekey technical characteristics were tightbinding of low-level programmaticinterfaces and synchronous RPC-stylemessaging. This contrasts with thedynamic binding provided by suchtechnologies as SOAP and WSDL, withtheir ability to invoke services acrossdifferent technology platforms, andsupport for several interaction stylesfrom RPC to asynchronous looselycoupled collaborations. [Veryard]

In short, CBD has come to be seen asyesterday’s hype, with little to show for itother than some useful technology. Thiscurrent understanding of CBD isaccompanied by a focus on servicesoffered by components (good) and a lackof focus on the implementation of thatservice (bad). For example, RichardPawson states that “Component-basedsystem development is primarilyconcerned with enabling a plug-and-playapproach to systems development.Plug-and-plays gives you, in theory,more flexibility in sourcing your systems;you will be able to purchase componentson the market...”. [Pawson]

CBSEHowever, over the past ten years, anumber of practitioners have beendeveloping CBD along a different path –what has been called Component-Based

4. The four main structured programming concepts were: sequence (of lines of code), if-then-else, do-while, and case.

5. Ivar Jacobsen once said that in the problem domain he could see objects; during analysis and design the objects were all there; but once the programmers gothold of them they disappeared, and never returned, being buried invisibly in applications. (Private communication to the author in 1993).

6. Defining what “important” means in this context is beyond the scope of this article. However, the concept is defined in several places, including [Tyndale].


continues...

CBSE is also concerned with identifyingand scoping the components in asystem. So our supply chain managementsystem could end up with perhaps 300-500 components, each consisting of anumber of classes.

Let’s now define what a component is ina little more detail.

A Component Is:A CBSE component – the kind used inbuilding enterprise-strength systems, asopposed to things like GUI widgets – isdefined as a module that exhibits all ofthe following characteristics:

● Represents and encapsulates asingle business concept (processor entity)

● Has one or more well-defined“network-style” interfaces (seeside-bar)

● Is visible and tangible throughoutthe development life cycle andalso in the run-time

middleware to support them.Components realize the vision of objectorientation. Components are language-neutral – can be written using either OOor procedural languages.7

But wait a minute – consider a systemsuch as supply chain management. Acount of the software repository wouldshow thousands – perhaps tens ofthousands – of OO classes. Does thatmean tens of thousands of components?Well, no. A component is normally acollection of classes. An important CBSEconcern is defining which classes belongto which component (remember that acomponent is not only a deployablemodule, it is also a “big” class in its ownright). So, for example, a Sales Ordercomponent would consist of an OrderHeader class, an Order Line class, acollection class (an instance of whichwould hold the Order Line instances),and several smaller classes such asCurrency, Order Value Calculator, etc.

Figure 7: Applications vs. Components

Network-style interface:An interface that can be invokedfrom other address spaces orsystems, and that can also beinvoked from within the sameaddress space. There are twoimportant constraints on an interfacethat makes it a “network-style”interface:

● References passed asparameters must be referencesto other components.8

● Objects are always passed byvalue, never by reference. That is,a reference to something that isnot a component, but whichmust be passed as a parameter(for example, an Order Header),is always passed by value.

These two constraints make it mucheasier to avoid the “object spaghetti”that resulted in some earlydistributed object implementations.Designers assumed that all objectscould be distributed, and ended upwith dense webs of dependencies(object invocations) that flowedacross networks. Systems built thisway were quickly found to beunworkable. The lesson is thatsome important techniques inclassical object- oriented designand implementation, although goodfor code that runs entirely in asingle address space, do not scale.

8. Strictly speaking, this implies a conceptof reference scope, where any given kindof reference has a specific scope. Forexample, a URL can have worldwidescope; a CORBA IOR has scope within agiven network of interconnected CORBAsystems (which may be extended by, forexample, the COM-CORBA interworkingstandard); a C++ object reference hasvalidity at most within a given addressspace in a single computer.

7. Although not available today, probably due to the justified lack of interest in procedural languages, in the90s there was middleware available that supported mixing components written in different languages inthe same address space.



● Can be built and deployedautonomously (an example ofautonomous deployment isupdating a system with a newversion of the component)

● Is easily combined and composedwith other components togetherwith it collaborates to deliverbusiness solutions

● Addresses the scalability anddistribution challenges of enterprisedistributed systems

● Is of medium to large granularity(typically is contains a number ofclasses, but is smaller than awhole application)

● Is managed at run-time by amiddleware container which atrun-time provides the technology“socket” into which the component“plugs”, and at design time by amodeling tool that also can be saidto provide a “socket” (it knowsabout components, and canimport a component model into asystem model that comprisescollaborating components).

A component interface is defined as a“port” - and entry point into thecomponent. Figure 8, based the OMG’sEDOC specification (and similar to what is currently being discussed for inclusionin UML2) illustrates this. The modelshown in Figure 8 starts at theComponent at the left centre. AComponent provides one or moreComponent Interfaces, which is a kind ofProtocol. A Protocol has one or morePorts. A Port, which is where thecomponent interacts with the worldoutside itself, is of three kinds: a FlowPort, an Operation, and a Protocol Port.The Operation Port is the familiar“interface” with an operation name andparameters. As we’ll see, a Flow Port is used for a “workflow component”, and a

Production of a GenericComponent Realization does notalways require IT technical andmanagement skills.

Thus the CBSE concept of “component”is wider than suggested by the commoncomponent technologies, but is muchmore closely defined than the traditionalconcept of third-party off-the-shelfplug-and-play modules or completeapplications or technology subsystemssuch as a DBMS.

OK, so far, but this was supposed to beabout SOA. Where does SOA come in?

Components are Service-OrientedObjects have interfaces; and so docomponents. Best practice OO designsuggests that objects should provide adefined service. It’s the same withcomponents. The difference is that, sincea component maps to a real thing in thebusiness domain (such as Customer9),and is a separately invokeable module,these interfaces are visible at run-time,instead of being (as with OOPLs), buried invisibly in one or more applicationmodules.

But service orientation is all aboutproviding an interface to a process. If components are the “things of the

Figure 8: The Component Interface

Protocol Port is used for the morecomplex B2B collaborations.

A Component can also have “required”interfaces. These are provided by otherComponents which the Componentinvokes. The Component is thendependent on those other interfaces (andon their providing Components).

The component itself is structured asshown in Figure 9. A given component isof a certain type (such as “Customer”,or “Order”). It provides an interfaceconsistent with its type. The componentalso has an internal implementation or“realization”. This realization can be oftwo kinds:

● A programmed realization – that is,the internals are coded using aprogramming language such asJava or C#, or by a scriptinglanguage such as or Python. Thiskind of component is generallyintended to be run on componentmiddleware such J2EE or .NET, andits creation requires IT technicaland management skills.

● A generic realization – a realizationthat is implemented using adeclarative specification language or tool. Examples includeworkflow and B2B components.

9. Strictly speaking, this should say: a component maps to a real concept in the business domain, such as “Customer”, and a component instance maps to a realthing in the business domain, such as the record held of the Customer “Joe Bloggs”.


continues...

Figure 9: Component Structure

10. CRUD is an acronym commonly used for the set of entity-oriented operations Create, Read, Update, and delete.

11. This example is highly simplified; a real-life order processing component assembly could contain up to thirty components.

business”, surely the only “services”they can provide are CRUD10 services –aren’t they?

Well, no. This is because some of the“things of the business” are processes –or to be precise, process specifications.A process spec is a set of instructions forhow to deliver a given service. In human-readable form, it could be a page in aProcedures Manual. A process spec canbe defined quite happily as a component,as opposed to a code block within somelarger non-component module.

Thus we have two kinds of component:first “process components”, which makeuse of the services of second “entitycomponents”. These are illustrated inFigure 10, where the components havebeen assembled into the server end ofa (highly simplified) order processing“application”.11 They are arrangedaccording to the mediator pattern, whichaims to reduce dependencies; the Order Process component “mediates” the Order, Customer, and Product entitycomponents. This makes the mediatedcomponents more re-usable by otherprocess components (for example, anInvoice Process component). Note thatthe component assembly is complete initself, and needs no code to glue the

components together – the componentmiddleware effectively does thatdynamically at run-time.

At this point, some of you may bethinking, “but lots of processes areimplemented using workflow systems,and COM objects or EJBs or CORBA Components shouldn’t be used tohand-craft workflow!” You’re right. Thisis where the Generic ComponentRealization (see Figure 9) comes in. AGeneric Component Realization is one

where the component consists of adeclarative specification or script, whichis interpreted at run-time by somemiddleware engine – for example, aworkflow engine. Such an engine can bethought of as a generic implementation,modified by the script, for allcomponents that make use of thatparticular engine. This means that aworkflow or B2B collaboration can bedeveloped using many of the sameconcepts as components destined to beimplemented on a J2EE environment.

In summary, the component concept canbe applied to a wide variety of modules,whether built with compiled code, ordeclaratively scripted. Further, theautonomy characteristic of allcomponents, from design through buildinto the run-time, means that its internalsare opaque to all but the builder.

Suppose the Product component inFigure 10 had been previously built. Tothe developer of other components, forexample the Order Process component,the Product component is a thoroughly

Figure 10: Process and Entity Components


black box. All that is seen is the serviceprovided by it (and, if it’s “ready-to-run”,a specification of the required “socket”or platform). So when the developerassembles the Product component into acomponent assembly, he or she has noidea of its implementation.

Figure 10 also illustrates how thecomponent assembly itself is a larger-grained component – a black box. Itprovides a service (the one provided bythe Order Process component), and itsinternals are quite opaque to a developerinvoking this service. On the other hand,the developer(s) who designed theassembly and built some or all of thecomponents in it have knowledge of theinternals.

Enterprise ServiceOriented ArchitectureNow we bring the two main threads –web services and CBSE – together. Theresult is an enterprise SOA that appliesto both web services made availableexternally and also to core businesscomponent services built or specified forinternal use. Figure 11 illustrates this.The business components have “web”interfaces – that is, they are specifiedusing WSDL and invoked using SOAP.It may appear that performance willbe unacceptable when componentsare co-located. However, any goodmiddleware will optimise access, so that components in the same address spacewill be automatically invoked directlyrather than via SOAP messages.12

Figure 11 also shows “wrappercomponents” that wrap legacy and/orpackaged applications for eitherprocess or data access. The wrappercomponents look like componentsfrom the outside, but their internalimplementation consists of whateveris needed to access the legacy or


Figure 11: The Enterprise SOA

including integration subsystems,communication subsystems, andcomponent containers

● Simplifies the whole enterprisedevelopment environment

In conclusion, Enterprise SOA is aconcept whose time has come, andwhich will form the foundation for futureenterprise systems. Perhaps CBSE andWeb Services are indeed a marriagemade in heaven.

Oliver Sims

ReferencesCummins – Fred Cummins, White Paper on WebServices Integration Architecture, OMG Documentbei/02-10-02

Herzum - Herzum & Sims, Business ComponentFactory, Wiley 2000

Hubert – Richard Hubert, Convergent Architecture,Wiley 2002

Pawson – Pawson & Matthews, Naked Objects,Wiley 2002

Tyndale - Tyndale-Biscoe, Sims, Wood, & Sluman,Business Modelling for Component Systems withUML, EDOC 2002 paper

Veryard - Richard Veryard, Modeling for SOA, CBDIJournal. February 2003

packaged application, plus the relevantpart of that application itself.

The result is a single way of providingand invoking service interfaces, whetherexternally or internally. In addition, all theadvantages of CBSE accrue. Indeed,Enterprise SOA has some uniqueadvantages:

● Provides, through use of webservices interfaces, a singleinterface and service accessdesign, which is independent ofthe underlying platforms

● Provides a single type system forinteractions across and outsidethe enterprise

● Provides a clear architecture for theinternal implementation of services

● Is tailor-made for use of the OMG’sMDA (Model-Driven Architecture)strategy

● Separates much more clearly thebusiness logic in code, workflow,or B2B collaboration specificationsfrom the underlying middleware,

12. It is an ancient dictate of middleware, going back at least to the 70s that remote/local access should be transparent to the application developer, with local accessbeing optimized. The recent introduction of “local” interfaces in J2EE seems to have ignored this rule, and was a giant leap backwards in the annals of effectivemiddleware. However, server middleware is available today that does observe the rule.


By David Sprott

Abstract: Sun has been through a stormy period over the

past year in the tough economic climate, with a lagging

position on Web Services, increasing competition from

Linux platforms, falling market share and diminishing

investor confidence. Last month Sun started an aggressive

fight back with some significant announcements. In this

report we examine the evolving Sun stack and assess how

new management functionality strengthens their overall

competitive position, and provides some tough challenges

for their competitors.

Sun MicrosystemsManages the Services Stack

Vendor Insight

continues...

IntroductionIf you listened to the media, the financialanalysts and of course their competition,Sun Microsystems is in trouble. ClearlySun’s share price speaks volumes, andthe valuation reflects an amazing fall fromgrace since the heady days of Dot Comwhen Sun was right inside the tornado.Sun also took a body blow recently withpublication of market share numbersshowing a strong move to Linux andaway from Solaris. Popular sentimenttoday suggests the rise of Linux willdeliver a fatal blow to Sun’s long runningSolaris strategy, and they have alreadyentered a period of slow decline asthe hegemony of IBM and Microsoftdominate the industry.

In the last month however Sun hasstarted to push back against theseassumptions. In January Sun made some

strong announcements on productplatforms and in late February they gavea pretty thorough update on theirstrategy right across the board, and inparticular provided some interestingstrategic guidance on their hardware andsoftware strategy.

Sun is moving progressively to a moretightly integrated stack than their Javabased competitors. The conventionallayers of the stack will becomeincreasingly blurred, and the feature

function of individual product componentssuch as app servers and portal servers,will become subordinate to overalleffectiveness and critically, economics.

Sun is also extending its platformcoverage, and whilst this may be seensuperficially as a defensive response tothe increasing capability and rapidacceptance of Linux, it should also be


processes. What's really significant is the impact this is having on Sun product management strategy, and in this reportit will become clear that the influence ofSix Sigma is rapidly becoming pervasivethroughout the company.

c) Demonstrate future for SPARC andSolaris - Sun’s competition and criticshave been making hay over the pastcouple of months with the idea thatcommodity based X86/Linux will replaceits SPARC/Solaris products. Sun hasmade a very strong response to thisnotion specifically with a clear roadmapthrough 2005 for the SPARC product linebased on a CMT (chip multithreading)architecture, which will deliver up to 15xmore throughput than current SPARCprocessors. This demonstrates a clearintent to lead the high end Unix (don'tforget Linux is a variety of Unix) marketwhilst providing a compatible growthpath for mid range application.

d) Support for reduction of customercost and complexity - The N1 project3 isa very significant step to reducingcomplexity in systems management,and together with the new productmanagement project Orion, more ofwhich below, demonstrates Sun’sproducts are being designed in responseto customers’ real issues.

e) Sharply differentiated professionalservices strategy - curiously Sun’sprofessional services strategy is closerto the model used by Microsoft asopposed to IBM. Whilst Sun has notinconsiderable services resources (10Kpersonnel) they are aggressivelypursuing a partnering approach ratherthan the full service approach as used byIBM and HP. The declared Sun strategy isto focus on the technology, and facilitateusage by customers in conjunction with

Sun Microsystems Manages the Services Stack

viewed as an innovative move toprovide better management of platformtransparency, a really important costrelated issue for CIO’s and serviceproviders.

Overall StrategyThe mood at Sun is interesting. Like theirnemesis in the past year, they havestarted to eat just a little humble pie. Forthe first time (at least in my experience)Scott McNealy did not engage in hisusual Microsoft bashing. Instead he andhis management team showed they havelearnt some pretty important lessonswhich, relevant to this report, include:

a) Improved management controls -They have learnt some pretty importantlessons in terms of managing cash andheadcount. Under the spotlight of thefinancial community this is a companythat is now bending over backwards todemonstrate probity, cost control andquality processes.

b) Customer focused drive to deliverquality - In my report on Sun last year1

I mentioned their stated intent to pursuea Six Sigma strategy and discussed theimportance of this. If you are not familiarwith this, Six Sigma2 is a processdiscipline that addresses quality througha metric driven approach. The concept,pioneered by close partners such asTexas Instruments, is an engineeringdiscipline that is applied to all aspects ofprocess improvement. Unlike say ISO9000 which focuses on traceability, SixSigma concentrates on measurableprocess efficiency and repeatability.Although this is a long term strategy, it isclearly becoming embedded in Sun andperhaps more than any other factor willcontribute to a profound change ofculture from relatively fast and looseto customer focused, high quality

third parties. For example Sun willprovide remote management services toenterprise data centers, but they will not host centers themselves, introducingpartners for this task. Whilst Sun will not necessarily be pleased with the analogy,they will recognize the Microsoft model isinherently more scalable and adaptableand focuses R & D efforts on creatingimproved products and facilitationservices. It might also support a lower riskbusiness model, being less susceptibleto changes in economic climate.

Project OrionIn January Sun announced that it wasmoving to a quarterly announcementcycle. They plan to bundleannouncements and issue them on aconsolidated basis. This somewhatodd announcement was actuallypresaging a more profound shift in Sunpractice, whereby Sun will be bundlingall of its software products together intoan upgrade and release unit, which isshipped every 90 days.

Sun reports its customer feedback thatmanaging the product upgrade life cycle(not just for Sun products) is highlyresource intensive; that the expandedSun ONE portfolio is highly complex interms of versions and dependencies,with a constant upgrade and releaseprocess. This is equally a problem forSun itself and its customers.

To address this Sun is moving to aquarterly shipment of “all” its systemsoftware products including the operatingsystem, N1, the various server products.The combined product will be referred toas Solaris. This will allow Sun to optimizeits own release programs, and to includemuch improved integration testing intoits processes. For customers there willbe much greater predictability and


continues...

simpler inter product dependencies. Sunwill also be offering alternative pricingoptions which include stack level (akapredictable) and also potentially metered options when suitable instrumenting isavailable in the product. Orion basedshipments will commence in earlyaccess status in Q3 and be generallyavailable in Q4 2003 for base platforms,and progressively roll out to the entireportfolio.

We understand that eventually Orion willhave multi-platform support and coverusage of Sun’s products such as the app and directory server on other platformssuch as HP-UX.

The details of Orion are quite sketchy atthis stage, and we understand this is acommitment that is still in the earlystages. However it is clear that Orion isan innovative move to simplify the life

cycle management of the entire set of software infrastructure for both Sun andits customers. The management ofdeployment will itself be managed by theN1 infrastructure, providing a significantlevel of process automation.

The archetypal software stack has beenin a state of constant change overthe past decade. New functionalcomponents, such as application ordirectory servers are initially introducedinto the market as separate components,which in the early stages of adoptionform the basis for new markets, butwhich rapidly become largelyundifferentiated commodity items andare then bundled into the lower layers ofinfrastructure, by the platform providers.

The cynical observer might commentthat this action by Sun is a directresponse to its failure to achieve aleading market share with individualcomponents, particularly the applicationserver, and therefore Sun has more togain by bundling the components andconcentrating its marketing on the sumof the parts. Whilst this may have beenthe stimulus behind Sun's original stackstrategy, it is clearly addressing very realissues for customers and platformprovider, which will be examined veryclosely by the rest of the industry.

Figure 1: The Services Operating System

Customer benefits Sun benefits

Single ship and install unit

Simplification of component management

Easier pre-requisite control and integrationwith other products

Simplified, predictable pricing

Simplified licensing management

Guarantees on upwards compatibility

Reduced testing and certification effort, potential for increased product quality

Simplification of component management

Easier pre-requisite control and integration with other products

Encouraging customers to use more Sun products, creating incremental revenue

Simplified licensing management

Table 1: Rationale for the Service Operating System



The Services OperatingSystemWhere Sun has been particularlyinnovative is in recognizing that thetreatment of the infrastructure as a“system” has some considerableadvantages, not just in the managementof the life cycle of the individualcomponents but also in the ongoingmanagement of the overall infrastructure.We should expect over time that theconsolidated product will allow greateropportunity for rationalization of theportfolio components and reuse ofcommon services, because dependencymanagement will be simplified with acommon release schedule. However thenet effect of this might also be that, asthere is tighter integration between theSun components, it may become lesseasy for third parties to integrate withthe stack.

The evolution of what we will refer to asthe Service Operating System (SOS) is avery positive move evolving beyond thebranding of the Sun ONE portfolio. Wecan expect Sun’s direct competitorsto follow.

Integratable StackBack about three years ago, after theNetBeans and Forte acquisitions Sundecided on a modular and open product strategy referred to as integratable. Theoriginal vision was that there would beconsiderable choice provided by a large

number of product partners. In practicewhilst Sun has maintained theintegratable strategy, the number ofparticipating partners has been lowerthan the original vision. This has been theresult of both Sun’s desire to minimizeoptions and to increase the quality of theintegrated offering as well as perhapsfewer ISV product partners wanting toinvest on the Sun platform which has notachieved the market share originallyenvisaged. Also Sun has clearly notrealized the goal of defraying productdevelopment costs by being able toleave certain areas of the portfolioto others.

Now the move to create an even moretightly integrated stack might justexacerbate this problem. Verticalintegration between the layers is almostcertainly going to happen, in the sameway that for example application serverfunctionality has been integrated into theSolaris operating system. Whilst Suncontinues to promote the integrateablenature of the software stack, the reality isthat industry consolidation will meanfewer product partners, for example asRational moves into IBM and BEAstrengthens its partnership with HP.Strategically it is also clear that Sun isfully committed to delivering the entirestack itself, and will be increasinglyemphasizing the virtues of thecomprehensive stack, and this is notdissimilar to the message from itsprimary Java competition. Strangely

whilst this is happening, Microsoft isactually demonstrating it can deliverproductive product partnerships to fillreal and important gaps such as WebServices Management.

Component or Service ArchitectureSun’s stated strategy for Orion is tointegrate the platform at the product APIlevel. In our opinion this would bemissing a major opportunity. Sun has the opportunity to embrace service orientedarchitecture for this program whichwould move the integration to theinterface layer, and render the servicesimplementation independent. Productcomponents currently use API’s, whichcould reasonably easily be upgraded toservices with or without SOAP.

This move would facilitate bothtransparency (choice and flexibility) ofcomponent providing the service as wellas making it easier to integrate thirdparties whose products will inevitablynot neatly dovetail into a productcomponent view.

Whilst the service based approach hassome compelling technical benefits, wemight expect that the marketingorganization may not be so enthusiastic.There is no real basis for service basedpricing, while there is a de factocomponent price today. Of coursethere’s nothing to stop continued usageof component pricing while productintegration is service based.

Component based product integration Service based product integration

API based

Conventional publication of API specification

Dependence based on physical unit

Standards based interfaces

Self documenting, published interfaces and WSDL meta data for useby provider, 3rd party partner product provider and customer

Product component transparency, providing greater portfolioflexibility for provider, partner and customer

Table 2


continues...continues...

This significantly increases the density ofdata center utilization.]

Sun’s initial version of N1 is specificallyfocused on managing Blade servers,providing soft recabling of what mightotherwise rapidly become a data centeradministrator's nightmare.

ProvisioningN1 starts to get really interesting later in2003 when provisioning functionalitybecomes available. The issues that Sunis addressing are:

1). the typical silo organization of (nonmainframe) data centers, whereapplications are installed on specificservers, which are then dedicated tothe application with predictable andplanned low average utilization in orderto accommodate peak operatingconditions. N1 enables the definition ofpools of resources that can be reused bymany applications on a dynamic basis.Sounds just like a mainframe.

2). the multiple operating systemenvironment that most of their customersare likely to be managing including Linuxand Solaris. By automating provisioningN1 will facilitate at least lower time andcost involved in managing multiple OS’sand transitioning between differentoperating systems.

Sun is being highly innovative in theproduct portfolio management areagenerally, and the move to SOA wouldextend the leadership and differentiationthis creates from their competitors. Wehave discussed this with senior Sunexecs and will await their responsewith interest.

Resource ManagementThe N1 product concept is not new, butit is a foundational component in theemerging stack strategy. N1 is a resourcemanagement infrastructure that providesa control system bringing together alloperator/administrator functions intoa virtual control interface. Featurefunctions are summarized in Table 2.

VirtualizationLate last year Sun launched their Bladeserver products, to widespread commentthat they were nearly a year behind theircompetition.

[For those readers of this softwarearchitecture journal that haven’t an ideaof what a blade is, simply put it is aserver that looks more like a card thana conventional rack server, and isphysically deployed in vertical arrayswhich are plugged into something thatlooks like a double height rack server.

Sun describes N1 as “the data center asa system” which is intended to allowvirtualization of resources, such thatradically higher utilization of physicalresources is possible. While this is highlygraphic, reality is perhaps a littledifferent, and practical deployments willbe more on the lines illustrated in Figure2, where multiple systems are maintainedconcurrently to achieve differentobjectives which might include:

● separate trust groups, tomanage risk

● technical compatibility groups, forexample to manage incompatibletechnologies and or technicaltransition

● federations

The definition of “systems” is animportant issue. In the past we haveadvised on the use of what we refer to as“integrity units”. These are in essencelogical components that form clusters ofthings that need to be managed together.These would generally be coarser thanformally defined technical components,and would address issues such as policy,trust, etc. We would repeat advice herethat system modeling is starting tobecome an important aspect of stack

Year Product Focus

2002

2003

2004

Virtualization

Provisioning

Policy automation

Functionality

Access to a virtual pool of resources,allowing “soft recabling”

New application stack, allowing for moresophisticated application provisioning ofapplications and services

This is expected to include functionality tounderstand prior system usage patterns, tomake predictions and execute appropriatesystem changes

Cost Benefit

Automating management of Blade servers

Delivering OS (Linux/Solaris) transparency

Increased utilization through automationand response to real time events

Table 3: Cost Benefits of N1


Solaris. However recent Roadmapannouncements on Solaris indicate the reverse, that Sun will almost certainlywork to differentiate Solaris featurefunctionality from Linux and establish adifferentiated high end environment. WhatN1 does is provide Sun’s customerswith mechanisms to manage bothconcurrently and also a relativelypainless transition mechanism.

Web ServicesThere’s very little new to report on WebServices per se. The impending versionof J2EE 1.4 will be the next major eventin this area, and as is well understood willimplement the various Java API’s for XMLas part of an extended programmingmodel where the Service is a first orderconstruct. Further J2EE 1.4 will alsoimplement the WSI basic profile. Sun’ssupport for 1.4 will be available inthe summer.

WS StandardsWhere Sun is in a difficult position is theyare forced into a follower position on theentire WSXX standards stack. Havingallowed the leadership of Web Servicesto pass to IBM and Microsoft, it is goingto be extraordinarily difficult for them torecover a significant position of influencein this area.

At this stage we would have toassess that Sun is reconciled to thisuncomfortable position and whilst it isdoing what it can to influence andleverage standards in areas such as WSI,it is focusing its energies on interestingareas for stack development as we havediscussed above.

In public Sun make the assessmentthat they expect process choreographyprotocols ebXML and BPEL et al toconverge. However our assessment isthat this is optimistic, and they willprobably have to implement dualstandards in this area in order to meetcustomer needs.

Web Services ProductsSun is not declaring any specific plans inthe very active area of Web ServicesManagement. However they commentthat the existing Sun ONE workflowengine could well provide the service busmechanism, which is then populated byinfrastructure services built accordingto Sun Blueprints or acquired frompartners.

SummaryThe re-branding of the Sun portfolio asSun ONE back in 2001 was a clearresponse to both Microsoft andparticularly IBM, both of whom have asingle stack covering their softwareproducts. However the combination ofN1 and Orion now take Sun’s


deployment, and identification of integrityunits, and the service dependencieswould be a good place to start.

Implementation TransparencyCurrently N1 supports Linux, Windowsand Solaris across some 15 categories ofdevice component. The N1 infrastructureprovides their customers with practicalmechanisms to decouple at least tosome extent the interdependence ofphysical device, operating system andapplication, making transition betweenLinux and Solaris as painless as possible.What is becoming very clear is that therelative economics of Solaris and Linuxwill vary over time, and that in futuremost of Sun’s customers will implementboth Solaris and Linux.

Many people might have assumed thatthe Sun strategy on Linux was aholding position, and that over time they would have worked to supercede

Figure 2: Federated Data Center Management

Whilst Sun is being

relegated to a follower

position in Web Services

standards, they are being

innovative in delivering

ways to address key

customer issues.


continuing confusion that will be obviousto customers, employees and partners.In this round of briefings there wereobvious gaps where Sun spokespeoplesimply sidestepped questions theycouldn't answer on issues such as WSManagement and standards. In resolvingorganizational stress as well as in thedelivery of delivering trusted, manageablesystems, we believe Sun’s investment inSix Sigma may well be its strongest card,providing the framework for effectiveexecution. However this is a long termproject.

Whilst Sun is being relegated to a followerposition in Web Services standards, theyare being innovative in delivering ways toaddress key customer issues. In today’stough market conditions this is a prettygood recipe for recovery - help thecustomer do more with less.

David Sprott [email protected]

1. CBDI Journal June 2002 - Sun MicrosystemsGets A Services Vision!

http://www.cbdiforum.com/secure/interact/2002-06/sun_micro.php3

2. Six Sigma means a measure of quality thatstrives for near perfection. Six Sigma is adisciplined, data driven approach andmethodology for eliminating defects (drivingtowards six standard deviations between themean and the nearest specification limit) in anyprocess – from manufacturing to transactionaland from product to service. The statisticalrepresentation of Six Sigma describesquantitatively how a process is performing; toachieve Six Sigma, a process must not producemore than 3.4 defects per million opportunities.

More information at:http://www.isixsigma.com/

http://www.isssp.com/

3. CBDI Journal January 2003 - AutonomicComputing

http://www.cbdiforum.com/secure/interact/2003-01/auto.php3

consolidated stack beyond brandingand creates considerable opportunity forcost reductions through simplificationand optimization.

Moving forward there is no applicationserver market, there is only a stackmarket, where increased blurring of theconventional layers, together with tightintegration between the managementtools and the rest of the infrastructure willhave the practical effect of increasingcustomer lock in. It will also have theeffect of reducing the number ofcollaborating partners, a process whichis already in train. However, if there is aclear ROI case for the new managementinfrastructure and approaches, customerswill see this as a sensible trade-off.

Looking at today's TPC-C Performancebenchmarks Sun is nowhere to be seen.On a price/performance basis Sun will in all probability, notwithstanding 15xperformance gains over three years,have difficulty in establishing andmaintaining a lead over its competition.What Sun is betting on is that high endsystems need more than simplyperformance, they need simplification,management and high quality which lead to lowest TCO. While the broaderplatform and OS strategy will play well to its natural customer base, we believeSun will continue to differentiate in thehigh end systems market. While Suncontinues to act as if it is the dominantplayer on a broader basis, it is most likelythat they will concentrate on the high endniche and be successful in that area. Atsome stage their marketing will catch upwith reality.

Sun has been through considerableturmoil over the past 24 months, andfrom experience we know that thingswill be pretty difficult. There will be


Vendor Insight

By Richard Veryard

A year ago, Microsoft announced its Trustworthy Computing

initiative: People Trusting Computing. In this report, we

discuss the progress Microsoft has made in this area, and

provide a framework model for assessing and managing

trustworthy capability – not just for Microsoft but for the

whole industry.

Microsoft’s TrustworthyComputing

ChallengeChallenge for MicrosoftFor some while now, Microsoft has beenthe subject of almost incessant criticismfrom the security world. Just over a yearago, Bill Gates responded boldly to thiscriticism, with an open email to Microsoftstaff announcing a strategic shift toTrustworthy Computing.1 This email wasthen followed up by a white paper, whichhas already been revised several timessince its first publication.2

Few large corporations have shownthemselves able to execute significantchanges in strategic direction as quicklyand effectively as Microsoft. Microsoft’srapid grasp of the opportunities of theInternet has already demonstrated thecorporation’s remarkable power torespond and adapt to new challenges.However, Microsoft’s allies and criticsalike can agree that if this strategic moveis taken seriously, it could represent thebiggest challenge Microsoft has facedto date.

Challenge for all suppliersAnd not just Microsoft. Microsoft rightlypoints out that the challenge of

Trustworthy Computing is not just one forMicrosoft but for the whole industry. Ifcomputing as a whole can be made moretrustworthy, then the world will be a stepcloser to accepting the vision of utilitycomputing – computing on tap – and thiswill arguably expand prospects foreveryone. Microsoft cannot takeresponsibility for the whole industry,but it presents itself as a leader of thisinitiative – not only working on theTrustworthy status of its own productsand processes, but also encouragingothers to do likewise.

And here is the nub of Bill’s strategicgamble. Microsoft has to succeed atTrustworthy Computing, both to helpeliminate one of the key inhibitors to thelong-term growth of the softwareindustry in an increasingly cautious andsuspicious world, and to maintainMicrosoft’s market share in this industry.Furthermore, if Trustworthy Computinghas the wider significance that Bill Gatesconfidently expects, Microsoft may gainan advantage over its competitors (notforgetting the Open Source community)to the extent that it visibly achieves more,more quickly.

The challenge of

Trustworthy Computing is

for the whole industry.


some ongoing responsibility for theirown security. While we do not expectMicrosoft or other suppliers to abdicatetheir responsibilities, it is important todraw appropriate boundaries onthese responsibilities. Just as a carmanufacturer should not be heldresponsible for reckless driving, so thesoftware industry should not be heldresponsible for all aspects of unsafecomputing.

Framework forTrustworthy ComputingSecurity and moreOne of the continuing triggers forTrustworthy Computing has been theembarrassment caused by well-publicized malware – Code Red, Nimda,and more recently Slammer. One of theissues around security – especially withInternet attacks such as Slammer – is theneed to install patches. Vendors typicallyregard victims as partly responsible fortheir vulnerability, to the extent that theyhave failed to install the relevant patches.However, Microsoft itself is often lax ininstalling patches on its own machines,and the media takes delight inannouncing that Microsoft has been hit.

However, the scope of TrustworthyComputing doesn’t just cover security,but also addresses a number of otherimportant issues. Microsoft hasidentified four high-level requirements oftrustworthy computing: security, privacy,reliability and business integrity. At thehighest level, these are requirements onthe whole system environment, coveringeverything from business systemsand applications to platforms andinfrastructure. These high levelrequirements then decompose into thetrustworthy characteristics of specificsoftware products and services. And

touch every facet of our lives and theconstituency of users is set to expanddramatically. A farmer in a developingcountry may not possess a laptopcomputer today, but tomorrow he/shewill use devices or appliances thattransparently include advancedcomputing capability as naturally astoday's appliances include electricmotors or internal combustion engines.

Trustworthy Computing –a supplier-led initiative?However whilst recognizing the broad

constituency they are serving, Microsoft’swhite paper seems to imply thattrustworthy computing needs to be asupplier-led initiative.

1. Trustworthiness ultimately means thattechnology can be taken for granted,and that “The People” will no longerneed to pay attention to questions oftrust and security. Presumably therewill be some experts somewhere whocontinue to pay attention to trust andsecurity on behalf of “the people”.

2. Trust is likely to be widely perceivedas establishing a framework forautomating policies that arereinforcing Microsoft's and othersupplier’s commercial position.

These two issues are tightly inter-related.

The longer-term goal of invisible trustcontrasts with a shorter-term requirementof visible trust. Overcoming a legacy ofmistrust will require that “the people” ortheir representatives have a good level ofvisibility over those aspects of computingthat affect trust and security.

An alternative to this stance should beconsidered, in which specified levels oftrust and security remain permanentlyvisible, in some way that is meaningful to “the people”, and “the people” have

Challenge for all stakeholdersThe ultimate goal of TrustworthyComputing is “People” trusting“Computing”. Both “People” and“Computing” are very broadly scoped.A broad scope for “Computing” hasseveral implications. It takes the focusaway from the alleged securityweaknesses of Microsoft’s (or any othersingle vendor’s) products and services,and spreads the responsibility and riskacross the whole computing industry –including in house development. This is asensible move, as it encourages trustand security to be regarded from awhole-system perspective, as well asproviding a framework against which thecontribution (positive or negative) of anyindividual component or service can beproperly assessed.

“Computing” must then be understoodnot just as a complex accumulation oftechnical bits and pieces, but as a socio-technical system, including businessrelationships and engineering practices.These must be regarded as importantelements of “trusted computing”.

Who then are the “people”? Microsoft’straditional audience has been “users” –in other words, people with personalcomputers running Windows and Office.But in the last few years Microsoft hasexpanded its product footprint and nowsupports small, medium and largeorganizations running networks andservers supporting complex applicationportfolios.

There is also a much broader notion of“people”, including all citizens whosesocial and economic wellbeing dependson “computing”. As Microsoft rightlypoints out, today computing is at a stage equivalent to the electricity industry inthe late 19th century. Over the nextdecade we can expect computing to

continues...


Default, Deployment & Communication(SD3+C). This is explained further inTable 1.

Security versus FunctionalityIs there a trade-off between security andfunctionality, as implied by Bill’s email? Itis not difficult to see how the constantdevelopment of new and more powerfulfeatures has led in the past to an upwardcurve in vulnerabilities. Adding featureswilly-nilly also adds to the complexity ofany product, and such complexity islikely to add to the costs of security andthe likelihood of security problems.

The software industry has always had anobsession with features, one whichMicrosoft has certainly shared. Product

improvements (upgrades) are typicallydefined in terms of new features –because that’s apparently whatcustomers will pay for. The productdevelopment process is typicallyorganized around features, and thereforeconverts any perceived problems with asoftware product into requirements fornew features.

In a recent article, Craig Mundie, authorof the Microsoft white paper onTrustworthy Computing, admits thatMicrosoft's business model demandscontinual increases in complexity.“Things have to keep moving, or therewould be no business.”

Central to Microsoft has been the beliefthat nobody is going to buy Windowsn+1 unless it is bigger and more complexthan Windows n. Microsoft does not yetbelieve that there is a significantcustomer base willing to pay for a newversion of Windows that is simpler andmore reliable than the previous version,and it is not currently doing very much tobuild such a customer base.

Microsoft’s Trustworthy Computing

from a trust perspective, of course, theseproducts and services cannot be whollyseparated from the trustworthiness oftheir producers/suppliers.

SD3+CMicrosoft has identified four elements ofits response to the requirement forsecurity, as shown in Figure 1: Design,

Figure 1: Federated Data Center Management

Element

Security by Design

Security by Default

Security in Deployment

Communication

Description

Security is designed into products andservices.

Products and services are deliveredwith the default security settings atmaximum strength.

Products and services are adequatelyprotected from attack.

Stakeholders are provided with relevantknowledge to enable them to use thesecurity architectures, features andprocesses effectively.

Commentary

Microsoft aims to achieve this by attention toarchitecture and design process, and the additionof security features.

Microsoft aims to resolve the apparent oppositionbetween functionality and security by providingsecure locks on features whose use may createextra vulnerability, and delivering products withthese features switched off and locked down.

While this includes a number of separate initiatives,one of the areas Microsoft is devoting attention tohere is the patch management process.

Microsoft is focusing here on the dissemination ofknowledge from Microsoft to its customers.

Table 1: Elements of SD3+C


effect on the whole system. In somecases, a security feature may simplyprovide greater security locally, whilereducing security globally. For example,feature interaction between differentsecurity mechanisms can createsignificant new vulnerabilities.

Security by DefaultThe next argument that Microsoft isusing is based on the idea of security bydefault. Instead of delivering productswith all the security holes open, Microsoftnow intends to deliver products with allthe security options closed. Where extrafunctionality may create vulnerability,these features will be switched off andlocked down, and they will requiredeliberate action by the systemadministrator to enable them.

However, there is a problem with thisapproach. Cautious IT managers will stillfeel that the presence of these featuresrepresents a security cost/threat. Thelocks preventing unauthorized use ofthese features may indeed be as strongas Microsoft claims. However, if theconsequences of a breach are sufficientlyhigh, a security-minded CTO may needto carry out an independent technicalverification of the strength of these locks– thus incurring a cost that is onlynecessitated by the unwanted presenceof these powerful features.

And of course the features don’t evenhave to be loaded onto your hardware.The same threat is present, even if thefeatures are simply sitting on a Microsoftor third party website, waiting to bedownloaded.

It could be argued that any hacker whocould reach the locks was probablyalready fully into the machine, and couldtherefore do anything he wanted anyway– so the access to these featureswouldn’t add any further vulnerability.

Features and functionality are so stronglyembedded in the value system ofsoftware developers, that it is notsurprising to find voices from withinMicrosoft defending its traditional values,and questioning the trade-off betweensecurity and functionality mentioned inBill’s email.

If Microsoft can get security right, thenthere may be no reason to compromiseon features after all. The key tounderstanding SD3+C is to realise thatMicrosoft is looking for a way tomaximize security and maximize featuresat the same time – to transcend thetrade-off that may once have existedbetween security and functionality, tohave their cake and eat it too.

Security by DesignThe first argument is that complexity canbe managed with a good architecture. Iffeatures are put in their proper place, andproperly controlled, there is no reason forany additional feature to have a negativeimpact on security. A good architecturewill itself promote security, as will a gooddesign process.

We welcome this emphasis on goodarchitecture and process, which willcertainly help to mitigate some of theeffects of excess functionality andcomplexity, thus improving security aswell as having other benefits. But weremain unconvinced that goodarchitecture and process alone willremove all concerns about complexityand excess functionality.

In some instances, extra complexity inthe architecture – such as extra layers oradditional indirection – could provide asecurity benefit. There are also manysecurity features, whose presence ispresumed to enhance security. However,these security features need to beevaluated holistically, in terms of the

But this argument fails to take account ofthe gradient of the vulnerability. A skilledhacker might get into a machine withsome difficulty, open all the locks, andleave without creating any obvious signs.This would then allow future attacks tobe made much more easily. Even if therewas always some vulnerability, theactions of the first hacker have nowmade the holes much larger and moreobvious.

There is also a range of social andsociotechnical attacks. For example, arogue software developer might createand distribute some attractive feature-laden software. When the software isinstalled, it issues a warning messagesaying that it cannot run properly withoutsuch-and-such feature being switchedon or downloaded. It is easy to imagineharassed system administrators beingcoerced into complying with theseinstructions by eager users. It may noteven be possible to determine whetherthe rogue software is deliberatelydesigned to trick people into reducingtheir security levels, or merely aconsequence of ill-advised enthusiasmon the part of its developer.

(It is also possible to imagine a range oflegitimate purposes for temporarilyunlocking these features. In somesituations, it might be safest to have atemporary unlock, for a fixed period, orfor the duration of a defined process,with an automatic relock when theperiod/process is complete.)

My own preferences are for simplicity,and I instinctively distrust unnecessarycomplexity. The fact that Microsoft hasidentified certain features as worthy ofbeing locked away means that they mustbe presumed powerful and potentiallydangerous. It’s like I don’t want to have agun in my house, even if it were securely

continues...


evaluating vulnerabilities, and forreceiving and installing patches wouldmake life simpler for systemadministrators and others, and make itmore likely that a given patch wouldachieve a greater coverage more quickly.This would enhance trustworthycomputing across the industry.

Of course, while improved patchmanagement standards and supportmay address the symptoms of resourceintensive configuration and deploymentsystems, they will merely reduce and notentirely eliminate the inherent overheadof patch management. There are stillhuman processes in deciding whether toapply patches at all, subjecting thepatches to verification, validation andtest, and managing the configuration anddeployment process.

In the longer term, customers fortrustworthy computing might reasonablyask why they need to install patches atall. Some patches may be upgrades toprovide additional functionality andperformance – and perhaps it would bebetter to call these something else.Meanwhile, emergency patches toaddress specific vulnerabilities (hot fixes)should surely be significantly reducedin number.

CommunicationIf Trustworthy Computing is conceivedas a supplier-led initiative, then we

should expect the emphasis to be oncommunication from suppliers to theircustomers. Microsoft has opened up anumber of new communication channels– including both web-based and moretraditional modes of publication – and isincreasing the volume of knowledgedisseminated through these channels.

A broader view of communication wouldlook at the sharing of all forms of relevantknowledge. Obviously, Microsoft wouldnot wish to position itself as the solesource of knowledge on security or othermatters, and therefore needs to haveeffective communication inwards as wellas outwards.

Complete FrameworkAs we have seen, security is addressedby SD3+C (Security by Design, by Default,in Deployment & Communication).Microsoft has indicated that the otheraspects can be broken down in similarfashion. Accordingly, the CBDi Forumhas developed the extended frameworkshown in Figure 2.

Progress ReportWhat has Microsoft achieved in a year?They have recruited some people withimpressive credentials, and there arevarious activities and initiatives to report.They have identified a number of areasthey want to work on. Meanwhile,outsiders take delight in pointing out


locked away – I’d feel it would just giveme something else to worry about. Whatif the gun cabinet were accidentally leftopen, what if my kids found where I hidthe key? Obviously there are lots oflegitimate gun owners who cheerfullyaccept the responsibilities of lookingafter their guns properly, as a small priceto pay for the utility of owning a gun. Butif I don’t want the guns in the first place,why should I have to bear such burdens?

Security in DeploymentBut the complexity of the products isnothing when put against the complexityof run-time system management.Products are installed into a vast diversityof configurations, environments andbusiness processes.

There are strong indications that thecomplexity of system managementcurrently exceeds the capacity ofsystems administrators. This has seriousconsequences on various aspects ofsystem performance, including security.To take just one obvious example, ithas become apparent that systemadministrators cannot cope with theinstallation of patches. It may take anumber of weeks between the discoveryof a vulnerability and the availability of apatch; but if the patch is not thensystematically applied, this means thatthe opportunity to exploit this vulnerabilityis extended from weeks to months oreven years.

Microsoft has itself been embarrassedby its own failure to install patches, andsees patch management as a key areafor improvement, not just for itself but forthe whole industry.

In the short term, there is an obviousneed for improved patch management –preferably leading to cross-vendorstandards and protocols (see Box 1).Common procedures for reporting and

● Cross-industry platform-independent process

● Common procedures for reporting and evaluating vulnerabilities

● Consensus on timing of disclosure of vulnerability

● Common procedures for receiving and installing patches

● Collaboration between vendors whose products interoperate

● Forum for resolving multi-vendor vulnerabilities

Box 1: Patch Management – Need for Standards

The TCM - A simple

high-level TWC Capability

Model ... a framework for

assessing the progress of

any organization towards

the goals of trustworthy

computing.


competitors, and against industry “bestpractice”, as well as against absolutetargets.

The CBDi Forum has therefore created asimple high-level TWC Capability Model,which can be used as a frameworkfor assessing the progress of anyorganization towards the goals oftrustworthy computing.

Capability ModelWhy do we need a model?The purposes of the capability model arethreefold

1. Measure & manage progress againstthe objectives of trustworthycomputing. This will apply not just toMicrosoft, but also to its partners,customers, competitors – indeed,potentially to the whole industry.

inconsistencies and failings. As if a singlevirus penetrating Redmond were enoughto prove the whole Trustworthy Initiativeto be a sham. As if Microsoft’s failure totake its own advice (e.g. on installingpatches) were a sign of hypocrisy, notjust simple human error. Although it mustbe said that propensity for error is animportant indicator of the requirementfor automation of application and ormonitoring functions.

Precisely because there is so much atstake, it is important to have a way ofassessing this objectively. We hope thatMicrosoft itself will have some way ofmeasuring progress internally, as well asmaking its progress visible externally.

Many people would be interested in acomparative benchmark for TrustworthyComputing, checking where Microsoft is currently positioned in relation to its

Figure 2: Extended Framework for Trustworthy Computing (CBDi Forum)

continues...



Security of Products

Products whose purpose and integritywould be threatened by securityviolations.

Measuring the Securityof Products

ISO Common Criteria.

CERT incident reports.

Attack surface.

Security from Products

Products whose primary purpose isto enhance security.

Products that directly increase thesecurity of Microsoft and third partyproducts, services and systems.

Products that support a securityengineering process.

Measuring the Securityfrom Products

Customer take-up of freely availableservices and freely disseminatedresources.

Return on Security Investment (ROSI).

Table 2

Figure 3: Trust Enablers

2. Create benchmarks for comparisonbetween organizations and forcomparison against requirements.

3 Define a roadmap for planning localand global improvement.

A model allows people to contribute tothe overall programme from their ownperspective and to further their owninterests in trustworthy computing. Onlyas people understand their own interestsand responsibilities more fully can thecore of the programme progress.

Structure of modelThe model defines a series of enablersand a series of achievements. Theenablers are the things that are done aspart of the programme; the achievementsare the results of the programme. Theenablers are justified because they areexpected to produce the achievements.

Ultimately, the achievements must belinked to the overall goals of TrustworthyComputing: People Trusting Computing.

● Computing becoming moretrustworthy

● Individual products and servicesbecoming more trustworthy(“security of products”)

● Individual products and servicesmaking a demonstrable contributionto trustworthy computing (securityfrom products).

● People becoming more trusting(as evidenced in their attitudesand behaviour)

The model in Figure 3 shows abstractenablers (policy & knowledge), whichare embedded in concrete enablers(processes, practices, skills &technologies). These then produce aseries of measurable results and otherachievements.

Examples of security policies cited byMicrosoft are shown in Box 2.


A quick and dirty assessment of Microsoftagainst this model would indicate someprogress. Before Bill’s email, Microsoftwould almost certainly have been at level1. A year later, they clearly have gone along way to defining a series of policiesand they have started implementing theseinternally and with partners. This givesthem a credible claim to be at level 2.

However, the policies implemented so farare by no means complete, and Microsofthas some way to go before these policiesare fully embedded in the organization.Furthermore, it is too early for anysignificant effect on the trustworthiness ofMicrosoft products and services to bevisible. Before Microsoft can reach level 3,it will need to demonstrate significantand tangible results, linked to a controlledprogramme.

In order to clearly see their future progressto higher levels, we shall need greaterrefinement in the model. We hope thatMicrosoft and others will participate indeveloping the necessary detail.

SummaryMany critics have found it hard to believethat the Gates email was a seriousinitiative, and not merely a cynical ornaïve gesture.

Based on a simple maturity model, it isapparent that Microsoft has alreadyprogressed from Level 1 to Level 2. Thisis already a significant change, and itwould be surely be unreasonable todemand any more at this stage.

However, Microsoft watchers will now belooking closely at the developingoutcome of the trustworthy computinginitiative. The pressure remains onMicrosoft to remain focused on thischallenge, and to deliver tangible results.

Richard Veryard [email protected]

● Security Ownership

- Every component (or service) or feature has a security owner.

- Security owners must sign-off

- Security owner is accountable for security (via performance review)

● Mandatory Processes

- Threat Modelling

● Schedule

- Time allowed in schedule for mandatory processes

Box 2: Security Policy Examples (Source: Microsoft)

The key management questions are as follows:

The quality of the abstract enablers.

The effectiveness with which theabstract enablers are embedded inthe concrete enablers.

The compliance of the organizationwith the abstract enablers.

The ability to attribute specificachievements to the specific enablersthat produced them.

The ability to optimize enablers toproduce the required results morereliably and cost-effectively.Installation of effective learning.

Do we have the right policies?

Have we successfully implementedthe policies?

Are we following the policies?

Do the policies work in achievingour security objectives? Can wedemonstrate that the results aredue to the policies?

Can we achieve better results withsimpler policies?

Table 3: Key Management Questions

This leads to a simple maturity model for trustworthy capability.

Level 1: Adhoc

Level 2: Defined

Level 3: Controlled

Level 4: Managed

Level 5: Optimizing

Adhoc, no systematic capability.

Adequate set of policies defined. Programme toimplement and embed policies in organization.

Broad implementation of policies, fully embedded inorganization. Programme yielding significant andtangible results.

Ability to attribute specific results to specific enablers.

Optimizing.

Table 4: The CBDI TCM - TWC Capability Model

1. See CBDI Report on Bill Gates email at http://www.cbdiforum.com/public/news/index.php3?id=879

2. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/html/securitywhitepaper.asp

CBDI Raison d’etreWe aim to provide unique insight on component and web service technologies andprocesses for the software industry and its customers. To provide high quality analysisand other information resources on best practice in business software creation, reuseand management. To maintain the highest level of independence.

Modus OperandiCBDI has three channels:

- Subscription services - provision of continuous commentary and information.

- Workshops and seminars - providing indepth briefing and guidance on advancedarchitectures, processes and practices.

- Consulting - including related product management and marketing advice,application audit and guidance, technical and business evaluation for investment

How we compare with othersWe are not a mass market, media oriented organization. All material published by theforum is unique. The majority of material is published by our own analysts, orcommissioned from others, and under strict editorial control to ensure accuracy. Werigorously exclude spurious marketing.

We aim to provide depth insight which covers a narrow topic footprint in a deeper waythan the other analysts, and in particular cover not just the technology, but also thearchitectures, usage, practices and processes.

Also we are unusual as analysts we do not simply echo what the vendors say, we area think tank, identifying new ideas, opportunities and providing stimulus for thinking.We try to be thought leaders providing ideas generation and a rich source ofconceptual thinking based on practical, real world feedback.

Who reads CBDI Journal?Technical and Application Architects, Business analysts, Consultants, CTO’s,Designers, Product strategists, Senior Developers, Project Managers etc . Subscriptionis split 40% USA, 50% Europe.

Contact us: For further information on any of our services contact us at: [email protected] or+353 2838073.

Insight for Web Service &Software Component Practice

IMPORTANT NOTICE: The information available in this publication is given in good faith and is

believed to be reliable. CBDI Forum Limited expressly excludes any representation or warranty

(express or implied ) about the suitability of materials in this publication for your purposes and

excludes to the fullest extent possible any liability in contract, tort or howsoever for

implementation of, or reliance upon, the information contained in this publication. All trademarks

and copyrights are recognised and acknowledged.

Subscribe to theCBDI JournalThe CBDI Journal is

published monthly. In

addition to the CBDI

Journal, subscription

includes electronic access

to all back numbers that

now represent a significant

resource library. There are

individual and corporate

subscriptions schemes.

Corporate subscription

includes access to our

workshop materials.

For more details and to

subscribe see:

www.cbdiforum.com


inside - CBDI Forum › public › downloads › LzStd › journal2003-03.pdf · The Back-End:...

Documents

Transcript of inside - CBDI Forum › public › downloads › LzStd › journal2003-03.pdf · The Back-End:...