cbdijournal - cbdi forumeverware-cbdi.com/public/downloads/-hpg9/journal2003-04.pdf · wakesoft...

April 2003We continue our drill down on

SOA practices with Part II of our

series plus a Worked Requirements

Example and a Service Based

Product Review

CBDIJournal3 Editorial

4 Best Practice ReportModeling for SOA - Worked ExampleOur recent article on Modeling for SOA was receivedwith great interest by members. In this follow-up article,we explore by example some aspects of a simple butpotentially collaborative business process.By Richard Veryard

13 Product Report The BT Authentication ServiceThere’s an entire industry growing around how weidentify ourselves. In this report we discuss a welcomereal world initiative from BT to provide an authenticationWeb Service.By David Sprott

18 Product ReportWakesoft J2EE FrameworkA extended Java framework and runtime that implementsSun’s best practice J2EE patterns in a loosely coupledapproach to deliver an application architecture for SOA.By Jonathan Stephenson

23 Best Practice ReportServices Oriented Architecture -Part 2 - The BridgeIn the first part of our series on SOA last month, weprovided detailed guidance on where to start. Thissecond part in the series presents a “bridge” thatprovides one-to-one mapping from business structuresand rules to IT components and algorithms. This is thefirm foundation required for agile businesses.By Oliver Sims

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

Thanks to all our members that contributed to the CBDI

Web Services Survey during February and March.

Hopefully you will have noticed from the weekly CBDI

Newswire that we published the results on the 27th March,

and the detailed results are now available online.1 There are

many insights that can be picked up from this survey, but

let’s just examine a couple:

Editorial

CBDI JOURNAL © CBDI Forum Limited, April 2003 3

www.cbdiforum.com

CBDI SURVEY EXTRACT: 70% of thoseresponding expressed a commitmentto using or adopting SOA. From ourinterviews it was clear that manyorganizations consider that Service is theimportant concept, not Web Service. WebServices is just today’s hot technology.

We have come to the conclusion thatthere is a fundamentally different mindsetthat needs to be brought to bear whenusing the Service concept. As we allknow the essence of a Service is that itis an improved form of component, ablack box. In this month’s CBDI JournalRichard Veryard advises that the essenceof understanding Service orientedrequirements is to manage the hiding ofcomplexity. He suggests there arevarious forms of complexity and thatunderstanding these, and makinginformed choices provides a systematicand sound business basis for makingwhat might otherwise be purelytechnical decisions relating to forexample granularity and scope.

Richard then goes on to demonstrate theapproach using a worked example inwhich, using the highly topical airportdeparture and security process, heillustrates how Service thinking canradically improve business andinformation support processes.

CBDI SURVEY EXTRACT: 47% of surveyparticipants plan to have a defined

process for Service delivery by the endof 2003.

Regular readers will recall that we havepublished several commentaries andreports on the software delivery processover the past 12 months. The recentsurvey confirmed our thinking that weneed an overlay to the current processesthat are widely used in the softwaredelivery life cycle, and that manyorganizations are now starting toconsider this.

Earlier this year we talked to a number ofmembers about whether there was somemerit in a CBDI led initiative to createsome level of common definition of thatprocess overlay. We have had verypositive feedback to this suggestion andover the next couple of months we areholding meetings for in interested partiesto discuss these matters.

You may like to look at some of therecent papers we have published in thisarea as well contribute to the activediscussion forum2. If you and or yourorganization are interested in thisinitiative we would like to hear fromyou. Hopefully we have alerted everyonewho has already signalled their interestin response to earlier reports, but if youhave an interest and have not hearddirectly from us please let me know.

Regards, David [email protected]

EXTRACT FROM CBDI WEBSERVICES USAGE SURVEYRESULTS:

● 70% of those respondingexpressed a commitmentto using or adopting SOA.

● 47% of survey participantsplan to have a definedprocess for Service deliveryby the end of 2003.

CBDI is now motivating aninitiative to better define theService Oriented DeliveryProcess. Contact us now ifyou would like to participate.

1. CBDI Web Services Usage Surveyhttp://www.cbdiforum.com/bronze/webserv_usage/webserv_usage.php3

2. CBDI TOPIC AREA on Web Services LifeCycle Process including various papersand discussion forumhttp://www.cbdiforum.com/report.php3?topic_id=7

4 CBDI JOURNAL © CBDI Forum Limited, April 2003

By Richard Veryard IntroductionIn a complex situation, we expect tomodel the requirements from severaldifferent perspectives, presenting aseries of coordinated models, as shownin Box 1.

One of the key design issues for SOA isto determine the scope and granularityof each service. SOA modeling helps toachieve this.

The identification and design of serviceswithin a service-oriented architecture canin principle be based on any of thesemodels. Many methods use a singleapproach for the identification and

design of services. While this may workwell in some environments, no singleapproach is ideal for all situations. CBDIhas therefore advocated that SOAdevelopers use a combination ofdifferent models and approaches toaddress different requirements. Servicesare defined and scoped to hide variousforms of complexity, as shown in Table 1.

Hiding complexity yields a gain inmanageability, as well as flexibility andreuse. Business analysts should considercarefully which type of complexity ismost at issue in a given situation, andchoose the appropriate modelingapproach accordingly.

Our recent article on Modeling for SOA was received with

great interest by members. In this follow-up article, we are

going to explore some aspects of a simple but potentially

collaborative business process.

With web services, it becomes feasible to automate a wide

range of services, and make them available both through

multiple technical channels and via third parties. If the

intention is to achieve massive reuse and economies of

scale, then this carries an obligation for precise and

accurate specification, since small errors in a publicly

available service can generate huge business problems

very quickly. CBDI has always advocated modeling; in this

article we provide a discussion of the possible business

and management opportunities opened up by proper

service modeling.

Modeling for SOA –Worked Example

Best Practice Report


continues...

Case DescriptionMost readers will have some experienceof flying – although many of us are lessfrequent flyers these days than theairlines would wish. So I’m going to lookat the passenger departure process –from arrival at the airport to boardingthe plane.

Let’s start by discussing why this mightbe a suitable opportunity for a service-oriented architecture. It’s because ofthe business potential of increasingdifferentiation and increasing federation.

Differentiated ServicesIn differentiated services, serviceoutcomes depend on context. Forexample: sometimes a passenger mayget a free upgrade.

Traditionally, this is at the discretion ofthe check-in agent, and is governed by

In complex cases, more than one typeof complexity may be important andworth analyzing. In such cases, it may beappropriate to use several approachesin parallel, and then reconcile andintelligently combine the resulting servicedefinitions.

Logical modeling helps to decide thescope and granularity of businessservices at an abstract level. These maythen be implemented as new webservices, or they may be mapped againstany available services (whether usingweb service protocols or not) that can beexposed from legacy systems ornegotiated with third party serviceproviders. As with any logical-to-physicaldesign mapping, the scope andgranularity may be the same betweenlogical and physical – but doesn’t haveto be.

policies and procedures, which are partof the agent’s training. If these policiesand procedures are changed, thesechanges have to be communicated to allcheck-in agents – and there are variousways of doing this, with varying levels ofaccuracy and reliability.

Meanwhile, if you check in at anelectronic kiosk, there is no chance ofgetting a discretionary upgrade. For thisreason, frequent travelers sometimesprefer to queue at the desk, if timeallows, since they may be able to speaksweetly to the clerk and get upgraded.Meanwhile anxious terrorists – or justpassengers who want to sneak on anextra item of hand baggage – mightprefer to use electronic check-in toavoid having to face questioning by thecheck-in agent.

Level

Market

Business

InformationComputation

EngineeringTechnology

Model Notations

ImplementationLanguages

Models

Domain Semantics

Business Asset Model Business Rule Model Business Service Model Business Process Model

Information Object Model

Service Context Model Service Policy Model Federation Model

System Policy Model System Service Model Collaboration Model

Demand Model

Operational Simulation Model

Class Model Predicate Logic Use Case Model Interaction Model

e.g. XML e.g. OCL e.g. WSDL e.g. BPEL

Box 1: Modeling Framework

Perspective Scope

Process/CollaborationModeling

Data/DocumentModeling

Rule/Policy Modeling

each service handles asingle process step

each service handles asimple set of data elements

each rule is encapsulated ina separate service

Hides

service hides operationalcomplexity

service hides datacomplexity

