Oracle SOA Suite 11g: Essential Concepts 1 - 1
SOAismorethanusingWSDLs,andismorethanjustanapplicationwithawebserviceinterface.SOAisastrategy—oranapproach—thatisbusinessfocused.Tobesuccessful,SOAmustprovidetruebusinessvalue.Withoutthatvalue,servicestendtobelow-levelutilityservices(suchasloggingandnotification)thatprovidenorealreturnoninvestment.TraditionalSOAprinciplessuchasloosecoupling,interoperability,composability,andreusearekeytraitsofSOA,butonlybecausetheycontributetothebusinessvalueofanSOA.Withinthescopeofthearchitecturalstrategy,SOAdescribesanapproachforenterprisesystemsdevelopmentandintegrationthatisbothtechnologyagnostic(thatis,itoperatesacrossheterogeneoussystems)andalignedwithbusinessimperatives.Itprovidesloosecouplingofcoarse-grainedcomponents(services)forrapidandeffectivereuseofenterpriseITassets.TheultimategoalofSOAistofacilitatethecreationofnewbusinesssolutionsthroughthecompositionofservices—withouttheneedforcomplexprogrammaticcodedevelopmentthatmightotherwiseduplicateexistingcapabilities.Thisleadstoamoreagileandefficiententerprisethatcanrespondmorerapidlytochangingmarketandregulatorydemands.
SOA Adoption and Architecture Fundamentals 1 - 2
Becauseeveryenterpriseisdifferent,thereisnosinglemodelofgoodSOAgovernance.Oraclehasagovernanceframeworkthathastwoaspects:
•Theactualbaselinemodel•Acontinuousfeedbackloop
Itisimportanttounderstandthatgovernanceisnotaone-offproject.Itissomethingthatyoustart,anditcontinuesforever.TheSOAGovernanceContinuousImprovementMethodisadefinition-improvementfeedbackprocesstodefineafocusedandcustomizedSOAGovernancemodel.
SOA Adoption and Architecture Fundamentals 1 - 3
GoodcommunicationandaccesstoinformationareoftenamongthemissingpiecesofanSOAinitiative.WhenyouexecuteSOA,itisimportanttohavea360-degreeviewofthewholesoftwaredevelopmentlifecycle(SDLC)oftheprogram-levelactivities.Ratherthanjustbuildingonebigapplication,anSOAinitiativeinvolvesbuildingmultipleapplicationsandpotentiallyhundredsofservices.Eachserviceismadeupofacontract,aninterface,andapayload.Asworkishandedfromonedepartmenttoanotherandfromonepersontoanother,amissingpartcanbecomeakeyissue.Theexecutionphasecoversthedifferentlifecyclesofdeliveringsolutionsandservicesandtheassociatedserviceinfrastructure.AnenterpriserepositoryprovidesasinglesourceoftruthfortheSOAportfolioandmanagesSOAassets,projects,andassociatedmetadata.Witharepository,youcanmakerapidinformeddecisionsaboutdependencytracking,impactanalysis,usagetracking,andcompliance.Withinthelifecycle,analystscapturerequirementsandperformprocess,functional,anddatamodeling.Architectsthenidentifyanddiscoverytheappropriateservicesanddefinetheassociatedservicecontracts.Serviceengineerscandesign,test,anddelivertheservices.ITOperationsthenprovidesfacilitiestoprovision,monitor,andmanageservices.Thelifecycleisthencomplete.BusinessandITuserscanutilizetoolstovisualizehistoricalandtrendanalysis.Thatinformationgetsfedintoplanning
SOA Adoption and Architecture Fundamentals 1 - 4
forversion2.0ofaservice.Version2.0ofanapplicationifusuallyreleasedafter12–18months.Butaservicemightbeversionedquitefrequently.
4
CreatingaSOAservicefromexistingassetsgenerallyrequiresmuchmorethanjustaddingastandards-basedinterface.Simplyservice-enablingexistingassetsisinsufficient.TheSOAserviceneedstoexposeprocesses,functionality,anddatathatareusableinabroadercontextthanthesourceofthecapabilitywasdesignedtomeet.Therefore,creatingaSOAserviceusuallyentailssomeamountofaggregation,transformation,orexpansionofexistingcapabilitiesprovidedbythesourcesystems.ThisrequiresaSOAserviceslayerbetweentheexistingassetsandtheconsumers(asillustratedintheslide).Theessenceofservice-orientedintegrationisthebuildingofacatalogofSOAservicesthatexpose―inabusiness-enablingway―thedata,functionality,andprocessescontainedinexistingsystems.Toachievethebenefitsofservice-orientedintegration,theSOAservicesmustdecoupletheconsumersfromthesourcesystemswithoutcreatingtightcouplingbetweentheconsumerandtheSOAserviceitself.Additionally,theSOAservicesmustexposefunctionalitythatisalignedwiththebusinessneedsoftheserviceconsumers,ratherthanmerelyprovidinganAPIordata-levelpassthroughtothesourcesystems.
SOA Adoption and Architecture Fundamentals 8 - 5
Theexistingsourcesystemsfrequentlyincludeabusinessprocessorworkflowbuiltintothesystem.Fromtheperspectiveofthesourcesystem,thisisacompletebusinessprocess.However,fromthebroadercontextoftheorganization,thebuilt-inbusinessprocessisactuallyonlyaportionofalargerbusinessprocessthatspansmultipleback-endsystems.Therefore,whenyoucreatethecatalogofSOAservices,thesebuilt-inbusinessprocessesshouldbeviewedassubprocessesthatarepartofthelargerenterprisebusinessprocess.Thisrelationshipisillustratedintheslide.
SOA Adoption and Architecture Fundamentals 8 - 6
Thefunctionalcapabilitiescontainedinexistingsourcesystemsareusuallytoofinegrainedanddomainspecifictobeuseful,asis,forcreatingcompositeapplications.Theapplicationhostingthefunctionalitywasusuallyconstructedtoprovideusersfine-grainedcontrol.Additionally,theapplicationinvariablycontainsfarmorefunctionalitythanisnecessaryinabroadercontext.Mostofthefunctionalityisspecifictothedomain(forexample,HR,Finance,Shipping)andhaslittlerelevanceinan"enterprise"context.Therefore,exposingexistingfunctionalityasSOAservicesusuallyrequiresabstractingthefunctionalitytoahigherlevelsothatithasmeaning(andismoreuseful)inabroadercontext.Frequentlythismeanscombiningseveralfine-grainedoperationsintoamorecoarse-grainedoperation.Sometimesthefine-grainedoperationsareassociatedwithabuilt-inworkflowexposedthroughtheuserinterface(asetofprescribedoperationsthattheenduserperformsinsequence).Inthisinstance,whenyoucreateaSOAservice,itisusuallydesirabletohaveasingleoperationontheSOAservicethatencapsulatesandhidesthebuilt-inworkflowbyperformingtheindividualstepsautomatically.Theorchestrationmayevenspantwoormoreexistingapplications.Thisorchestrationoffine-grainedoperationstocreateacoarser-grainedoperationisacommontechniquetoabstractfunctionality.Thistype
SOA Adoption and Architecture Fundamentals 8 - 7
oforchestrationisillustratedintheslide.
7
Eachexistingapplicationcontainsitsowndatamodelanddataformats.Thisproliferationofdatamodelsanddataformatsismadeworsebythefactthatasingleenterpriseentity(forexample,acustomer,product,ororder)frequentlyhasdataelementsstoredinmultipleexistingapplications.TobesuccessfulatexposingexistingdataviaSOAservices,theintegrationapproachmustmanagethiscomplexity.Providingconsumerrepresentationsandreadingfromandwritingtomultiplesourcesystemsleadtotheissueofdataformattransformations.Foraverysmallnumberofsourcesystems,point-to-pointtransformationscanbeusedbytheSOAservices.However,thisapproachbecomesunworkableasthenumberofsourcesystemsincreases.Abetterapproachistocreateanormalizedformatforthedataentitiesandthenprovidetransformationstoandfromthenormalizedformatforeachsourcesystem.Asinglecanonicaldatamodelfortheentireenterpriseisnotrequiredtosuccessfullyemploynormalizeddataformats.Rather,afederatedapproachtonormalizationcanbeused.Forexample,inalargeenterprise,eachfunctionaldomaincouldcreateanormalizedformat.TransformationsbetweenthedomainformatswouldthenbecreatedforSOAservicesthat
SOA Adoption and Architecture Fundamentals 8 - 8
spandomains.Thisapproachisillustratedintheslide.
8
TheprimarygoalofaSOAservicethatexposesanenterprisedataentityistomakeiteasiertoworkwiththeentityandhidethecomplexityofhowthatentityisstoredinexistingsourcesystems.Toachievethisgoal,theSOAserviceneedstoincorporatethefollowingcapabilities:
Consumerrepresentation:TheSOAserviceshouldpresentaninterfacetotheentitythatisappropriatefortheconsumerofthedata.AsingleSOAservicemightprovidemultiplerepresentationsofasingeentity,witheachrepresentationappropriateforadifferenttypeofconsumer.Aggregation: TheSOAservicemayneedtopulldataelementsfrommultiplesourcesystemstoconstructarepresentationforaparticularconsumer.Synchronization: Anupdatetoanentitymayrequireupdatingdataelementsinmorethanonesourcesystem.TheSOAserviceneedstoensurethatallupdatesaredoneproperlysothattheentitymaintainsconsistency.
SOA Adoption and Architecture Fundamentals 8 - 9
ServiceContractSOAservicesincludeacontractthatspecifiesthefunctionalandnonfunctionalcapabilitiesprovided.Tosupportbusiness-levelcomposition,theSOAservicemusthaveacontractthatisunderstandabletoabusinessperson.Aserviceengineeringprocessthatenforcescreationoftheservicecontractmustbeestablished.ThearchitecturemustsupportdiscoveryofexistingSOAservicesbasedontheservicecontracts.SomeofthecapabilitiesprovidedbytheSOAserviceanddocumentedintheservicecontractmaybefulfilledbyconfigurationofinfrastructure.OpaqueServiceImplementationsTheimplementationofaSOAserviceisopaquetoallserviceconsumers.ServiceconsumersmustbeabletosuccessfullycallaSOAservicewithoutneedingtounderstandtheinternalworkingsofSOAservices.Theserviceinterfacemustbeconstructedsothatimplementationdetailsdonotpropagatethroughtheinterface.Thearchitecturemustsupportopaqueserviceimplementations.
SOA Adoption and Architecture Fundamentals 8 - 10
PlatformIndependenceTheserviceconsumerplatformisindependentoftheserviceproviderplatform.SOAservicesneedtosupportanykindofserviceconsumerregardlessoftheparticularplatformonwhichtheconsumerisbuilt.SOAservicesmustbeconstructedsothatplatformdependenciesarenotintroduced.Thearchitecturemustsupportserviceconsumershostedonplatformsthataredifferentfromtheserviceproviders.LocationTransparencyThelocationofaserviceproviderisunimportanttotheserviceconsumer(andviceversa).LocationtransparencyhelpsprovidethedecouplingofserviceconsumersandprovidersthatisnecessaryforextensiveSOAservicereuse.Serviceprovidersshouldmakenoassumptionaboutthelocationoftheserviceconsumer.Thearchitecturemustsupporttheabilityforaserviceconsumertocallaserviceprovider,regardlessofthelocationofeither.ConcurrentServiceVersionsTheremaybemultipleversionsofaSOAserviceconcurrentlyinproduction.ASOAservicewillalmostalwaysrequiremodificationstosupportnewconsumersortoexpandfunctionality.SupportingconcurrentversionsofaSOAserviceisessentialforasoundservice-versioningapproach.Aservice-versioningstrategyneedstobeestablished.ThearchitecturemustsupportmultipleconcurrentversionsofaSOAservice.GracefulServiceMigrationServiceconsumersshouldbeabletomigratetoanewerversionofaSOAservicegracefully.ServiceconsumersshouldmigratetoanewversionofaSOAserviceaspartofanormalmaintenanceprocess.Thecoordinateddeploymentofserviceconsumersandserviceprovidersshouldnotbenecessary.Aservicemigrationstrategyneedstobeestablished.Thearchitecturemustsupportgracefulservicemigration.SummaryTheprecedingprinciplesprovidesoundguidanceforcreatingaservice-orientedarchitectureforintegration.Eachorganizationembracingservice-orientedintegrationshouldevaluatetheprincipleslistedintheslideandderivetheirownsetofprinciplestomatchthespecificenvironmentandgoalsoftheirorganization.
SOA Adoption and Architecture Fundamentals 8 - 11
Thedatamovementlayerprovidesbatchandbulkdatahandlingforthearchitecture.Thislayerexistsprimarilytooffloadbulkdatamovementfromtheupperlayersinthearchitecture.Bulkdatamovementisinevitableinmanyenterprises;therefore,thearchitecturemustprovideamechanismtoprovidethiscapabilityinanefficient,controlledmanner.Withoutthislayer,theotherlayersinthearchitecturemightbemisusedtomovelargeblocksofdata―ataskforwhichtheotherlayersarenotwellsuited.Thekeycapabilitiesencapsulatedbythislayerinclude:
Extract,transform,load: TheETL/ELTcapabilityprovidesbulkdatamovementfromonepersistentstoretoanother.Datacleansing: Datacleansingensuresthequalityofthedatathatisbeingmovedinbulk.Datacleansingcanalsobeappliedtoensurequalityandconsistencyonindividualdataupdates.Primary-keycross-reference: Eachpersistentdatastoreislikelytohaveitsownuniqueprimarykeyscheme.Thislayerprovidesthecross-referencebetweentheseprimarykeyschemessothatanidentitycanbemaintainedacrossdisparatedatastores.
SOA Adoption and Architecture Fundamentals 8 - 12
Thedatamovementlayerisshownbelowtheenterpriseinformationsystemsbecausebulkdatamovementisdone"behindthescenes"andthisprocessingisprimarilyinvisibletotheupperlayersofthearchitecture.However,theresultsachievedbythedatamovementlayerareclearlyvaluabletotheupperlayers,andboththequalitydataandtheprimary-keycross-referenceareleveragedbytheupperlayersinthearchitecturewhereverappropriate.InsomeITdepartments,bulkdatamovementisusedtocreateonlineaggregatedataviewsbypullingdatafrommultiplesystemstogetherintoasingledatastore.Althoughthisarchitecturedoesnotprohibitsuchanapproach,thepreferredapproachistocreateenterprisedataentitiesinthedatanormalizationlayerthataggregatedataacrosssourcesystemswithouttheneedtopersistentlystorecopiesofdata.Anenterpriseinformationsystem(EIS)isanysystemthatprovidesdataorfunctionalitythatisexposedbytheintegrationarchitecture.ExamplesofEISsincludepackagedapplications,legacysystems,databases,partnersystems,andsoon.AnEISmayalsobeaserviceconsumer.AsSOAbecomesmoreprevalent,itwillbecomemorecommonforEISstoparticipatenativelyinservice-orientedintegration.Thisisnotformallyalayerintheintegrationarchitecture.Rather,theentirepurposeofthearchitectureistoexposethedataandfunctionalitythatiscontainedinthevariousenterpriseinformationsystemstoprovidebusinessvaluebeyondwhatisalreadyprovidedbythesystemsthemselves.
SOA Adoption and Architecture Fundamentals 8 - 13
Theconnectivitylayerprovidesaccesstotheenterpriseinformationsystems.ThereareavarietyoftechnologiesandproductsthatcanbeleveragedtoconnecttoexistingEISs.Generally,bothsynchronousandasynchronoustechniquesareemployedbythislayertoprovideconnectivity.Bothproprietaryandstandards-basedtechnologiesandproductsareused.Thekeycapabilitiesprovidedbythislayerinclude:
Messaging:MessagingprovidesasynchronousconnectivitytoEISs.Manytraditionalintegrationproducts(forexample,MQSeriesandTIBCO)arebasedonmessagingsystems.EnterpriseshavesuccessfullyusedtheseproductstoconnecttoEISs,andthisexistingconnectivitycanbeleveragedbythisarchitecture.Adapters:Adapters(forexample,JCA)provideastandardizedapproachforconnectingtoEISs.StandardAPIs:TheEISmayprovideaccessviaoneormorestandardapplicationprogramminginterface(forexample,JDBC,RMI,andWS*).Theconnectivitylayerincludesthesestandardinterfacesnatively,therebyallowingeasyaccesstoanyEISthatexposesastandardAPI.
SOA Adoption and Architecture Fundamentals 8 - 14
CustomAPIs: SomeEISs(especiallylegacy)provideaccessonlyviaacustomapplicationprogramminginterface.TheconnectivitylayerprovidesthecapabilitytocallthesecustomAPIsandwrapthemwithastandardizedinterface.Events: EventsallowtheEISstoinitiateactions.TheconnectivitylayerprovidesthemechanismsothatanEIScanraiseaneventthatishandledbythemediationlayer(justlikeanyothermessage).Theprimarypurposeofthislayerinthearchitectureistoencapsulateandhidethecomplexityofconnectingtoback-endsystems.ThisallowstheupperlayersinthearchitecturetotreattheEISsinamoreuniformandgenericfashion,thusprovidinggreaterreusabilityandportabilityacrossback-endsystems.
Thedatanormalizationlayerprovidesastandardizedformatfordataentities.EachEISstoresdatainitsown(usuallyproprietary)format.Thislayertransformsthedataintoaformthatisreadilyconsumablebytheupperlayersinthearchitecture.Thekeycapabilitiesprovidedbythislayerinclude:
Logicaldatamodel: Thelogicaldatamodelprovidesan"enterprise"viewofdataentities.Thelogicaldatamodelforanenterprisefrequentlyincorporatesindustry-standarddataformats(forexample,HR-XML,HL7,andIATA).Dataaggregation: Toconstructacompleteviewofanenterprisedataentity,itisfrequentlynecessarytoaggregatedatafromseveralsources.Thislayerincludesthisabilitytoaggregatedatafrommultiplesourcestoprovideacompleteenterprisedataentity.Datasynchronization: Datasynchronizationensuresthatalldataentitiesremainconsistentregardlessofwhereanupdateorchangeismade.Changesarepropagatedtoallcopiesandviewsinanorderlymanner.Datacaching: Datacachingallowsthecomputationalexpenseofaggregationandtransformationtobesharedacrossmorethanoneservicerequest.Theprimarypurposeofthislayerinthearchitectureistoencapsulateandhidethecomplexityofthedatamodelsandformatsusedbytheback-endsystems.Thisallowstheupperlayersinthearchitecturetooperateondataentitiesthatmatchtheneedsofthebusinessratherthanoperatingondatathatmatchthestorageapproachoftheback-endsystems.Thedatanormalizationprovidedbythislayershouldnotbeconfusedwithdatabasenormalization.
Thebusinessservicelayerexposesdataandfunctionalitythatisunderstandableandhasmeaninginabusinesscontext.ThislayerusesthelowerlayerstocreateSOAservicesthatabusinesspersonwouldunderstand.Thekeycapabilitiesprovidedbythislayerinclude:
Enrichment: Enrichmentistheprocessofaddingdataelementstoadataentitytogivetheentityincreasedinformation(andhencevalue)inabusinesscontext.Orchestration: Orchestrationisusedtocombinemultiplelower-leveloperationsintoabusinessservicethathidesthecomplexityofthelower-leveloperations.Custombusinesslogic: Custombusinesslogicishostedinthislayerofthearchitecture.Custombusinesslogicfrequentlyleverageslower-levellayerstoprovidesomeoftheexposeddataandfunctionality.Businessrules: Businessrulesdescribetheoperations,definitions,and
SOA Adoption and Architecture Fundamentals 8 - 15
constraintsthatapplytoanorganization.Essentiallytheyareif-thenstatementsthatdefineorconstrainsomeaspectofthebusiness.Althoughbusinessrulesarefrequentlycapturedincustomcode,itisfarbettertoextractthesebusinessrulesintoexplicitrulesetssothattheycanbemoreeasilyunderstood,modified,andmaintained.
Theprimarypurposeofthislayerinthearchitectureistoprovideaninterfacethatmatchesthebusiness.Thislayeralsoprovidesthelayerofinnovationovertheexistingback-endsystems.Custombusinesslogicandrulescanbeimplementedthatuseexistingsystemsyetprovidecapabilitiesthatextendbeyondthecapabilitiesprovidedbytheback-endsystems.
15
Thebusinessprocesslayerautomatesbusinessprocesses.Thislayerusesthelowerlayers,especiallythebusinessservicelayer,tocreateandautomatebusinessprocesses.Thebusinessprocessesgenerallyspanmultipleenterpriseinformationsystems.Thekeycapabilitiesinthislayerinclude:
Human-centricworkflow:Human-centricworkflowisabusinessprocessthatisprimarilyorentirelycomposedofhumantasks.Theremaybesomerelativelysmallamountofsysteminteractiontosupportthehumantasks.System-centricworkflow:System-centricworkflowisabusinessprocessthatisprimarilycomposedofsystem-to-systemactivities.Theremaybesomehumantasksinthebusinessprocess,orhumansmayberequiredtohandletheexceptioncasesinanotherwiseentirelysystem-to-systemprocess.Choreography:Choreographydefinesthemessagesthatflowbackandforthbetweensystemsthatareparticipatinginbusinessprocesses.AnexampleofchoreographywouldbeaRosettaNetPartnerInterfaceProcess(PIP).Businessactivitymonitoring:Businessactivitymonitoring(BAM)
SOA Adoption and Architecture Fundamentals 8 - 16
providesvisibilityintobusinessprocesses.TheBAMinformationisexposedindashboardsthatareusedtomeasureandimprovebusinessprocesses..
16
Decisionrules:Mostbusinessprocessesincludedecisionpointswherebranchingisdonebasedoncertaincriteria.Decisionrulesaretheencapsulationofthesedecisioncriteriaintoarulethatisthenmoreeasilymodifiedandmaintained.
Theprimarypurposeofthislayerinthearchitectureistodefineandautomatethebusinessprocessesinawaythatisexternalto―andindependentof―thespecificback-endsystemsusedintheorganization.Thisisolatesthebusinessprocessfromback-endsystemchangesand,conversely,isolatestheback-endsystemsfrombusinessprocesschanges.Decouplingthebusinessprocessesfromtheback-endsystemssimplifieschangesandmaintenanceforbusinessprocessesandback-endsystems.Thislayergenerallyprovidesthegreatestandmostmeasurablebusinessvalue.Themediationlayerprovidesloosecouplingfortheentirearchitecture.Itdecouplesthelayersofthearchitectureandalsodecoupleexternalusersofthelayersfromthespecificlayersinthearchitecture.Thekeycapabilitiesinthislayerinclude:
Routing: Routingprovidestheabilitytosendtheclientrequesttotheappropriateproviderbasedoncertaincriteria.Theroutingmayevenincludesendingtheclientrequesttomultipleproviders.Thiscapabilityfacilitateslocationtransparency,versioning,scalability,partitioning,requestpipelining,SLAmanagement,andsoon.Protocolmediation: Protocolmediationistheabilitytohandleaclientrequestthatusesoneprotocol(forexample,WS*,JMS,orREST)withaproviderthatusesadifferentprotocol.Thisprovidesprotocoldecouplingbetweentheproviderandtheconsumer.
Messagetransformation:Messagetransformationallowsaclientrequestthatusesonemessageformattobehandledbyaproviderthatexpectsadifferentmessageformat.Thisprovidesmessageformatdecouplingbetweentheproviderandtheconsumer.
Discovery: DiscoveryisthemechanismbywhichaclientfindsaproviderofaparticularSOAservice.Discoverycanoccuratdesigntimeorruntime.Monitoring:Monitoringcapturesruntimeinformationaboutthemessagesflowingthroughthemediationlayer.Becausethemediationlayerisanintermediaryformessagetraffic,itprovidesacentralizedmonitoringcapability.Policyenforcement: Policyenforcementprovidesconsistentapplicationofpolicies(forexample,WS-SecurityPolicy)acrossallmessagesflowingthroughthemediationlayer.Becausethemediationlayerisanintermediaryformessagetraffic,itprovidesacentralizedpolicyenforcementcapability.
Theprimarypurposeofthislayerinthearchitectureistofacilitatecommunicationbetweenlayersinthearchitectureandbetweenthisarchitectureandthesystemsthatconnecttoit.Thislayeris“infrastructure”inthetruestsenseandthereforerarelymapsdirectlytobusinessrequirements.However,thislayerprovideskeycapabilitiesthatmakethearchitectureserviceorientedandistheprimaryfocusfor
SOA Adoption and Architecture Fundamentals 8 - 17
meetingnonfunctionalrequirementssuchasscalability,reliability,availability,andmaintainability.AUserInteractionSystemisanysystemthataccessesanylayerintheintegrationarchitecture.Thereareawidevarietyofsystemsthatcanaccesstheintegrationlayers.Examplesincludeweb-basedapplications,fat-clientapplications,andpartnerapplications.Thisisnotformallyalayerintheintegrationarchitecture.Rather,thesearethesystemsthatgainvaluefromthedataandfunctionalityexposedbythelayersofthearchitecture
17
ASOAservicecanbeexposedatanylayerinthelogicalarchitecture.ASOAserviceimplementationcanalsospanlayersintheintegration.WhenconstructingaSOAservicethatspanslayers,developersshouldunderstandandapplythelayerssothattheimplementationusesthesameseparationofconcerns.ThisnotonlymakestheSOAserviceeasiertomaintain,italsomakesitpossibletoeasilyrefactortheSOAservicetoexposelower-levelfunctionalityasaseparateanddistinctservice.SOAservicescanbeclassifiedbytheuppermostlayerthatisincludedintheservicefunctionality.ThediagramintheslideillustratesseveraltypesofSOAservicesandalsoillustrateshowupperlayerscallservicesfromlowerlayers.Dottedlinesindicatecommunicationpathsthroughthemediationlayer,whereassolidlinesindicatedirectcommunicationthatisnotmediated.CommunicationthatisinternaltoaSOAserviceimplementationdoesnotusethemediationlayer.AllcommunicationthatusestheinterfacetoaSOAserviceshouldpassthroughthemediationlayer.Thediagramshowsthebusinessprocessdirectlyaccessingaconnectivityservice.Whilethearchitectureallowsthisdirectinteraction,ingeneralthisshouldbeavoidedsinceittendstomakethebusinessprocessdirectlydependentontheactualback-endsystembeingcalled.Abetterapproachis
SOA Adoption and Architecture Fundamentals 8 - 18
tokeepthebusinessprocessisolatedfromtheback-endsystemsbyhavingthebusinessprocesscallonlybusinessservicesordataservices.
18
Servicecompositionistheabilitytoleveragelower-levelservicestocreateahigher-levelservice.Theorchestrationshownintheslideisanexampleofservicecompositionbecausethebusinessserviceleveragestheconnectivityservicetosupplysomeofthenecessarycapability.Thisarchitecturesupportsandencouragesservicecompositionasaprimaryapproachfordeveloperstoapply.Whendoingcomposition,developersshouldrespectthelayeringofthearchitecture.Abusinessservicecouldleverageexistingconnectivityservicesordataservices,andadataservicecouldleverageexistingconnectivityservices.Butadataserviceshouldnotcallabusinessservice,andaconnectivityserviceshouldnotcalladataserviceorabusinessservice.Compositionbycallingserviceswithinthesamelayerofthearchitecture(forexample,abusinessservicecallinganotherbusinessservice)issupported,butcaremustbetakenwhenusingcompositionwithinalayerbecausethiscanleadtocomplexdependenciesthatpresentproblemsformaintenanceandversioning.Dependingontheproductsandtechnologyusedtoimplementthemediationlayer,itmayalsobepossibletoconstructservicecompositionsinthemediationlayer.Thisiscommonlyreferredtoasaservicepipeline.Inaservicepipeline,themediationlayerhandlesaservicerequestbyroutingtherequesttooneormoreservicespotentiallydoingmessagetransformationsandprotocoltranslationsaswell.Althoughitispowerful,thiscapabilityshouldbeusedjudiciouslysincethemediationlayerisnotageneral-purposeprogrammingenvironmentandisusuallyasharedresource.ExcessivecomputingorconfigurationerrorswithinthemediationlayercouldSOA Adoption and Architecture
Fundamentals 8 - 19
negativelyaffectallservicetrafficpassingthroughthemediationlayer.
19
Thetableintheslideillustratesthedifferencesbetweenabusinessprocessandanorchestration.Businessprocessesshouldnotcontainlower-leveltechnicaldetails.Thetechnicaldetailsshouldbeencapsulatedbybusinessservicesthatexposeaninterfacethatismeaningfultoabusinessuser.Forexample,thebusinessprocessmayhaveastepthatrequiresupdatingacustomeraddress.However,thecustomeraddressmaybestoredinseveralback-endsystems.Thiscomplexityisnotofinteresttoabusinessuser,norisitacorepartofthebusinessprocess.Therefore,thistechnicalcomplexityshouldbeencapsulatedbyasharedbusinessservicethatexposesan“updatecustomeraddress”operation.Theoperationthenupdatesallnecessarysystems.Noticethatthisencapsulationalsomakesitpossibletochangetheback-endsystemsorevenremoveback-endsystemswithoutaffectingbusinessprocessesthatupdatecustomeraddresses.Onlythesharedbusinessserviceneedstobemodified.Conversely,theorchestrationthatisincludedinthebusinessservicesshouldnotincludestepsthatarelikelytochangeduetochangesinbusinessstrategyorexecution.Thosestepsbelonginthebusinessprocesslayersothattheycanbeeasilychangedwheneverthebusinesschanges.
SOA Adoption and Architecture Fundamentals 8 - 20
Thisservice-orientedintegrationarchitecturedoesnotrequiretheuseofspecifictoolsortechnologies.Itisbasedonprinciplesthatwerepresentedearlier,anditcanberealizedusingawidevarietyoftoolsandtechnologies.Nonetheless,therearetypesoftoolsandtechnologiesthatarewellsuitedtoservice-orientedintegration,fitnicelywiththearchitecture,andthereforearelikelytobeusedbydevelopersapplyingthisarchitecture.Thesetoolsandtechnologiesareshownintheslideanddescribedforeachlayerinthearchitecture.MediationLayerTheprimarytoolsandtechnologiesforthislayerareEnterpriseServiceBus(ESB),Registry,Repository,andWebServiceManagement(WSM).Therearealsomanyexistingandemergingprotocolstandards,includingWS*,REST,JMS,XML,andXSLT.BusinessProcessLayerTheprimarytoolsandtechnologiesforthislayerareforcapturing,analyzing,executing,andmonitoringbusinessprocesses.Theseincludebusinessprocessanalysis(BPA),businessprocessmanagement(BPM),andbusinessactivitymonitoring(BAM).Rulesenginescanalsobeusedtocaptureandexecutedecisionrulesforbusinessprocesses.Thereareseveralassociatedstandards,
SOA Adoption and Architecture Fundamentals 8 - 21
includingBPMN,BPEL,andUMLActivityDiagrams.
21
BusinessServiceLayerTheprimarytoolsandtechnologiesforthislayerincludetraditionalsoftwaredevelopmenttools(forexample,IDE).Additionally,theorchestrationcapabilityrequiresadeveloper-focusedprocessdefinitiontool.Rulesenginescanalsobeusedtocaptureandexecutebusinessrules.AssociatedstandardsincludeUML,J2EE,BPEL,SCA,WSCDL,andsoon.DataNormalizationLayerTheprimarytoolsandtechnologiesforthislayerareformodelingdataandfordefiningandmanipulatingdataformats.Thus,theprimarytoolsarevisualizationandauthoringtoolsforERDs,O/Rmapping,XML,XSD,XQuery,XSLT,andsoon.Industry-standarddataformatsarealsoimportantforthislayer.Becausethislayeralsoperformsdataaggregationanddatasynchronization,orchestrationtools(forexample,BPEL)arealsoessentialforthislayer.ConnectivityLayerTheprimarytoolsandtechnologiesforthislayerareadapterdevelopmentkitsandmessagingtechnologies.Also,therearemanypossibletechnologiesthatmaybeneededtoconnecttothewidevarietyofsystemsthatmaybeincludedassourcesystems.AssociatedstandardsincludeJDBC,ODBC,andJCA.DataMovementLayerTheprimarytoolsandtechnologiesforthislayerareETLtoolsanddatacleansingtools.PersistentstoragetoolsandtechnologiesforbothOLTPandOLAParevitallyimportantforthislayer.
SOA Adoption and Architecture Fundamentals 8 - 22
Mediationisakeycomponentintheoverallarchitecture,providingthedecouplingbetweenconsumersandproviders.Thediagramintheslideillustratesthetypicalflowofamessagethroughthemediationlayer.
1. BeforecallingaSOAservice,theserviceconsumermustfirstfindtheappropriateSOAservices.Thisiscalledservicediscoveryandmaybeperformedatdevelopmenttimeoratruntime.Thearchitecturesupportsboth.ThereisalsoanauthorizationcheckdonetoseewhichSOAservicestheconsumerisallowedtosee.2. Theservicerequestismadetoaserviceproxyratherthandirectlytotheserviceprovider.Theserviceproxyallowsthemediationlayertoapplyallthecapabilitiesthathavebeenconfiguredforthatservicerequest.3. Anauthorizationcheckisperformedontheservicerequest.Althoughitisnotalwaysrequired,leveragingtheauthorizationcapabilitywithinthemediationlayerprovidesacentralizedapproachtosecuringSOAservices.Anauthorizationcheckmayalsobeperformedbeforeforwardingtheresponsemessagetoensurethattheconsumerisallowedtoseethecontentswithintheresponsemessage.4. Aftertheservicerequesthasbeenauthorized,the
SOA Adoption and Architecture Fundamentals 8 - 23
requestisroutedtotheappropriateserviceprovider.Therequestmessagemaybetransformedbeforebeingsenttotheprovider;theprotocolmaybetranslatedaswell.5. Alloftheactivitieswithinthemediationlayeraremonitored.ThisprovidesacentralizedmonitoringcapabilityacrossallSOAservices.
23
Theservice-orientedintegrationarchitecturespansmultiplesystemsandthecomputerprocesseswithinthosesystems.Thediagramintheslideillustratesthemessageflowandtheprocessboundariesthatarecrossedbythemessages.Asinglebusinessprocessmayresultinmessagesthatspanmanycomputerprocesses.Ingeneral,everyserviceinvocationresultsinaprocessboundarybeingcrossed.Infact,sinceeachserviceinvocationalsopassesthroughthemediationlayer,eachserviceinvocationcrossestwoprocessboundaries:mediationandserviceprovider.Additionally,theserviceimplementationmayalsocrossserviceboundaries.Forexample,thebusinessserviceshownintheslidemakesAPIcallstopackagedapplications(viaadapters),andeachpackagedapplicationrunsinitsownprocess.Althoughsevendifferentprocessesareshown,thediagramactuallysimplifiesthenumberofprocessesincludedintheintegration.Bothoftheconnectivityservices(AandB)wouldlikelyincludeout-of-processcallstothesourcesystemforwhichtheyareprovidingconnectivity.Eachtimeaprocessboundaryiscrossed,thereareperformanceimpactsfromthenetworkandmessagemarshallingandde-marshalling.ThisisaprimaryreasonthatSOAservicesshouldexposerelativelycoarse-grainedinterfaces.
SOA Adoption and Architecture Fundamentals 8 - 24
Thisisalsoareasonthataserviceimplementationmightspanmultiplelayersinthearchitecture.Thisalsoexplainswhythearchitectureincludesaseparatedatamovementlayer,becausemovinglargequantitiesofdataacrossserviceboundariesiscomputationallyveryexpensive.
24
Therearemanywaysthatthearchitecturecanbedeployedinanenterprise.Organizationalsize,structure,andspanofmanagementcontrolplayasignificantroleindeterminingmanyaspectsofdeployment,especiallyhowmuchissharedacrosstheenterpriseandhowmuchisspecifictoaportfolioordivision.Inamostlyshareddeployment,onlythelowerlevelsofthearchitecturearedeployedindependentlyacrossportfoliosordivisions.Thistypeofdeploymentisillustratedintheslide.Thistypeofdeploymenthasmostofthelayersdeployedsothattheyaresharedacrosstheenterprise.Onlythelowestlevelsofthearchitecturearespecifictotheportfolios.Itshouldalsobeclearthatitispossibleforasmallerenterprisetohavealloftheintegrationlayerssharedenterprise-wide.
SOA Adoption and Architecture Fundamentals 8 - 25
Astheenterprisesizeincreases,itbecomesmoredifficulttodeployasinglesharedenvironmentforintegration.Itbecomesmorelikelythatadistributedorhierarchicaldeploymentwillbeabetterfit(asillustratedintheslide).Thistypeofhierarchicaldeploymenthasseveraladvantages,includingthefollowing:
Eachportfoliocandefineitsownbusinessprocesses,SOAservices,anddataformatsthatareindependentfromotherportfolios.Thisdeploymentsupportsthefederateddatanormalizationapproach(describedearlier).BusinessprocessesorSOAservicesthatspanportfoliosexistattheenterpriselevelandcanleveragetheportfoliobusinessprocessesandSOAservices.Themediationlayerprovideslocationtransparencybetweentheportfolioandenterprisedomains.Thistypeofdeploymenteasilysupportsacquisitionsbecauseanewacquisitioncanbetreatedassimplyanotherportfolio.
Theprimarydisadvantageofahierarchicaldeploymentistheincreasedcostandcomplexityofsupportingmorehardwareandsoftware.Adherencetostandardstosupportinteroperabilityisalsomoreimportantinahierarchical
SOA Adoption and Architecture Fundamentals 8 - 26
deploymentbecausethevariousportfoliosmayselectdifferentproducts.
26
Theslideshowsahigh-levelviewofhowthearchitecturemightbedeployedtohardware.Thediagramshowseachlayerdeployedtoseparatehardware.Althoughthisdeploymentispossible,itmayalsobedesirabletodeploylayersofthearchitecturetothesamehardware.Showingthelayersdeployedtoseparatehardwaremakesthecommunicationpathsmoreexplicit.Thisalsoshowsthelayersdeployedtomultiplehardwareboxestoprovidescalabilityandreliability.Inamoderndatacenterwhereservervirtualizationiswidespread,thelayerswouldbedeployedtovirtualservers.Thenumberofvirtualservershostingeachlayerisdeterminedbytheloadonthelayerandcanbedynamicallyprovisionedasnecessary.Manyofthedetailedhardwaredeploymentdecisionsaredrivenbythespecificproductsandtechnologiesusedtorealizethearchitecture.
SOA Adoption and Architecture Fundamentals 8 - 27
SOA Adoption and Architecture Fundamentals 8 - 28
ThefollowingOracleFusionMiddlewareproductsareincludedintheproductmapping:
OracleBPELProcessManager(BPEL-PM):Providestheabilitytoquicklybuildanddeployorchestrationsandbusinessprocessesinastandards-basedmannerOracleBusinessActivityMonitoring(OBAM):Acompletesolutionforbuildinginteractive,real-timedashboardsandproactivealertsformonitoringbusinessprocessesandservicesOracleBusinessProcessManagement(OBPM):AcompletesetoftoolsenablingcollaborationbetweenbusinessandITtocreate,automate,execute,andoptimizebusinessprocessesOracleBusinessRules(OBR):Evaluaterulesrapidlyusingalightweight,high-performancerulesengineOracleBusiness-to-BusinessIntegration(OB2BI):ProvidesasingleintegratedsolutionforrapidlyestablishingonlinecollaborationsandautomatedprocesseswithbusinesspartnersOracleDataIntegrator(ODI):Anext-generationextract,load,andtransform(ELT)technologythatofferstheproductivityofadeclarativedesignapproach,aswellasthebenefitsofaplatformforseamless
SOA Adoption and Architecture Fundamentals 8 - 29
batchandreal-timeintegration
29