Business Processes
MikeP.PapazoglouandJianYang
Infolab,TilburgUniversity,POBox90153,5000LE,Tilburg,Netherlands
fmikep,[email protected],
Abstract. E-businessisshiftingattentionfromcomponentbasedtoweb
servicebasedapplications.Mostenterprisesspendmostoftheirtime
as-sembling applications by consumingweb servicesratherthanworrying
aboutthedesignprinciplesunderlyingthem,theirgranularityorthe
de-velopmentofcomponentsthatimplementthem.Inthispaperwepresent
adesignmethodologyforwebservicesandbusinessprocesses.Wediscuss
howbusinessprocessshouldbe describedso thatservicescanbe
prop-erlyidentiedandprovidestrategiesandprinciplesregardingfunctional
andnon-functionalaspectsofwebservicedesign.
1 Introduction
Manyenterprisesarespendingasignicantamountoftheirtimeassembling
ap-plicationsthatprovidewebservicefunctionalityratherthanworryingaboutthe
designprinciples underlying the web services,theirgranularityorthe
develop-mentofcomponentsthat implementthem. Onequestionarisesnaturally:what
isthe properwayto designweb servicessothat theycanbeeÆcientlyusedin
businessapplications, canbemanaged, reused,pricedand metered?
Implementing a thin SOAP/WSDL/UDDI [3,2,4] layer on top of existing
applicationsor componentsthatrealizethewebservicesisnotenoughto build
reliable,manageable,andre-usablewebservices.Thereisstillalistofissuesthat
need to be addressedand researched in connectionwith design methodologies
andengineeringprinciples before webservicesbecometheprominentparadigm
fordistributedcomputingandelectronic business.
Wecancertainly borrowseveralideasfromtheareaof componentsoftware
development. Although it provides some technical insights such as reusability
andplug-replaceability,specication,and designprincipleswhichcanbeuseful
to web servicedesign, these twoconcepts are dierentin termsof the level of
abstractionand(functionalandnon-functional)concerns.
Whatis missing is a sound design methodologyand engineeringprinciples
for developing web service based applications. The methodology we propose
herein is based on coreweb service infrastructure,i.e., WSDL and WSFL [1].
It consists of two parts:a framework for business process analysis and service
design principles. The former provides the means for identifying web services
application scenariofrom thebusiness domain of e-travellingand in particular
the specications of the open travel agency [11]. OTA has specied a set of
businessprocessesforobtainingservicesrelatingtothetravelindustry.Wewill
demonstratehowthedesignprinciples areappliedintermsofthisexample.
2 Service Interface and Specication
Whendesigning anapplication, developersdevelopalogicalmodelof what an
enterprisedoesin termsofbusiness objects(such asproduct, customer, order,
bill,etc)andtheservicesthebusinessrequiresfromthesebusinessobjects(what
isthe stock level,what isthedeliveryscheduleand soon).Thedevelopermay
implementthese conceptsasablendofserviceinterfacesand components(the
business objects). Components are normally used to implement (realize) the
servicefunctionality. Frequently, theinterfacesthatthecomponentsrealizeare
too low level and not representative of the actual business services provided.
Thisimpliesthat wearedealingwithtwolargelycomplementaryelements:the
serviceinterfaceanditscorrespondingimplementationcomponent(service
real-ization),illustratedinFigure1.Itisimportanttodistinguishbetweenthesetwo
elementsbecauseinmanycasestheorganisationsthatprovideserviceinterfaces
arenotthesamewiththeorganisationsthat implement theservices.Aservice
isabusiness conceptthatshould bespeciedwithanapplicationortheuserof
theserviceinmind,whiletheservicerealizationmaybeprovidedbyasoftware
package,e.g.,anERP package,aspecial purposebuiltcomponent,commercial
o the shelf applications (COTS), ora legacy application. To a service client
is irrelevant whether the servicesare provided by a ne-grainedsuite of
com-ponents, or a single monolithic ERP. It is important that the developer who
implementsthe servicestill thinks aboutgranularity so theycanchange parts
of the implementation with the minimum of disruption to other components,
applications and services. The granularity of components should be theprime
concernof thedeveloperresponsibleforprovidingcomponentimplementations
forservices,whereasservicedesigners should bemoreinterestedin theprocess
operationsandassemblypotentialoftheprovided services.
Theonlywayoneservicecaninteractwith anotherisviaitsinterface.The
interface simply provides the mechanismby which services communicate with
applicationsandother services.Technically,theserviceinterfaceisthe
descrip-tionofthesignaturesofasetofoperationsthatareavailabletotheserviceclient
forinvocation.Theservicespecicationmustexplicitlydescribealltheinterfaces
thataclientofthisserviceexpectsaswellastheserviceinterfaces(if any)that
must be provided by the environment into which the service is assembled. As
these service interfaces areprovided by other servicesthe service specication
servesasameanstodenehowtheserviceinterfacecanberelatedtothe
inter-faces ofthe imported servicesandhowitcanbeimplementedoutofimported
serviceinterfaces.Inthis sensethe servicespecicationhasamission identical
Service -realization
Web -service
Implementation
(outsourced )
Web -service
specification
Imported
web -service
interfaces
Web -service
usage
interface
Web -service
client
reuse/buy
build/buy
build
Web -service
Implementation
(in -house)
Web -service
Implementation
(outsourced )
Service -realization
Web -service
Implementation
(outsourced )
Web -service
specification
Imported
web -service
interfaces
Web -service
usage
interface
Web -service
client
reuse/buy
build/buy
build
Web -service
Implementation
(in -house)
Web -service
Implementation
(outsourced )
Component
Component
Component
Fig.1.ServiceRealization StrategyandArchitecture
andhowtodeneanewwebserviceinterface(<PortType>)asacollection
(as-sembly)ofexisting ones(imported <PortType>s).Aservicespecication,thus,
denes the encapsulation boundary of a service, and consequently determines
thegranularityofreplaceabilityofwebserviceinterfacecompositions. Justlike
components, servicescan be plug-replaceable, onlyif service specications are
self- contained and symmetrical [6]. As service development requires that we
dealwithmultipleimportedserviceinterfacesitisusefultointroducethisstage
the concept of service usage interface. A service usage interface is simply the
interfacethataclientoftheserviceexpectsto see.
3 Describing Business Process Features
The key focal point of web service design is the business process. A business
processleveragesthe<port type>elementinWSDLtodeneitsbasicprocess
activityinterface.Abusinessprocesscanbemodelledasastatemachinewhere
activitiesaremodelledaswebserviceinvocations,whicharesequencedbystate
transitionevents(controlowactivities).
Determineobjectivesanddescribethebusinessprocessstructure:The
thebusinessprocess.Thefunctions ofabusiness processareexpressedinterms
oftheactivitiesortheservicesthatneedtobeperformedbyaspecicbusiness
process.Forinstance,theregistrationofanewcustomerisanactivityinasales
orderprocess. Thedescriptionofaprocessencompassesthefollowingactions:
1. Identify,groupanddescribetheactivitiesthattogetherimplementabusiness
process:Theobjectiveofthisactionistoidentifytheservicesthatneedtobe
combinedinordertogenerateabusinessprocessandthendescribetheusage
interfaceoftheoverallbusinessprocess.Thestructureofabusinessprocess
describes how an individual process activity (<PortType>) is linked with
another in order to achievea business process. To assemble ahigher-level
servicebycombiningotherwebservices,theservicedesigner needsto:
{ Selecttheservicestocomposebylookingathowtheseservicesandtheir
operationswithinabusinessprocessrelatetooneanother.
{ Connectthe usageinterfaceof thebusiness process tothe interfacesof
importedservicesandplugthemtogether.
2. Describeactivitydependencies,conditionsorsynchronisation:Aprocess
def-initioncanorganiseactivitiesintovarying structures:
{ Hierarchical activity denitions: in a hierarchical denition processes
activitieshaveahierarchicalstructure.Forinstance,theactivityof
send-inganinsurancepolicy foratravelplan canbedividedinto three
sub-activities:computetheinsurancepremium,notifyinsurance,mail
insur-ancepremiumtothecustomer.
{ Conditional activity denitions: in processdenitions that havea
con-ditionalactivitystructureactivitiesareperformedonlyifcertain
condi-tionsaremet.Forinstance, itmaybecompanypolicy tosendasecond
billing notice to a traveller when an invoice is more than two months
overdue.
{ Activitydependencydenitions:processdenitionsareincomplete
with-out further indication of the activity structure. In any process
deni-tion,sub-activitiescanexecuteonlyafter theirparentactivityhas
com-menced.Thismeansthatsub-activitiesareimplicitlydependentontheir
parentactivity.Inothercasestheremightbeanexplicitdependency
be-tween activities: an activity may only be able to start when another
specic activity hascompleted. Forinstance, an itinerary conrmation
cannotbesentto atravellerunlessallightshavebeenreservedbyan
airline.
3. Describethe implementation of the businessprocess:Writethe application,
e.g.,provideaWSFLdenition,that mapstheoperationsandinterfacesof
importedservicesto thoseof anotherin orderto createtheusageinterface
ofthebusiness process(higher-levelwebservice).
Describe business activity responsibilities (roles): The second step in
the service design methodology is to identify responsibilities associated with
business process activities and the service providers that are responsible for
isexpectedtoproperlyfullthebusinessresponsibilityofimplementingtheweb
service, orset of web services, which performthat activitywithin the process
under therolethat theprovideris expectedto undertake.Toexplicatethis we
usetheOTAtravelreservationsexampleandassumethatthisbusiness process
is expressed in WSFL. For each activity, we would identify service provider
responsible for theexecution of the process step(for example, servicesoered
byatravelagentorbyanairlinecompany)and denetheassociationbetween
activitiesin theowmodeland operationsoeredbytheservice. Inthetravel
reservations example, we may dene the business process for handling travel
reservations as a WSFL ow model. However, we do not bind the activities
to particular serviceproviders.Instead weidentify thegeneric serviceprovider
(role)that is requiredforeachactivity(forexample, sometravelagentforthe
activityprocessbookthetrip,andsomeairlineservicefortheactivityorderand
issuethetickets).Wewouldthen denetheWSDLwebserviceinterfaceofthe
owmodel,thatis,theWSFL<serviceProviderType>oftheowmodel.This
interfacehastwofacets:onefacetdenestheinterfacethataserviceclientwould
usewhenrequestingtheprocessingofatravelreservation,thatis,theoperations
thatthewebserviceprovidesforusebyservicerequesters.Forexample,service
would provide an operation that takes a trip order asinput and passes it on
(throughaWSFLowsource)totheactivitiesintheowmodelforprocessing.
Theotherfacetidentiestheoperationsthattheservicerequiresfromtheother
serviceproviders.
4 Service Design Principles
Theservicedesignprinciplesthatunderlyingtheservicedesignstagesdescribed
aboverevolvearoundtwowell-known software designguidelines: coupling and
cohesion.Theseguaranteethatservicesareself-contained,modularandableto
supportservicecomposability.
4.1 Service coupling
It is importantthat the groupingof activitiesin business processes isas
inde-pendentas possible from other such groupingsin other processes. One way of
measuring service design quality is coupling, orthe degree of interdependence
betweentwobusiness processes.Theobjectiveisto minimise coupling,that is,
to make (self-contained) business processesas independent as possible by not
havinganyknowledgeof orrelying onany other business processes.Low
cou-plingbetweenbusinessprocessesindicatesawell-partitionedsystemthatavoids
theproblemsofserviceredundancyandduplication.
Couplingcanbeachievedbyreducingthenumberofconnectionsbetween
ser-vicesinabusinessprocess,eliminatingunnecessaryrelationshipsbetweenthem,
and byreducingthenumberof necessaryrelationships,if possible.Coupling is
cicrepresentational or computational details of oneanother. Thecentral
tacticstemsfromtheideaofabstractclassesinobject-orienteddesignwhere
compositeclassesandactionsminimisesdependenciesonirrelevant
represen-tationalandcomputationaldetails [7].Theseconcernsleadtothe
exploita-tionofinteroperabilityandreusabilityforservicedesign.Thissolvesseveral
serviceoptionsrelatedtodesign,including:
(a) Interchangeable/replaceable services: existing services may be swapped
bynewserviceimplementations{oronessuppliedbyadierentprovider
oeringbetter performance orpricing { withoutdisruptingthe overall
businessprocessfunctionality.
(b) Multiple service versions: dierentversionsof aservicemaywork best
in parts of a business processes depending on the application's needs.
For example, a stock exchange service may provide dierent levels of
detail, e.g., nancial details, charts, market projections, depending on
thechargingoptions.
2. Identitycoupling:Connection channelsbetweenservicesshouldbeunaware
ofwhoisprovidingtheservice.Itisnotdesirabletokeeptrackofthetargets
(recipients)ofservicemessages,especiallywhentheyarelikelytochangeor
whendiscoveringthebestserviceproviderisnotatrivialmatter.
3. Communicationprotocolcoupling:Asenderofamessageshouldrelyonlyon
thoseeectsnecessarytoachieveeectivecommunication.Forexample,
one-waystylesofoperationwhereaserviceendpointreceivesamessagewithout
havingto sendanacknowledgementplacesthelowest possibledemands on
theserviceperformingtheoperation.Theservicethatperformstheoperation
doesnotassumeanything aboutwhen theeects oftheoperation hold, or
evenrequirethatanoticationbesentbackindicatingcompletion.
Lowcoupling increasesthe degreeofisolation of onebusiness processfrom
changes thathappentoanother; simpliesdesignunderstanding;andincreases
thereusepotentialofwebservices.
4.2 Service cohesion
Cohesion is the degree of the strength of functional relatednessof operations
within aservice. Designers should create strong, highly cohesivebusiness
pro-cesses,businessprocesseswhoseservicesandserviceoperationsarestronglyand
genuinely relatedto oneanother.Theguidelines bywhichto increasecohesion
areas follows:
1. Functional service cohesion: A functionally cohesive business process
con-tains services that all contribute to the execution of one and only one
problem-related task. At the same time the operations in the services of
thebusiness processmustalsobehighlyrelatedtoone another.
2. Communicational service cohesion: A communicationally cohesivebusiness
relatedto elementsinotherbusiness processes.
3. Logical servicecohesion:A logicallycohesivebusiness processis onewhose
activitiesall contributeto tasksof the samegeneral category. These tasks
areselectedandinvokedoutsidethebusinessprocess.
Highcohesionincreasestheclarityandeaseofcomprehensionofthedesign;
simplies maintenance and future enhancements; achieves service granularity
at a fairly reasonable level; and often supports low coupling. The ne grain
of highly related functionality supports increased reuse potential as a highly
cohesiveservicemodule canbeusedforveryspecicpurposes.
5 Non Functional Service Design Guidelines
Non-functionalservicecharacteristicsdescribethebroadercontextofaservice,
e.g., what business function the web service accomplishes, how it ts into a
broader business process context aswell ascharacteristicsof thehosting
envi-ronmentsuchaswhethertheserviceproviderensuressecurityandprivacy,what
kindofauditing,securityandprivacypolicyisenforcedbytheserviceprovider,
whatlevelsofqualityofserviceareavailableandsoon,e.g,non-functional
char-acteristicsofwebservicessuchasthosedescribedbytheWebServiceEndpoint
Language(WSEL).
5.1 Service provisioningstrategies
Serviceprovisioningiscentralto operatingrevenuegeneratingwebservices
be-tweenorganisations. It is acomplexmixture of technical and business aspects
forsupportingserviceclientactivitiesandinvolveschoicesforservicerealization,
serviceenrolment,auditing,metering,billingandmanagingoperationsthat
con-trolthebehaviourofaserviceduringuse.Theprovisioningrequirementsforweb
servicesimposeseriousimplicationsforthedesignmethodologyofservices.
5.1.1Servicerealizationstrategies Theseparationofspecicationfrom
im-plementation allows web services to be realized in dierent ways. It becomes
importantthentoplaneectivelywhendecidinghowtorealizeorprovision
ser-vices,considerthediversityofrealizationalternativesandmaketherightchoice.
Thereareimportantfactorsthatneedtobeconsideredduring thisprocessand
thesearesimilarto thefactorsconsideredwhenrealizingcomponents[8]:
{ Gapanalysis.This techniquedecidestheservicerealizationstrategyby
in-crementallyaddingmoreimplementationdetailstoanabstractserviceusage
interface.Duringthisprocessaservicerealizationarchitecturecanbeusedto
alizationarchitecture,withavailablesoftwareserviceimplementations.Figure1
showshowimportedserviceinterfaces,whicharepartofabusiness processare
realizedin termsofalreadyexisting interfacesandimplementations.Theticker
arrowsinthisguredenotethedierentprovisioningpossibilities,suchreusing,
buildingorbuyingserviceinterfacesandtheirunderlyingimplementations.This
gure also illustrates that service interfaces may be provided by one service
providerwhileanother provider,e.g.,an ASPcompany,mayoertheir
under-lying implementation. Agap analysis strategymaybe developedin stages and
results in a recommendation to do development work, reuse or purchase web
services.
Theservicerealizationstrategyinvolveschoosingfromanincreasingdiversity
ofdierentoptionsforservices,inadditiontoservicereuse,whichmaybemixed
in variouscombinationsincluding:
1. Purchasing/leasing/paying per use for services. This option is covered in
somedetailinthesectiononservicemeteringandbilling.
2. Outsourcingservicedesignandimplementation.Onceaserviceisspecied,
thedesignofits interfacesorsets ofinterfacesand thecodingof itsactual
implementationmaybeoutsourced.
3. Usingwrappers and/oradapters. Non-component implementations for
ser-vices may include database functionalityor legacysoftwarein theform of
adaptersorwrappers.
5.1.2Servicebilling strategies Fromtheperspectiveoftheserviceprovider
acomplex tradingweb- serviceis acommercialisablesoftware commodity. For
example,aserviceprovidermaydecideto oersimpleservices(withnoquality
of service guarantee) for free, while it would charge a nominal fee for use of
itscomplex(addedvalue)webservices.With complextradingwebservicesthe
qualityofserviceplaysahighroleofimportanceandtheserviceisoeredfora
price.Thesetypesofservicesareverydierentfromthesellingofshrink-wrapped
softwarecomponents,in that paymentshould be onanexecution basisforthe
deliveryoftheservice,ratherthanonaone-opaymentforanimplementation
ofthesoftware.Forcomplextradingwebservices,theserviceprovidermayhave
dierentchargingalternatives.Thesemayinclude:
1. Paymentonaper usebasis.With this alternativeaclientis charged some
nominalfeeeachtimetheyinvoketheservice.
2. Paymentonasubscriptionbasis.With thisalternativeaclientischargeda
setamountofmoneyforagivenperiodoftime.
3. Paymentonaleasingbasis.Thisalternativeissimilartosubscription;
how-ever, it is geared towards web services that may provide high value for a
shorterperiodoftime.
4. Lifetimeservices. Theseservices areoered for aset amount ofmoney for
theirentirelifetime.
distributetheirfunctionalitywithasimpleSLAagreementthatallowsfora
futurechargingmechanismtocome intoplay.
6. Free with hidden value.This term refersto services that mayactually get
advantage from clients using them. For example, a client may use a web
serviceforfreebutmayhavetopayasubscriptionfeewhenitwishestosee
moreservicesrelatedto thefreeservice.
A service design methodology should take into account several important
aspectsrelatingtotheaccountingprocessforserviceprovisioning,suchasservice
metering,ratingandbilling.
Service meteringmodel:Useofaservicebyaclientmustbemeteredifthe
serviceproviderrequiresusage-basedbilling.Thentheserviceproviderneedsto
audit theserviceasitisused andbillfor it.This couldtypicallybedoneona
periodicbasisandrequiresthatameteringandaccountingmodelfortheuseof
theservicebeestablished.Themodelcouldallowtheestablishmentofaservice
contractforeachnewsubscriberandtackingandbillingforusingthesubscribed
hostedservices.Toachievethis,theservice-meteringmodelcouldoperateonthe
assumptionthatwebserviceswithahighdegreeofvaluearecontractedvia,for
example, SLAs. The metering model cancover dierent payment possibilities
suchasfee-for-usemodel,thesubscriptionmodel, andtheleasemodel.
Service rating/billing model: Software organisations that are used to the
traditional up-frontlicense/ongoingmaintenance pricingstructure forsoftware
should come up with annuity-based pricing models for the web services they
provide.Thepricing (rating)model coulddetermine subscriberratesbasedon
subscription and usage events. For example,the pricing model could calculate
charges for services based on the quality and precision of the service and on
individual meteringeventsbasedon aservice-ratingscheme. Thebillingmodel
associates rating details with the correct client account. It provides adequate
information to allow the retrievaland payment of billing details by the client
andthecorrectdisbursementofpaymentstotheserviceprovider'ssuppliers(who
areinturnserviceprovidersoeringwholesaleservicestotheoriginalprovider).
5.2 Service policy managementmodels
Asawide rangeof servicesisprovided acrossanetworkitis onlynaturalthat
services would introducepolicy management models that determine
dierenti-atedservicesaccordingtobusiness rulesorapplication-levelpolicies. Thereare
manyreasonswhybusinessesmightwanttogivedierentlevelsofserviceto
dif-ferentcustomersorwhytheymightneeddierentlevelsofpriorityto dierent
business transaction models involvingweb services.Therefore, itis nosurprise
that such criteriaare considered to be equally important to technical policies
suchassecurityorauthentication.
Considerfor example astock quote service where dierent clients may be
providingmoretimelystockquotepricesandothernancialdata,e.g.,nancial
charting,stockgrowthtrends,andsoon.Moreover,there mightbeclientswho
wouldneedsomecharacteristicsofdataqualitybutnoothers.Forinstance,some
investorsmaybeinterested in streaming market quotes and data while others
maynot.Therefore,serviceproviderscanmixdierentlevelsofserviceprecision,
granularity,timelinessandscope.Anotherpossibilityistodierentiateservices
basedontechnicalqualitydetailssuchasresponsetime,performancebandwidth
used, and reliability. Ifaservice isdesignedto coverafairlywide spectrumof
servicelevelsaccordingto somesetof policies thenit islikelythat thisservice
wouldachievemuch higherlevelsofuse[10].
5.3 Service programmingstyle
Services havetwo programmingstyles: RPC or document-based. Determining
theserviceprogrammingstyleis largelyadesignissue asdierentapplications
impose dierentprogramming-stylerequirementsforwebservices.Considerfor
exampleanapplicationthat dealswithpurchaseorderrequests,purchaseorder
conrmations and delivery information. This application requires that request
messages may contain purchase orders in the form of XML documents while
response messagesmaycontainpurchase orderreceipts ordeliveryinformation
againintheformofXMLdocuments.Thistypeofapplicationusesdata-oriented
web-services.Moreover,thereisnorealurgencyforaresponsemessagetofollow
arequestimmediatelyifatall.Incontrastto this,consideranapplication that
providesbusinesseswithup-to-the-instantcreditstandings.Beforecompleting
abusiness transaction, abusiness mayrequireto check apotential customer's
creditstanding.Inthisscenario,arequestwouldbesenttothecreditcheckweb
serviceprovider,e.g.,abank,processed,andaresponseindicatingthepotential
customer'screditratingwouldbereturnedinrealtime.Thistypeofwebservice
relies on an RPC programming style. In this type of applications the client
invokingtheweb-serviceneedsanimmediateresponseormayevenrequirethat
thewebservicesinteractinaback-and-forthconversationalway.
5.4 Authorisation design considerations
Since web servicesshould allowaccess to sanctioned clients, securityis a rst
order business consideration. Normally, an integrated approach to security is
required whereby all technical system aspects as well asbusiness policies and
processesaretakenintoconsideration.
Increasingly authorisationcapabilities areemerging asamajor security
re-quirement for e-business. An enterprise not only needs to know who the
re-questersaccessingtheirservicesare;italsoneedstocontrolthewhatwebservices
thatrequesterhasaccessto,what factorsaectavailabilityoftheweb-services
to that customer, andwhat auditing isrequired to ensurethenon-repudiation
risedrequestersandapplications inmuchthesamewaythatWeb sitesrestrict
access to authorised clients and applications. Authorisation can usually take
placeforeachoperationwithinthewebservice.Alternatively,theremaybe
oc-casionswhenauthorisationforawebservice(orbusinessprocess)asawholeis
moreappropriate,forinstance whereahighgranularityofsecurityisnot
criti-cal [9].There are dierentauthenticationmodels forclientauthentication.For
instance, anauthenticationmodelmayrequirethat aclientauthenticates itself
by presentingits encoded credentialsor may requirethat XML signatures be
generatedforwebservicerequests.
Onceawebservicedesignmethodologyhasbeenapplied,webservice
speci-cationinWSDLcanensueonthebasisofthefollowingsteps:(1)specifyingthe
serviceinterface;(2)makingoperationparameters;(3)messagingandtransport;
(4)implementing.Anexampleofthiscanbefoundin[5].
6 Conclusion
Inthis paperwearguethat withoutdesignmethodologiesandsound
engineer-ingprinciples webservicescannotbeproperlydevelopedto achievewhatthey
promised: reusability and plug-replaceability, exibility and extensibility. We
thenproposeamethodologywhichprovidesaframeworkforidentifyingweb
ser-vices frombusiness processesandprinciples in webservicedesignwhichcovers
bothfunctionalperspectivessuchascouplingandcohesion,and non-functional
perspectivessuch asprovision,billing, pricingand metering.The design
strat-egy is in line with the web servicestandardsWSDL and WSFL,and software
engineeringprinciples.
References
1. "Web Service Flow Language (WSFL 1.0)",
http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf.
2. "WebServiceDenitionLanguage",http://www.w3.org/TR/wsdl.
3. "SimpleObjectAccessProtocol(SOAP)1.1",http://www.w3.org/TR/SOAP.
4. UDDI Project, "UDDI Technical White Paper", September, 2000,
http://www.udddi.org.
5. Bilal Siddiqui, "Deploying Web services with WSDL",
http://www-106.ibm.com/developerworks/library/ws-intwsdl/.
6. D.F. d'Souza, A.C. Wills, "Objects, componentsand frameworks with UML",
Addison-Wesley,LongmanInc.,1999.
7. D.deChampeaux,D.Lea,andP.Faure, "Object-orientedsystemdevelopment",
Addison-Wesleypublishingco.,1993.
8. P.Allen,"Realizinge-BusinesswithComponents", Addison-Wesley,2001.
9. P.Cauldwell, et.al., "XMLWebServices", WroxPressLtd.,2001.
10. CBDiForum "Design Pattern:Dierentiated Service", www.cdbiforum.com, pp
3-8,December2000.
11. OpenTravelAlliance,OTA, "2001CSpecications", http://www.opentravel.org,