service hides business logic

Defines

define services using processand interaction diagrams

define services using classdiagram or data model

define services using rulediagram

Table 1: Perspectives for Modeling Services


Modeling for SOA – Worked Example continued...

removed by increasing interchangeability.

Federated ServicesAnother reason this example isinteresting from an SOA perspective isthat it allows us to think about servicedelivery as performed by a network ofcollaborating entities.

For example, at some airports, thecheck-in is performed by local agents, orvia third-party channels. Meanwhile, anairline may perform/support check-in,baggage handling and other services forpartner airlines at its “home” airport.

As we have seen, it may be difficult todeliver a differentiated service over anelectronic kiosk; but it is often even moredifficult to deliver a differentiated servicevia third-party agents. Frequent flyerpassengers may get excellent treatmentat some airports, but may be deniedaccess to their expected benefits insome foreign airports. While airlines havegotten better at sharing lounge access,for example, there are still gaps inthe service.

Three ModelingApproachesIdentifying the requirementsTo design a set of services on an

electronic kiosk, we need to start byidentifying a set of requirements. This isnot as simple as it seems. The obviousapproach is to start with our ownbusiness process, and design theservices on a kiosk to support thisprocess. However, this approach typicallyfails to produce reusable services. Eventhe domain modeling approach, wherethe process model is generalized to will be limited in the reuse itcan achieve. Much higher levels of reusecan be achieved by taking a much largerscope, and thinking about the broaderrequirements and opportunities of theecosystem in which the kiosk is to besituated – in this case, the airport. Whatactivities are going on in the airport, andhow might a kiosk interact usefully withthese activities? Many airports have oneset of machines for electronic check-in,one set of machines selling tickets forlocal transport, and a third set ofmachines accepting payment for the carpark. If we think about building a kioskthat can support all of these services, wecan then start to think about bundlingand recombining these services inways that add value for passengers.Furthermore, this analysis might causean airline to consider not only the needsof passengers, but of any relatives and

We may suppose that there are businessadvantages in electronic check-in, interms of speed and efficiency. We mayalso suppose that there are businessadvantages in providing differentiatedservices of various kinds. To gain greateraccess to these business advantages,airlines might therefore want to makeelectronic check-in more sophisticated,to support at least some elements ofservice differentiation. Electronic kioskscould support a range of biometricchecks logically equivalent to those ahuman agent might make – is thepassenger sweating, agitated, lookingfrightened, etc. Software can alsomeasure the response time of thepassenger, and may make usefulinferences about the passenger and hiscontext from any lengthy hesitation –just as a human agent does.Uncharacteristic hesitation may be asign of impersonation, or it may signala need for help.

In any case, we might expect thecheck-in service to be broadly the same,regardless of whether it is executed by ahuman check-in agent or an electronickiosk. Although it may never be possibleto impose total consistency for the sameservice across different access channels, some needless complications can be

Requirements Modeling Approach Electronic Kiosk Example

Our Business

Our Domain

Our Ecosystem

Identify Business ProblemIdentify “Users”Negotiate RequirementsDefine Solution

Identify DomainIdentify Domain ExpertsDefine RequirementsDesign Solution Kit

Identify EcosystemIdentify ServicesProcure & Release Devices

Design the services on a kiosk to fit with our own businessrequirements

Design the services on a kiosk to fit with a generic view ofthe business requirements of any airline

Design the services on a kiosk to fit with a view of theprevailing demands in the chosen environment (airport)

Table 2


continues...

not true. Take security search, forexample. In the current internationalenvironment, we should not be surprisedto find that security procedures are muchstricter than they used to be, and thatthey vary according to context – suchas the destination of the plane. Securitysearches may be repeated duringdifferent process steps before thepassenger is allowed onto the plane, andadditional adhoc checks performedagainst security blacklists. In a traditionalsystem, manual physical searches maybe carried out repeatedly at the securityagent’s discretion, without formal controlor monitoring. But in an automatedservice-based system, we need to modelsuch variations explicitly, with preciseand formal controls. Such variation isdifficult to represent clearly inconventional process models. We’llcome back to this one.

Another potential problem with theprocess model is the limitation of scope.While it may be useful to show theprocess as perceived by the airline, thisis not the only perspective. From thepassenger’s perspective, the model inFigure 1 is incomplete. When apassenger arrives at an airport to take aflight, he undergoes a sequence ofactivities. While some of these activitiesare obviously a necessary part of thedeparture process, others (shown belowthe dotted line in Figure 2) may representzero or negative value for the passenger.

friends who accompany them to theairport – and this consideration may leadto further business opportunities.

Decomposing the requirements andidentifying servicesAs indicated in Table 2 and 3, thereare three ways of decomposing therequirements to identify the services.

Much of this modeling will be familiar toreaders, and this article is not intendedas an introduction to all aspects ofmodeling. Instead, we are going toillustrate some of the new opportunitiesof SOA, especially in terms of theseparation of process, data and policy.

Processes and CollaborationsA conventional view of the passengerdeparture process is shown in Figure 1.

Figure 1

Perspective Basis for decomposition

Process/Collaboration Modeling

Data/Document Modeling

Rule/Policy Modeling

First cut decomposition based on activities

First cut decomposition based on things(so-called business objects)

First cut decomposition based onbusiness goals

Example

Example: Check-in, Board

Example: Passenger, Flight

Example: Reward Loyalty, No TerroristOn Plane

Table 3: Three Ways of Decomposition

Note that CROSS BORDER andBAGGAGE DROP are conditional – theyare always required under someconditions (international flights,overweight baggage), and never required under some other conditions (domesticflights, handbags only). In some methods,such process steps may be referred to as“optional” – but this can be a misleadingterm, since it suggests that there isa choice.

In a conventional process model, theseconditions would either be directlyhardcoded into the preconditions of theconditional process steps themselves,or indirectly hardcoded into thepreconditions of some later processstep. For example, BOARDPLANE mayhave a precondition .

The word “hardcoded” in the previousparagraph will alert some readers to apotential inflexibility in this approach.Perhaps the rules applying to CROSSBORDER and BAGGAGE DROP haveremained much the same for decades,and are common across all airlines andairports. If this assumption is true, thenthe hardcoding may not matter verymuch. But in these interesting times,long standing convention is no basis forassuming future stability of requirements.

In any case, there are other exampleswhere such an assumption is definitely



In either case, we must be wary of apossible semantic mismatch betweeninput and output. maynot have the same meaning in bothplaces, because the passenger’s notionof cleanliness may be different to thecleaning company’s notion. The cleaningcompany’s preferred notion of cleanlinessmay be simply – but the airline willprobably prefer to define the outcomemore rigorously, perhaps in terms ofa further independent service . Wetherefore need semantic models thatallow these notions to be preciselydefined and mapped together.

Managing ServicesManagement of the process may includea requirement to coordinate input andoutput.

There are several potential interdepen-dencies between the input services.Either loading the passengers, baggage,fuel and other supplies must wait untilthe safety checks are complete. Or ifa plane fails a safety check, then

Figure 2: The Importance ofBroadening Scope

However, these process steps may beimportant for other participants in thebusiness collaboration, including the air-port authorities and the various retail out-lets that support the economics of theairport.

● Waiting passengers spend money,which generates revenue.

● Passengers walk at differentspeeds, which reduces congestion.

● Some passengers may be willingto pay extra to avoid inconvenience(“fast track service”)

Modeling ServicesA business process transforms a set ofinput services into a set of outputservices. Both input and output servicescan be expressed as use cases. But usecase descriptions alone don’t give us aview of how the whole process hangstogether. We need a way of mappingthe process logic and service context,between input services and outputservices.

An output service is typically dependentupon one or more input services, asshown in Figure 3.

● hasprecondition

● has postcondition

Alternatively, may beidentified as part of a service levelagreement (SLA) on input and/or output.

Figure 3: Business ProcessTransformation

A business process

transforms a set of input

services into a set of

output services. But use

case descriptions alone

don’t give us a view of

how the whole process

hangs together.


2. If security policy relies on simplecharacteristics, it is easily evaded byintelligent attackers.

● We assume all terrorists comefrom specific countries.

● We assume all weapons aremade of metal.

Successful classification typically involvesa complex combination of attributes andbehavior patterns. In general, we maywant policies to be opaque and changedregularly, to make them less vulnerableto manipulation by outsiders. This mayapply to commercial policies as well assecurity policies.

two subclasses, in order to eliminatesecurity threats.

● Normal passengers versussecurity threats

● Normal bags versus bagscontaining weapons.

These aspects of security policy cantherefore be represented in a data orclass model, using traditional datamodeling techniques. But there are anumber of issues with this.

1. We may want security policyenforced by agents (such as thirdparty service providers) who don’thave access to all relevant data.

passengers, baggage, fuel and othersupplies may have to be off-loaded.

An airline may either hold everythinguntil checks are complete, or go aheadwith the possibility that some actionsmay have to be reversed out. This choiceis typically represented in policy.Alternatively, the responsibility for thischoice may be delegated to the serviceprovider. If you want this choice to bemade intelligently, then the serviceprovider will need to be given enoughcontext to achieve this.

Coordination of the process may includethe allocation of resources. For example,where input services are resource-constrained, a resource allocationdecision is required, to determine whichplane to service first. Obviously there is aproblem if the catering company decidesto supply plane A first, while the cleaningcompany decides to clean plane B first,because this may mean neither ofthem will be ready. Such coordinationrequirements can be implemented invarious ways – either through directpeer-to-peer contact between serviceproviders or as part of the coordinationfunction of the calling process.Coordination of this kind is especiallyrelevant in handling exceptions andcontingencies – which is where muchmanagement effort has always beenspent. But regardless of how they areimplemented, and by whom, suchrequirements may be specified in termsof postconditions or invariants on adefined set of separate but collaboratingservices.

Modeling Policy via Data or ProcessScreening passengers and baggagefor security threats is a classic CRM(customer relationship management)requirement - classification leading todifferential treatment. We are trying toclassify passengers and their bags into

continues...

CRM Insight – Decoupling Data Requirement from Data Solution

What an airline WANTS to do is identify bags containing weapons. This is therequirement. What an airline ACTUALLY does is identify bags containing suspectartifacts. In practice, many innocent items arouse suspicion, while genuineweapons sometimes slip through. Over time, we might hope to refine the criteriafor suspicion, so that we have a higher chance of detecting weapons, with fewerfalse alarms.

Problems of this kind are very common with CRM. What a company WANTSto do is identify customers who are going to buy more product and generatemore profit. What it ACTUALLY does is define a set of selection criteria againstthe customer database, which it uses to target customers for special attention(differentiated service). Selection criteria are evaluated retrospectively, todiscover how accurately they have targeted the customers, the varied andrefined over time.

Many firms prefer to keep the actual selection criteria secret from competitorsand business partners, as well as from the customers themselves. They believethat if customers discover the criteria, they can manipulate them to their ownadvantage. (The relationship between secrecy and security is a complex one.See CBDI Journal article on Identity and Services, September 2002.)

The logical separation here between requirement and solution has importantimplications for class modeling. Both WEAPON and SUSPECT ARTEFACT needto be visible as classes, or at least as subclasses of BAGGAGE. These should bedecoupled in the class model, so that some services may reference WEAPONwhile other services reference SUSPECT BAGGAGE. This means we candifferentiate services in terms of the underlying business or security requirement(WEAPON) while varying and refining the detection criteria (SUSPECT ARTEFACT).It also means we can reveal information about one class and not the other.

Box 2: CRM Insight – Decoupling Data Requirement from Data Solution



Persistent context for a passenger arethose attributes and preferences thatremain from one flight to the next:frequent flier, seafood menu, wheelchairuser, security blacklisted, and so on.Transient context for a passengertypically relate to a single journey: latecheck-in, travel in group, connection atother end, suspicious behavior, and so on.

As Figure 5 shows, policies such assecurity may be applied at any stage of

contract. Policies may reference variouselements of context. There may be someelements of context for each businessobject touched by the service. SeeFigure 4.

Context may be persistent or transient.

Decoupling the data model as describedin Box 2 allows us to specify relationshipsmore precisely between third parties anddata. E.g. do the police performing thesecurity check have access to airlinebookings? Do they, or should they haveknowledge of who specifically is passingthrough the security check? Conversely,if the police have concerns about anindividual passenger, how and at whatstage does the airline get notified of thisconcern? Security policies may also beembedded inside process descriptions.For example, screening passengers andbaggage for security threats takes placeat various stages of the process. Eachprocess step may execute some elementsof the security policies. Third party andlegacy processes may embed/assumevarious policies.

However, where policies are representedin the data or process model, we areusually constrained to fairly simple(binary) policies. Complex policiesgenerally require more explicit modeling.See Table 4.

Modeling contextPolicies may define or modify the service

Binary Policies Complex Policies

Tests have a definite outcome with two possibilities.

Upgrade at check-in? Yes/No.

Security check? Pass/fail

This makes downstream process steps more simple,because they can assume context.

“If this passenger has been allowed to reach this stage, shemust have passed all necessary security checks.”

If a simplification is unacceptable, it is not just because theassumption is false – most systems are based on simplisticassumptions that are not totally valid. In this example, theassumption is also dangerous – in terms of the risk ofgetting it wrong.

Tests may have complex outcome, including deferred callsto further processes and policies.

Each process step may add or modify the context. Eachprocess step may be sensitive to context.

This makes process steps more general (powerful, reusable)because they can be applied across multiple contexts.

This makes systems more flexible, because their behaviorcan be modified by altering policies.

Complex policies may avoid simplistic assumptions andtherefore be more accurate. But higher levels of complexitymay be harder to manage, and this introduces a differentset of problems and risks.

Table 4: Policies may be binary or complex

Figure 4: Services are driven bypolicy and context

Figure 5: Context Sensitive PolicyApplication

We can now fully

decouple the process

from the policies, gaining

greater flexibility and reuse

in both departments.


continues...

delays for economy passengers, the greater the benefits of “fasttrack”security for club passengers. For thisreason, investment to improve speedof immigration and security processes(including biometrics checks) maybe introduced to business classpassengers first.

Figure 7: Policy Effects on BusinessPerformance

Management may adjust policies toimprove the security and otherperformance aspects of the system as awhole. Policy changes may have complexeffect on business performance. Minorpolicy changes may sometimes havemajor consequences on businessperformance, while multiple policies mayinteract in complex ways.

For example, it may be obvious that strictsecurity may increase costs and causedelays, while lax security may increasethe chances of incidents leading toservice disruption (and worse). But whatmay be less obvious is that tight securitymay sometimes have counterproductiveeffects – especially if it generates lots of

the process. At each stage, the policymay determine the need for furtherinformation or monitoring.

Policies may involve collaborationbetween multiple service providers,which may involve shared processes aswell as shared context. Collaborationmay itself be subject to policies, such assecurity & privacy policies, as well ascommercial policies covering cost,risk/liability and compensation.

We can now fully decouple the processfrom the policies, gaining greaterflexibility and reuse in both departments.The same policy may be referenced atseveral points in the process. A policymay be shifted sideways or repeated.Redundant policy may be removed.Policy may be made stricter or morelenient.

Figure 6: Policy Driven ServiceDifferentiation

As shown in Figure 6, policy may be usedto provide some service differentiation.For example, the longer the security



false alarms and diverts attention awayfrom genuine security threats.

Another reason for separating policyfrom process is that policy ownershipmay be organizationally separate fromprocess ownership. Processes can betuned to deliver widely varying businessperformance by plugging in differentpolicies, without changing the underlyingprocess.

Policy SummaryOur models of the passenger departureprocess show clearly how system

We have also seen how small policychanges may cause major system failure.The performance of the system may bevery sensitive to policy. A policy for onebusiness goal may have a negative effecton other business goals (side effects,interference). A business goal may evenbe undermined by counterproductivepolicies. It may therefore be useful oreven essential to simulate theimplementation of a policy beforeenacting it.

In the Service-Oriented Architecture, wetherefore recommend modeling policiesexplicitly, and using them to defineseparate services, driven by context.This decoupling creates the potential toachieve much higher levels of flexibilityand reuse.

Modeling SummaryIn this article, we have mainly discussedSOA modeling from a technically neutralperspective. Even though an abstractinvariant service model may not makethe technological details explicit, it isapparent in this example that automationhas the potential to change the behaviorand performance of the whole system inquite radical ways.

Richard Veryard [email protected]

behavior depends on policies. Policiesmay have a complex effect on businessgoals. The business may want toexperiment with different policies.Policies can be defined at any level ofgranularity. Greater granularity offersgreater flexibility and control, whileexcessive granularity causes complexityand may be unmanageable.

When modeling, therefore, it makessense to start with the simplest possibleset of policies. Allow for incrementalpolicy refinement later.

Figure 8: System Dynamics Models

To-BeDefine web service specifications

Create and deploy web services

Bind and manage SOA system

InvariantModel abstract services in atechnologically neutral way

As-IsDetermine service orientation inLegacy Systems (data/process)

Model implicit services, includingpolicy services

Expose & wrap services

Refactor to improve decoupling

Figure 9: Service Reengineering Process: From As-Is to To-Be


continues...

By David Sprott

Security, privacy or digital identity, take your pick. There’s

an entire industry growing around how we identify ourselves.

But as usual it seems that we are in danger of letting the

technology drive the solutions. In previous reports we

have emphasized the centrality of the consumer in the

authentication process and the need for systems thinking

to be brought into play. In this report we discuss a welcome

initiative from BT to provide an authentication Web Service.

The BT Authentication Service

Product Report

IntroductionIn our report last September, EstablishingRequirements for Identity1, we challengedthe current security strategies of manyindustry players, which seem to bedriven by provider needs rather thanconsumers. We suggested that thecurrent emphasis on single sign-on, asit is currently being presented, is illconsidered and will probably be rejectedby many consumers as increasing riskrather than reducing it. We advised onthe requirement for a coherent identitymanagement system and the criticality ofdesigning identity systems that first andforemost protect the interests of theconsumer.

The primary concern that serviceconsumers have is that their interactionwith a service is secure, such that otherscannot make use of the service usingtheir identity. Any authentication systemneeds to provide visible evidence to theconsumer that their interaction isabsolutely confidential and that otherscannot access their confidential services.

The common response to this concern isto use physical verification, for example smart cards, or biometrics which rangefrom retina scans through voicerecognition. The problem with biometricsis that no sooner has the technologybeen perfected, than some bright personfinds an equally clever way to circumventthem. Smart cards can be lost or stolen,and passwords can be broken. Retinascans can be replicated with contactlenses. Finger prints can be copied ontogelatin prosthetics. As we have noted inour report on Establishing Requirementsfor Identity we need an holistic systemsapproach, and not surprisingly newtechnology isn’t always the answer.

The general principle here is that identityis no longer regarded as monothetic(dependent on a single characteristicfeature) but as polythetic (dependenton several characteristic features). Thesystem no longer regards me purely afunction of my fingerprint or iris scan,but is able to use a range of alternativeauthentication mechanisms. CBDISeptember 2002


Single “Identity” Is the KeyThere is rightly much skepticismsurrounding efforts in the industry aroundidentity. The problem is people will keepgoing on about single sign-on” andthat is a complete irrelevance to the realproblem that we do badly need to fix.

Whilst we all have many user ID’s andpasswords, that we consistently lose,and or fail to remember, they are aninconvenience, not a critical issue.Whilst many sites are inherently insecure,for example openly mailing lostpasswords without encryption, securitymechanisms surrounding web site usageare generally pretty good where theyneed to be. For example with my ownprivate banking system I am challengedto provide parts of pre-arrangedkeywords that are known only to myselfand my bank, which gives me, togetherwith the encryption of the messaging, alot of confidence that only I am able totransact on my accounts.

The problem is the integrity of my accessto the banking system is not scalable - toset up the on-line banking I had to visitthe bank in person and providedocumentary evidence and photo ID, sothat there was physical verification of myidentity. I have a similar arrangement withinsurance and investment companies,but I have to say that I perceive these asless secure, because they were arrangedby snail mail, which could more easily beintercepted.

So as a consumer, if someone could offerme a Web Service which allowed me tohave the same level of visible integrityas I have with my on-line banking system,I would actually be very interested. Iwould see this not just as a value addingservice, but a critical security component.

It occurs to me that in conventional termswe already have an authentication model

The BT Authentication Service continued...

out the clear opportunity forintermediaries, to offer value addingservices on a horizontal and verticalbasis. Last year we reported on BTwho announced their Web Servicesmanagement strategy2 see Box 2.Recently we talked again to BT and werereally interested to learn that one of theirhorizontal service offerings will be anauthentication service.

The BT AuthenticationServiceBT is developing what they call an onlineidentity checking service, branded asURU. The purpose and scope of theservice is to authenticate and validateidentities and addresses in the UK.

The service is initially based on adatabase which has been developedby GB Group Plc, a UK company thatspecializes in proving identity. GBprovides a National Register databaseservice containing historical and currentUK population data. The GB databasehas been developed over the past sixyears and is currently used to support anumber of call centers. The new service

that has some lessons for us - it’s calleda notary. The notary or public notary,depending on which country you live in,is an individual who is either a publicservant or certified person who providesa service which authenticates documents(and therefore by implication individuals).

Notary, n, (public) person publiclyauthorized to draw up or attestcontracts etc, protest bills ofexchange, etc, and perform otherformalities, hence notar IAL.

And in case you think notary services area thing of the past, my own personalexperience is that Network Solutions Inc.use them as a regular part of theirprocess for (web site) registrant changes,to ensure the applicant is who they saythey are. So if you want to transferwww.amazon.com to yourself, you willhave to convince a notary that you havethe authority to do so!

BT - Web ServiceIntermediaryIn our Web Service research over the past few years CBDI has been pointing

A CASE OF MISTAKEN IDENTITY

Last month a British pensioner and charity worker Derek Bond was arrestedduring his vacation in South Africa and held in prison for three weeks in a caseof mistaken identity. Mr Bond had been mistaken by the FBI for their real wantedman, multi-million pound fraud suspect Derek Lloyd Sykes. Evidently Mr Sykes,also a British citizen who is now in custody and awaiting trial in Texas, may haveused, among other names the pseudonym and false identity of Derek Bond aslong as 14 years ago. A news conference was told that Mr Bond's passportnumber had somehow been added to the FBI “wanted” notice about Mr Sykes.

In this age of ultra-fast communications, one would have thought that such acase of mistaken identity would have been cleared up within hours or at worst acouple of days. For some reason best known to themselves, the FBI insisted thatDerek Bond be held by the South African police pending extradition to the UnitedStates, a process which had been incepted four days after his arrest.

Source BBC News

Box 1: Mistaken Identity Can be Serious


continues...

The standard service accepts 2 or moreparameters (questions) and a response isreturned with MATCH/NO MATCH statusindicated in the result fields. It istherefore a provider choice of how manyand which fields are used in theauthenticate process, to determine thelevel of checking. GB indicates thatcurrently they have approximately 50%coverage in the UK. Whilst they areworking hard to extend the coverage,they believe their service is fullyjustifiable at this stage. If there is nomatch on an authenticate service request,then the agent will revert to aconventional manual authenticationprocess perhaps requesting certaindocuments by surface mail to corroborateidentity. GB makes the point that if50% of authentication requests can beautomated this represents a huge saving in agent time and not insignificantlyincreases customer satisfaction. As arelatively unsatisfied customer of the

BT ANNOUNCE WEB SERVICES BASED PRODUCTS

Last week BT announced a strategic initiative to enter into the web servicesarena. Interestingly BT’s web services approach is much broader than thefootprint of their conventional business model. They are offering an end to endsolution service including a web services application component library, adeployment environment and a web services management layer ... This broadlybased announcement suggests BT has recognized their core competencies ofmanaging networks and systems integration provide a basis for value addedservices.

The BT announcement represents a small but significant step towards arevolution in how Services are delivered. In our work on Service businessframeworks we suggest that the telcos are ideally situated to act as what wedefine as a super intermediary - a middleman that aggregates and provides bothtangible (SLA’s) and intangible (brands) product offerings that encourageconsumer and business trust in remote service operation. This model will slowlyevolve over the next five years, and will soon be recognized as a radicalreengineering of the Service delivery process.

CBDI Commentary October 2002 3

Box 2: BT’s Web Services Product Strategy

operated by BT, links to the GB databasewhich checks an individual’s identity inreal time by comparing basic dataprovided by the individual with theinformation already in the register, whichincludes links to other reference sourcessuch as the National Criminal IntelligenceService, HM Customs and Excise andNational Crime Squad, plus mortalitydatabases and the electoral register. Theresults of the checks are then passedback to the BT service.

The service is aimed at determiningwhether someone is pretending to besomeone else using the minimumnumber of questions. The servicerequests answers to specific questions,such as Post Code/Address, Telephoneno, Postal address, House next door and(believe it or not) Closest pub (publichouse), although sadly the latter moreinteresting questions do not appear to bepart of the standard service specificationyet, see Figure 1 on page 16.

archetypal call center, I can only agreewith this.

Authentication ServiceFuturesThe URU service is one of a number ofstandard services that BT is offering theircustomers as value added services (theyactually call them components) on topof their web services managementinfrastructure. The service will bepublished in the BT Web Services libraryand is intended for widespread usage,both by organizations using BT’s systemsintegration services, but equally as webservices consumed by competitiveorganizations such as EDS.

BT initially plans support for twointerface mechanisms - web sites andCRM systems. This will be followed byan IVR service (more on this below)which will verify the identity of the callerbefore the caller is put through to the callcentre agent. This will prevent the agentfrom hearing confidential information andreduce their time on the call.

BT sees URU as having strategic potentialinsofar as it could become a majorapplication in its own right. Initially BT isusing the GB database as the primaryauthenticating source, but whilst they arevery happy with GB as a strategicpartner, their contract is non-exclusive,and both parties fully expect BT tosignificantly expand the sources over time.

An obvious question was what aboutBT’s own telephone directory? But ofcourse BT is a regulated company and isrequired to offer services on a freemarket basis, so GB actually alreadyacquire the BT directory along with anumber of other intermediaries. BT ishowever investigating various otherdirect sources including governmentdatasets such as the Driver Vehicle


The BT Authentication Service continued...

Licensing Authority (DVLA). The UKgovernment has imposed strictauthentication requirements on suchactivities as gambling in its quest tostamp out money laundering, and initialindications are that governmentdepartments will be able to assist inmaking databases available under strictusage conditions. What is helpful hereis that the UK Deputy InformationCommissioner has taken a view that thisform of authentication is not in factdata sharing, because of the nature ofthe service result which only returnsMATCH/NO MATCH status.

A further stage of evolution beingassessed by BT is the option for datasubjects (citizens) to register with URU.There are some considerable benefits ofregistration because the service will notifythe data subject of every authenticationrequest by email, which will of coursecause an immediate alert if animpersonation attempt is made.

What this indicates is there will bevarying levels of certification of identity,which will be dependent on the dataavailable. For the higher levels ofcertification, the registration step is ofcourse a critical part of the process. BT iscurrently planning to promote theauthentication service for corporateusage, which will as a by product createa large number, perhaps as many as 2million individuals over a relatively shortperiod of time, who have beenauthoritatively identified because of theiremployment. BT is anticipating a processwhereby certain classes of registrantwould then be able to act in a capacitysimilar to a notary to authenticate othersin the registration process.

I fully accept and support BT’s desire forcaution here, but in fact I think this islikely to be a major weakness in thesystem. I would recommend that

POST /uruws/uru.asmx HTTP/1.1Host: www.prove-uru.co.ukContent-Type: text/xml; charset=utf-8Content-Length: lengthSOAPAction: "http://bt.com/uru/interface/Authenticate"

string string string string int string boolean string int int int int int int boolean

guid

Figure 1: Authenticate Data

HTTP/1.1 200 OKContent-Type: text/xml; charset=utf-8Content-Length: length

string boolean string string string string string boolean string double string

Figure 2 - Authenticate Response


conventional notaries would be the ideal way of executing this process, andprovide everyone with a high level ofconfidence.

You might ask, what is the motivation onthe part of the individual? Why wouldanyone want to go to the bother andalmost certainly the cost of becomingregistered? My own response would bethat this would bring peace of mind in mytransactions, so that I could have thesame peace of mind that I have intransacting on line with my bank today,but with a myriad of other online sites forpretty much any purpose.

In every country there will be a choice ofauthenticator that you choose to registerwith. Interestingly GB is working with amutual company that holds key questionson behalf of individuals, which for dataprotection reasons would be separatefrom the authenticator role. Clearly BTtogether with its early stage partner, GB,has visions that in the UK they willbecome a major supplier of authenticationservices. However the service is alsodesigned to scale across Europe andresearch and trials will be conductedlater this year.

BT’s view, after talking with the Office ofthe Information Commissioner, is that theURU approach raises no significant DataProtection Act issues and (with no detaildisclosure), offers some tangibleadvantages. As the DP Act is Europewide, they are confident there will beno privacy/data protection issues inother EU countries.

BiometricsIn the introduction to this report Imentioned some of the issues withbiometrics. But the key issue is thatbiometrics must be used in conjunctionwith other mechanisms. BT has somereally interesting plans in this area, based

on developing IVR (interactive voice

response) based authentication. Not

surprising because of course as a telco

BT will be really keen to see its core

technology in use, but more importantly

this is a device that is cheap and already

ubiquitously available for use by any of

their potential customers. As I concluded

in my report on Voice Components last

November4 this is a technology whose

time has come. BT is planning to use IVR

to have the individual repeat a series of

20 to 30 words and then with permission

capture a voice print.

When you want to invoke the authenticate

service, an IVR system will call you,

wherever you wish, (so it’s location

independent) and ask you to say a

selection of words. This of course can be

used in conjunction with basic

authentication mechanisms as well,

depending on the trust status of the

application, which of course can vary

depending on context.

SummaryBT is doing a number of ground breakingthings here. First they are creating acommodity (widely available, for massmarket use) service based product thatwill be available to a wide constituency,including their systems integrationcompetitors.

Second they are addressing one of thekey issues relating to service use -providing a strong authentication system,not just a set of protocols.

In our opinion BT will have someinteresting challenges in terms ofmarketing this service, but thatfundamentally it is likely to be highlyattractive both to provider and consumer,and have a clear value.

I support BT’s initial targeting of thecorporate market, although I am less

than convinced that this will yield theregistrant authenticator base they hopefor. However there are lots of othermarkets where BT can look to build awide base quite quickly, for examplecompanies that offer credit card protectionschemes would be ideal candidates thatmay be interested in both using andbeing a channel for promoting such asscheme. They and other channels mighteven assist in defraying the costs asbetter authentication will reduce fraud.

BT will need to understand the socialimpacts this might have on the way wetransact ordinary business. Althoughmost people are likely to feel safer withthis form of protection over theirbusiness dealings, some people may feelthreatened that this is big brothercoming in by the back door. Either way,eventually authentication is going tobecome part of everyday life and thisproject positions BT to be a centralplayer in a significant growth area.

David Sprott [email protected]

1. CBDI Best Practice Report EstablishingRequirements for Identityhttp://www.cbdiforum.com/secure/interact/2002-09/practice.php3

2. CBDI Best Practice Report - Experiences inAdopting Web Serviceshttp://www.cbdiforum.com/secure/interact/2002-11/adopting.php3

3. Thu 03 Oct: CBDI Commentary -Reengineering The Software Supply Chainhttp://www.cbdiforum.com/public/news/index.php3?id=1113

4. Reusing Voice Components and Serviceshttp://www.cbdiforum.com/secure/interact/2002-11/voice.php3


Product Report

By Jonathan Stephenson

Wakesoft have made Service Oriented Architecture their

focus and have an aggressive development program to

target this growing market. Wakesoft has developed a

Java framework that implements Sun’s best practice

J2EE patterns in a loosely coupled approach. In the next

release the framework will supply more runtime monitoring

and performance analysis, which will add the service

management capabilities required to build market share.

The term framework is not a well defined one and we look

hard at this product to see how much is ‘framework’ and

what is ‘run-time server’. A run-time dependency may put

some potential buyers off, but as Wakesoft builds more

management capability into this architectural layer the value

it brings will justify its contribution to the final application.

Wakesoft J2EE FrameworkExtended Framework and Runtime DeliversJ2EE Application Architecture for SOA

IntroductionWakesoft is one of a growing number ofJ2EE framework companies making theirliving from the complexities of the J2EEplatform. Based in San Francisco andrecently venture financed to the tune of$7M we were interested to see how a‘framework’ could attract so muchfunding. They have write ups of twocustomers on their site, one for insuranceclaims processing and the other financialadvice. In both cases the client wasprepared to pay for a ready-madeJ2EE framework (currently retailing at

approximately $14K per CPU) in order toensure the success of their projects.

The trouble with frameworks from thecommercial point of view is that it isdifficult to charge for them. Struts is aclassic example. The Apache Strutsimplementation of the Model – View-Controller pattern has been acceptedand adopted by many J2EE usersbecause it is free. To create a commercialproduct, the tools and runtimecomponents have to deliver somesignificant productivity gains. Wakesofthas created a framework which uses a


continues...

added to by the customer to provide newbehavior or new integration capabilities.

Throughout the framework you will findreferences to the famous ‘Gang of four’patterns1, which have been adopted andspecialized by Sun as the J2EE blueprints.

Installing WakesoftWe installed the evaluation downloadfrom the web site. The license key arrivedby email, and when we worked out whereto put it, the demo examples of Sun’sPet Shop and the cartoon e-dating webapplication provided two goodapplications into which we could dig forworking code examples. Documentationat the architectural level is good – notsure how programmers would find theirway round all the classes without sometraining. The ‘tutorial’ is a summary of thesteps and some folders of partly builtstages for the example – a step-by-steptutorial is needed here. The Wakesoftcommunity site has more trainingslide-ware with audio.

The Wakesoft components work with allJ2EE application servers and there areinstructions for Oracle, WebSphere,Weblogic and Tomcat/JBoss (with whichit ships).

You will need a full Java JDK and ApacheANT to complete the environment forbuilding applications.

Architecture and PatternsThe list of patterns implemented byWakesoft’s framework reads like thecontents list of the Gang of Four book1

and we will highlight just the main ones inthis report. The best way to understandthe framework in our opinion is tounderstand the problems they set outto fix. Let’s take the simple J2EEarchitecture; a JSP web tier that uses aStateless Session Bean to provide afaçade for a set of business objectsimplemented as Entity Beans. The

set of controllers (implemented asServlets and Classes) that implements alayered and loosely coupled applicationarchitecture where user interface flow,data mapping between web tier and thebusiness objects, and business rules areconfigured in XML files rather than hardcoded Java. In the persistence layer theadapter pattern implementation allowsfor plug-and-play data connectors whichprovide an added flexibility, especially fora company migrating to new platforms.

Wakesoft provides:

1. A wizard (‘accelerator’) to generate askeleton application from a set ofbusiness object definitions as, forexample, java classes.

2. A MVC implementation for the webtier based on a control servlet.

3. A data-mapping layer to mapbetween HTML forms, XML and thebusiness objects.

4. Server based input validation, loggingand error handling.

5. Business rules defined as a series ofre-usable steps either as part of theweb tier or EJB tier.

6. A uniform implementation of themanager/adapter pattern that provides,for example, a flexible objectpersistence layer.

7. Web Service and Java MessageBean support

The benefit of this type of architecture isthat the system can be reconfiguredwithout always needing recoding in Java.The flow of pages and the steps in thebusiness rules are defined in XML filesrather than JSP and EJB as in aconventional J2EE development.

The manager/adapter pattern providesthe extensibility that customers require,but in a flexible architecture. TheWakesoft adapters can be enhanced or

problems that Wakesoft set out to solveare as follows:

● Business rules become embeddedin the JSP layer as developerswork around limitations in the EJBSession layer.

● Navigation and presentation codeis embedded in JSP scripts.

● Business rules are coded in EJBsand can’t be changed without Javaprogramming and recompilation.

● Different persistence mechanismsare used for session and otherdata. Bean Managed Persistencecan create a dependency on aparticular database technologyand migration to new data storesis difficult without coding EJBs.

● Much code is written to map theHTML data entered on forms to thebusiness objects and is inflexible.

In the following sections we describe thepatterns used to solve these issues.Figure 1 gives the overview of thearchitecture.

Front ControllerThe Front Controller pattern is the oneimplemented also by Struts. Wakesoft’sis a more capable implementation but ofcourse you can stick with Struts if youprefer the Apache ‘standard’.

The implementation of this patternconsists of a Controller Servlet whichreceives all Form Posts from the HTTPserver and does a lookup in the XMLnavigation file to determine the action.This can include execution of abusiness rule or forwarding to a newJSP page. The controller servletdelegates the requests to the WakesoftNavigationManager which determinesthe next action.

A typical navigation XML file entry lookslike this:


A form submit to the controller servletwith the ‘edit’ PAGE value forwards to the Address.jsp script. The servlet deliversthe run-time capability; the Wakesoft

code generator builds you a skeletonXML navigation file but you have to thenbuild the user interface JSP tier and linkthe flow of pages by editing the XMLNavigation file by hand. There are nographical tools to manipulate or displaythe application flow in the currentproduct so you edit the XML by hand.

MapperThe MappingManager is probably themodule in the framework that does themost to reduce the number of lines of

Wakesoft J2EE Framework continued...

code written, especially in the JSPs. Inthe typical business application the JSPcode instantiates EJB Session Beansand populates their properties with valuesextracted from the request object, e.g.

String yyString =

request.getParameter(“year”);

if yyString !=null &&

yyString.length()>0{

try {

boPerson.BirthYY=Integer.

parseInt(yyString);

yyOK=true;

} catch (NumberFormatException e {

}

}

and that is just for one simple integer!The Wakesoft mapping tools provide aready built infrastructure to convertHTML posts into XML data, validate itand populate the business object. Anaming convention must be adhered toso that the framework can work outwhich form field ends up as whichbusiness object attribute. The mapperuses introspection to read the propertynames of the business object and also toapply standard data type checks to thedata. Custom mappers are written by thedeveloper to carry out more customizedvalidation.

The automatic marshalling of databetween XML and either the user-interface or EJB tier is a powerful featurethat streamlines the code you write inthe JSPs and focuses developers ondeveloping functionality not infrastructure.The marshalling of data between thethree logical tiers of HTML, XML andJava objects is provided by the Wakesoftclasses that are invoked by the JSPs.

Service Layer and Business RulesThe business logic of your applicationis implemented using the ‘chain ofresponsibility’ pattern1. The BusinessProcess Manager implements the façadepattern and the adapter layer loads up an

Figure 1: Wakesoft Framework and Server Architecture

Figure 2: Front Controller


To convert your business processes intoweb services you add some name/valuepairs to the ejb-business-process.xmlfile, so for example you could publishthe GetStockQuote process above byadding:


Wakesoft have recently raised a $7Mcapital injection, which will enable themto build some new capability into theframework, we suggest that somegraphical visualization tools would helpnavigate the XML configurations thatcurrently have to be hand crafted. Withtheir sights set on the growing emphasison enterprise SOA, the forthcomingreleases will address the runtimemanagement of their customerapplications. Monitoring, businessanalysis and more service features willcreate more value for their users.

Wakesoft’s two big customer successstories are written up on their web site,one in personal finance, the other ininsurance. These customers needed atried and tested architecture to get theirJ2EE developments up and running andturned to Wakesoft.

SummaryThe J2EE platform has been evolvingrapidly over the last five years so evenestablished Java users will be looking attheir first efforts and wishing they had thebenefits of the features now standardin application servers. A really well designed SOA has long-term benefitsand protects investment in software andprocess models allowing applications to

Wakesoft J2EE Framework continued...

logging, drop-down list views for webpages, etc., etc. Clearly the designers atWakesoft have a deep background inreal-world J2EE development and even ifyou don’t buy the framework license,their documentation alone is well worthstudying as a blueprint for best practiceJ2EE patterns.

Market IssuesWakesoft will appeal to project managersand architects who would rather focustheir developers on business code anduser interface. They will get the benefit ofa tried and tested architecture and fewernasty surprises in the code. Developersmay be a more difficult market toconvince since they will not be learningso many J2EE techniques and will haveto spend more time in XML configurationfiles than in your usual J2EE project.We started by raising the ‘frameworkvs. runtime’ issue and for many thedependence on Wakesoft classes andservlets may be a negative factor. On theplus side, of course, is that you save indevelopment time and lifecycle costsand as future releases add value to theruntime environment its contribution willbe more obvious. The runtime costs arenot insignificant so the price tag will bejustifiable, we suggest, for projects ofover 1 developer-year.

Criteria

Loosely coupled

Technology neutral

Course grained/meaningfulto business

Discoverable

Multiple invocation styles

Description

Services exposed as web services are defined through the XML configuredprocess steps and are exposed as business services that need no knowledgeof internal structures

Web Services can be called from any platform

The process façade and the process adapter pattern positively encouragesyou to build a business services bus

Via WSDL/UDDI (developer must set up)

Business process can be driven from asynchronous messages (JMS support)or SOAP etc.

Check

✓

✓

✓

✓

✓

be evolved as the business changes ornew server technology comes along.Against this backdrop, Wakesoft offers atruly elegant architecture ‘out of the box’.We would like to see more graphicaltools to help developers get to grips withthe XML that drives the application andbetter runtime management. Projectmanagers and architects will appreciatethe head start this gives a developmentteam. The financial cost and lifetimedependency on the Wakesoft Companyhas to be balanced against the benefits itbrings, but with their recent venturecapital win, we believe Wakesoft is acompany with a future.

For further information: www.wakesoft.com.

Jonathan [email protected]

1. Design Patterns: Elements of reusable ObjectOriented Software by Erich Gamma, RichardHelm, Ralph Johnson, and John Vlissides. Addison-Wesley 1995

Table 1: SOA Criteria


continues...

By Oliver Sims IntroductionPart 1 of this series showed the synergybetween Web Services and Component-Based Development (CBD), both ofwhich are necessary for EnterpriseService-Oriented Architecture (ESOA).

But an effective architecture for designingand building service-oriented IT systemsdoes not answer the question, whatservices does the business need toprovide – both internally and externally?Again, where an existing business

process plan has already definedrequired business services, then how arebusiness-related structures providingthose services defined? Such structuresare necessary in order to provide a soundbase for longer-term stability andadaptability of the architecture anddesign underlying the deliveredservices. These questions are mostoften addressed by the “requirementsdefinition” or “business modeling” part ofa development process.

The Enterprise Service-Oriented Architecture provides the

essential foundations for flexible applications. The first

report in this series showed how a single architecture

based on mature CBD can address B2B, B2C, Workflow,

Legacy Wrapping, and provide the scalable Enterprise

Services needed. However, to be effective, and to truly

enable business agility, there must be clear traceability

between business requirements and system implementation.

Otherwise the services provided may well not be those the

business requires and needs. This report, the second in

the series, shows how a seamless progression can be

made from a business requirements definition to

implementation, with little information loss. This is business-

oriented system modeling and design (as opposed to

system-oriented business modeling) – a development

process that ensures that the “business model” maps

one-to-one to components in the IT system, so capturing

business requirements much more precisely as well as

providing much better business-to-code traceability.

Services Oriented Architecture -Part 2 - The Bridge

Best Practice Report


much of what is built by IT will not dowhat the business needs IT to do, or willresult in “service silos”. Either way, theresult is loss of agility.

“Firm foundations” mean specifying alland only what the business needs, withminimal or information loss whilecrossing the bridge between businessrules and structures to IT structures andalgorithms. Many current requirementsanalysis methods provide mapping of thebusiness rules to IT algorithms. However,those IT algorithms usually end upburied in code modules that bear littleresemblance to business structures.Real and effective traceability becomesvery difficult; the bridge weakens,sometimes to the point of collapse.

This report presents a “bridge” thatprovides one-to-one mapping fromservices and business structures andrules to IT components and algorithms.This is the firm foundation required foragile businesses. It is particularlyimportant for ESOA, where properidentification of the components thatprovide the services is the key to agile IT. Changes to business processes or rules

can immediately and unambiguouslybe traced to one or more specificcomponents. In addition, new businessstructures and algorithms are analyzedsuch that the structures defined in therequirements activity become the start ofthe IT design model.

We start by suggesting a particularapproach to requirements. Then we showhow the resulting business-orientedmodel can be directly implemented bythe kinds of software componentdiscussed in Part 1 of this series. Finally,with this sound bridge in place, we peera little way into the future, and start to getsome idea of what the control center of atruly agile business might look like.

RequirementsThe objective of the requirements activity1

is to define precisely what services theplanned system should provide, howthey’re carried out, and what businessfeatures it should exhibit. Requirementsis an activity that ends when all relevantbusiness questions have been answered.Therefore it is not some high-levelscoping activity; rather it is a significantpart of the system development effort,and goes into substantial detail – businessdetail; however, it does not include ITsystem design. There are many differentapproaches to this activity, with differentstarting points focuses, and techniques.

The approach we recommend is, in brief,as follows:

1. Define scope, vision, and goals

2. Define the business requirements interms of business processes andresources used or created by thoseprocesses (“resources” are sometimesknown as business objects, or entities).

3. Define the “business elements” thatthe IT system will implement

But what are business elements?

Services Oriented Architecture - Part 2 - The Bridge continued...

Now an important aspect of ESOA isthat the services provided, and thecomponents that implement them,should map as directly as possible to thebusiness. Then, when the businessevolves, it is very quickly clear whatparts of the IT system are affected andwhich new or changed services andcomponents should be provided.However, current methodologies do notprovide this, nor do they help withstructuring already-defined services.Figure 1 illustrates how the structuresof typical business requirementsmethodologies do not map to thestructure of the IT solution. The resultingimpedance mismatch can cause loss ofinformation and traceability.

Without a solution to this problem, it ishard to see how any software initiative,by itself, can hope to make businessmore agile, responsive, or IT becomemore productive so that it can meet time-to-market goals. That is, there needs tobe a clear “bridge” between the businessand the IT system. But without firmfoundations, this bridge will fail to convey properly the things that the businessrequires of IT. Failure here means that

Figure 1: Impedance mismatch in the development process

1. We use the generic term “requirements” as the name of the activity that defines precisely what the business wants and needs of IT. This activity goes by manynames in the industry, including “business modeling”, “requirements”, “requirements analysis”, “scoping and definition”, etc.


case models, or more formally by UMLclasses or action states. Figure 23

shows a scheme where each of severalkinds of step is a UML action state.

The important step for our purposes isthe “immediate” step. This is a step thatis required to complete as soon aspossible, and whose intermediate statesare of no concern to the business in thatthey are not required to be rememberedafter the step has completed. Animmediate step is performedautonomously, with no intervention froma human. It defines a service provided bythe core enterprise system (as discussedin the last report). When an immediatestep is further refined, then subsidiarysteps must also be immediate.

Other kinds of step, briefly, are:

● An Extended Step is one wherethe intermediate states are ofinterest to the business, and mayhave to be remembered. This couldbe because there are businessreasons for such interest, orbecause other factors, includingtechnology, require it. An

Business ElementsThe term “business element” was coinedby David A. Taylor [Taylor]. A businesselement is a process, a resource, or anorganizational unit. These three areinter-dependent: organizations performspecified processes; a process requiresboth an organization to perform it andresources as input or things produced;resources are assets of an organization,and are used or produced by processes.

Informally, we can say that a BusinessElement (BE) is an identifiable “chunk” ofthe business that is seen as importantby business people. A BE can be aprocess-oriented or resource-oriented.Examples are “Sales Order Service”,Invoice Management”, “Customer”,“Booking”, and “Sales Order”.

But how are these BEs identified? Withexperience, the BE’s rather jump out atone, and candidate BEs can often besuggested at the start of requirementsbased on experience in other companiesin the same industry. However, there is aset of heuristics that enable candidatesto be identified based on process andresource models.

Processes and ResourcesFor our purposes, we need an approachthat defines clearly:

● Business “processes”, each ofwhich has one or more “steps”,and where each step is, whereappropriate, further refined as aprocess in its own right. Theprocess provides a service(possibly an internal service), andthe steps define how the serviceis provided.

● Resources (as artifacts)2 or entitiesused by or produced by steps

Steps may be captured in text within use

extended step is a candidate forimplementation by Workflow.

● A Human Step is one that isperformed by a human with noinvolvement by the system beingmodeled.

● A Tool Step is one that is performedby a human user interacting with a“tool” that is part of the system.The human user will use someform of interactive device (e.g. aGUI) to interact with the system.

● A Protocol Step is one thatrequires a peer-to-peer protocolfor its completion. Such a step is acandidate for implementationthough a B2B-style mechanism.

As to resources, these are often currentlycaptured in a “business object model” oran “entity model”. Examples are“Customer”, “Balance”, “Address”, and“Order Line”.

Given the process and resource models,we can define the set of “businesselements” that are within the scope ofthe project.

continues...

2. There may be a number of kinds of resources, such as entities, performers, and actors. Here we are concerned only with those resources that are entities,sometimes called “resources-as-artifacts”.

3. This is a subset of a real conceptual model, developed by the COMBINE project [COMBINE], and simplified for the purposes of this report.

Figure 2: Kinds of process steps


without first saying to what it belongs.

That is, its scope is implied and

understood, and is probably that of the

business or of an important organizational

unit within the business. For example, in

a manufacturing business, a “customer”

probably does not have to be qualified,

so it’s independent. “Address” or

“Balance”, on the other hand, would

have to be qualified to be meaningful, for

example, “customer address” or “supplier

address.” Of course, this is context-

dependent; for example, addresses are

often kept separate from the resources

they relate to, especially in distribution-

oriented organizations.

Looking at the business resource model

in this way, certain resources can be

identified as real and independent, and

are called “focus” resources, while the

others are called “auxiliary” resources.

These terms follow UML semantics

(see [UML]).

IdentificationThe following heuristic can be used to

identify resource business elements

(RBEs):

1. Consider each resource in thebusiness resource model, and askwhether it is “real” and “independent”.If it is, then it is the focus resource fora RBE. Other resources are “auxiliary”resources.

The terms “focus” and “auxiliary” areUML stereotypes, and have the samesemantics here.

2. Follow the relationships (includingupward generalizations) from the focusresource, to and through auxiliaryresources, stopping when anotherfocus resource is reached. Note theauxiliary resources encountered.Those auxiliary resources, plus thefocus resource, form a group calledthe “focus group”.

3. Create a class diagram showing therelationships between auxiliaryresources and the focus resource.

4. When all RBEs have been identified,create an RBE relationships classdiagram. This is essential both forcomprehension of relationshipsbetween RBEs.

ExampleThe RBE example starts from a businessresource model (or business objectmodel). Figure 3 shows a highly simplifiedresource model.


Business Element AnalysisIn this section we show how threedifferent kinds of business element canbe derived from traditional resource andprocess models. The three kinds are:

● Resource Business Element (RBE) –the important resources in thebusiness

● Service Business Element (SBE) –a set of related services providedby the business and implementedby a business process

● Delivery Business Element (DBE) –a defined grouping of service andresource business elements thatprovides a coherent set of servicesrelated to an organizational unit

Resource Business Element (RBE)

OverviewA Resource Business Element (RBE)encapsulates a group of resources.

An RBE is a group of resources focusedaround a particular resource that is“real and independent” in the businessdomain. Other resources are “auxiliary”,inasmuch as they support the primaryresource in some way (for example, aCustomer resource may be supported bya Customer Balance resource).

Real: A real resource is one that is bothused and understood by subject matterexperts (SMEs). It is not abstract. Forexample, in a manufacturing business,“customer,” “address,” and “invoice lineitem” would probably be real, while“legal entity,” “location,” and “collectionmember” might not. That is, an SMEwould assert that while a “customer” is acommon everyday concrete thing, a“legal entity” is not (although theremight be agreement that, hypothetically,it would be a good super-type of“customer”).4

Independent: An independent resourceis one that can be talked about by SMEs

4. For a full discussion of this topic, see under “Trading Partners” in [Herzum], p.463.

Figure 3: Resource Model (fragment)

In this section we show

how three different kinds

of business element

can be derived from

traditional resource and

process models.


Let's assume that Employee, Customer, and Order are identified as the focusresources. Following the identification heuristic to group auxiliary resources gives thefollowing three focus groups:

When these are disentangled, the following picture of three resource businesselements emerges:

The result is a significant simplification of the original resource model, and noinformation is lost. Note that some auxiliary resources appear in more than one RBE.This is not surprising. However, a given focus resource appears in only one RBE.

Figure 4: Focus Groups

Figure 5: Resource Business Elements

continues...



The Service Business Element (SBE)

OverviewA service business element is a collectionof “immediate” steps (discussed above).The reason for grouping the steps(and their sub-steps) is that a givenorganizational unit is often responsiblefor the set of processes (steps)surrounding a Resource BE. These stepsare typically closely related in terms ofthe kinds of things they do, and togetherprovide a coherent service. In effect, weapply the tested modularization principlesof high cohesion and low coupling tothese “chunks” of the business.

Identification heuristicTo identify Service Business Elements(SBEs):

1. Identify the highest-level immediatesteps in the business process model.These are services provided by thecore business systems (discussed inthe last report).

2. The name of each step is probably ofthe form “verb-noun”. If not, convertthe name to this form, or make anote of the name equivalence.

It will be found that many of the nounsare the names of resource BEs, forexample Supplier, Shipment, Contract,Schedule, Invoice, and Product.

3. Group the steps by resources BE. It islikely that each group will include theCRUD5 lifecycle of the resource BE.

Many groups will involve more thanone resource BE. For example, aSales Order group could includesteps that not only direct the lifecycle of a Sales Order in some way,but also update Inventory andCustomer Balance. However, thefocus of the group is often a specificresource (such as Sales Order).

Some groups may involve only oneresource BE. In this case, it is likelythat the step forms part of the

responsibilities of the resource BE(such as “validate new order”).

4. Iterate on the next level of immediatesteps in the business process model.If no further PBEs are found, then theimmediate steps at this level ofiteration are candidates for thebusiness logic within the SBE. If thereare no lower-level immediate stepsfound, then stop.

Each SBE will normally map to anorganizational unit, and is a candidatefor implementation as a processcomponent. The various verbs in thenames of the immediate steps arecandidate operations in the interfaces ofthat component. Subsidiary immediatesteps associated with each higher-levelimmediate step typically constitute theprocess that provides the service indicatedby the higher-level immediate step.

This identification heuristic groupsimmediate steps such that the groups –service business elements – make sensein business terms, and not only providethe basis for a service-oriented enterprisesystem, but also exhibit best practicemodularization along high cohesion lowcoupling principals.

PBE Identification ExampleSuppose the following services (top-levelimmediate steps) were defined in theprocess model:

● Amend Customer Record

● Handle Order (place a new Order)

● Employee Leaves

● Record New Customer

● Amend Existing Order

● Cancel Order

● Hire New Employee

Many of these steps will have subsidiaryimmediate steps. For example, the“Amend Customer Record” and “HandleOrder” steps could well have thefollowing subsidiary steps:

5. CRUD: Create, Read, Update, Delete.

A service business

element is a collection of

“immediate” steps. These

steps are typically closely

related in terms of the

kinds of things they do,

and together provide a

coherent service.


Delivery Business Element (SBE)

Specific subsets of Service andResource BEs are used in deliveringcapability to an organizational unit in thebusiness. For example, an Order ServiceSBE plus several RBEs such asCustomer, Product, and Sales Order areused to deliver order managementcapabilities to a Sale Order Processingdepartment in the business. Suchspecific groups can be seen as providingdefined services to other parts of theorganization, as well as to customers andsuppliers. The grouping itself usefullyforms a third kind of business element,which we call a Delivery BE, since it isthis group that delivers functionality forthe business. Consider: a resource BEcan do nothing by itself (no service orprocess), and likewise, a service BE byitself is pretty useless (no resources!).The Delivery BE is the set of assets thatdelivers value.

A Delivery Business Element (DBE) is agrouping of Service and ResourceBusiness Elements that together delivera business solution to a businessproblem, and which provides servicesto requestors.

A given DBE often corresponds to amajor responsibility of a department orlarger organizational unit in the business.For example, the services and resourcesinvolved in a “Sales Order Management”DBE would reflect the majorresponsibilities of the Sales ProcessingDepartment in a business.

A simplified example of a DBE is shownin Figure 15.

IdentificationDelivery Business Elements can beidentified as by finding the top-levelSBEs. A “top-level” SBE is one that is nota dependant of any other SBE. For eachtop-level SBE, identify the set of BEs thatthis SBE needs to function correctly. That

Service Subsidiary Immediate Steps

Amend Customer Record

Handle Order

● Validate customer details provided

● Review credit limit by running a Credit Check

● Record Customer details

● Check for relationships with other Customers,update where necessary

● Send the standard “your details changed” letter

● Validate data su

cbdijournal - cbdi forumeverware-cbdi.com/public/downloads/-hpg9/journal2003-04.pdf · wakesoft...

Documents