Implementing SOA using ESB: beyond hype

  • View
    36

  • Download
    0

Embed Size (px)

DESCRIPTION

Implementing SOA using ESB: beyond hype. Abdelkarim Erradi Trung Nguyen Kien September 2004. Agenda. Service Oriented Architecture (SOA) Enterprise Service Bus (ESB) ESB Architecture and Components ESB design patterns ESB case study. Agenda. Service Oriented Architecture (SOA) - PowerPoint PPT Presentation

Text of Implementing SOA using ESB: beyond hype

  • AgendaService Oriented Architecture (SOA)Enterprise Service Bus (ESB)ESB Architecture and ComponentsESB design patterns ESB case study

  • AgendaService Oriented Architecture (SOA)Enterprise Service Bus (ESB)ESB Architecture and ComponentsESB design patterns ESB case study

  • Why should we care?

    By 2008, SOA will be a prevailing software engineering practice, ending the 40-year domination of monolithic software architecture (0.7 probability)

  • Service Orientation is a New Computing ParadigmNot as a new name for APIComponent

    A genuine set of concepts with which we can construct new kinds of software This is as significant if not more than Object Orientation

    In particular SO forces us to think about enabling the same piece of code to be leveragedby large numbers of consumers in unforeseen context

  • So what is a service?"There really are just two types of services Message ProducersAct and add stuff to messagesMessage ConsumersTake stuff from messages and act on it Messages flow through "pipelines"Pipeline is a sequence of servicesMessages grow and shrink on the wayTechnology Agnostic InteractionAn approach to logic partitioning that maximizes the re-use of application-neutral services.

  • SOA DriversOutsourcingDesire for increased ReuseBusinessProcessAutomationB2B Integration

  • Constructing software in the web era (J2EE, .Net, )

    App Server

    ClientDBCCICCICCIERPCRMrequestresponseModelERPEAIb2bInternetCCI: Client Communication InterfaceControllerView

  • A Component now Becomes a Service Running Outside the Consumer BoundariesConsumer

  • SOA is technologyproduct protocolstandardIs not

  • SOA is (Contd)SOA enables application functionality to be provided and consumed as sets of services Services can be invoked, published and discoveredare abstracted away from the implementation using a single, standards-based form of interface.

  • Services vs. Components and ObjectsSimilaritiesLike classes and components, services have one or more interfacesPublisher and consumer agree on the interfaceDifferencesSOA is about schemas, not object typesSOA talks about messages, not method callsRelationServices are built using classes and components

  • SOA Tenets : PEACEPolicy-based compatibility Explicitness of boundariesWe should opt-in to make our code accessibleAutonomyIndependent deployment, versioning and securityContract ExchangeShare contracts and schemas not classes or objectsClemens Vasters CTO, newtelligence AGDon Box Architect, Microsoft Corp.

  • Applications as FiefdomsApplication are like fiefdomsThey protect their citizens StateDataThey dont trust foreigners -> every alien is subject to authentication and inspectionThe gate (service interface) in the only entrance into the fiefdomTransactions and security implications

  • From Components to (Web) ServicesRequires a client library

    Client / ServerExtendableStateless

    FastSmall to medium granularityLoose coupling via Message exchanges PoliciesPeer-to-peerComposableContext independent

    Some overheadMedium to coarse granularity

  • Shift To A Service-Oriented ArchitectureFunction orientedBuild to lastProlonged development cyclesFromToCoordination oriented Build to changeIncrementally built and deployedApplication silosTightly coupledObject orientedKnown implementationEnterprise solutionsLoosely coupledMessage orientedAbstractionSource: Microsoft (Modified)

  • Achieving Loose CouplingLoose coupling reduction of dependencies between components that communicate with one another in order to allow them to operate and evolve independentlyRequires: Coarse-grained communicationSupport for message evolutionSupport for asynchronous messages

  • AgendaService Oriented Architecture (SOA)Enterprise Service Bus (ESB)ESB Architecture and ComponentsESB design patterns ESB implementationsESB case study

  • What ESB?ESB = MOM++ESB combines MOM, Web services, transformation and routing intelligence Standards-based integration: all WS standards work toward providing secure, reliable messaging workflows'Any to Any (A2A)Facilitate large-scale implementation of the SOA principles with suitable service levels and manageability.

  • Why ESB?InflexibleTightly-coupled (Location & implementation aware)Synchronous (RPC, availability dependent)Fine-grained (Method level, development-time binding)Many connections and data formatsNot scalableExtremely difficult to manageOvercome Point-to-Point integration problems

  • Hub and Spoke PatternPoint to PointHub & SpokeHub and spoke organizing principles1. Dont connect anything directly to anything2. Applications are autonomous and share no databases directly 3. Knowledge of interconnections removed from source and targets and moved to the hubBenefits1. Operational simplification2. Adaptation to change3. Reuse leverage

  • Enterprise Service Bus (ESB)Enterprise messagingReliable, secure interactions across the extended enterpriseDistributed deployment architecture for high scalabilityXML as native data type for document exchangeIntelligent routing of business transactions Itinerary, content and rule-based routing Transformation of business data between applicationsService container end-pointsWeb services, JCA and Application Server supportUnified management and monitoring of entire services network

  • ESB Characteristics

    XML oriented MessagingTransformationIntelligent routing servicesBasic connectivity (Web Services, JCA Adapters, JMS)Service-oriented architectureSupport for highly distributed deploymentsManageabilityRobustnessScalability and PerformanceSecurityBreadth of connectivityDevelopment / Deployment toolset

  • ESB = MOM++

  • Managing Web Services: A New Vendor TaxonomyWeb Services BrokerMultiprotocol ESBWeb Services ControllerWeb Services Application ManagerActionalAmberPoint Oblix (Confluent) Hewlett-Packard/ Talking BlocksInfravioItellixComputer Associates (Adjoin)Hewlett-Packard/ OpenviewReactivityService IntegrityWestbridgeFiorano Software's ESB IBM's Services Integration Bus (a future product)IONA Technologies' ArtixKenamea's Web Messaging Platform KnowNow's Event Routing Platform Microsoft's Indigo (a future product)PolarLake's JIntegrator Software AG's EntireXSonic Software's ESB SpiritSoft's SpiritwaveWebV2's Process CouplerBlue Titan's Network Director Cape Clear's 4 Server Digital Evolution's DE Management Server Flamenco NetworksPrimordial's Web Services NetworkSystinet's Web Services BuswebMethods' FabricEnterprise Service BusEnterprise Systems ManagementDevelopmentIntegrationManagementWeb Services Middleware

  • Aspects of the Enterprise Service Bus - IBMEnterprise Service Bus

    POLICYWSDL Described Services

  • IBMs Business Integration Reference ArchitectureEnterprise applicationsEnterprise dataData Access ServicesApplication Access ServicesIBM Software Offerings Monitoring ServicesModel, design, development, test toolsCommon Runtime InfrastructureWebSphere BI ModelerWebSphere BI MonitorWeb Services GatewayWebSphere BI Event/Message BrokerWebSphere MQWebSphere BI AdaptersDB2 Information Integrator ClassicWebSphere StudioDB2 Information IntegratorWebSphere Business Integration Server WebSphere Business Integration Connect WebSphere Application ServerEnterprise Service BusProcess Services

    Community Integration ServicesApplication ServicesInformation Services WebSphere Portal Server

    User Interaction Services

  • The SonicXQ PlatformWSDLHTTPHTTP-SActiveXC/C++JavaSonicXQSonicMQEJB/J2EEJDBC3rd-Party JCA AdaptersMQSeriesTIBCOJMSFTP/SMTPP4GLSOAP

  • AgendaService Oriented Architecture (SOA)Enterprise Service Bus (ESB)ESB Architecture and ComponentsESB design patterns ESB implementationsESB case study

  • Is there any concrete architecture?Therere different views of ESB implementation but general ideas are same.Lets look at the implementation from few vendors.

  • Cape ClearCape Clear Business Integeration SuiteCape Clear StudioCape Clear ManagerCape Clear ServerCape Clear Data Interchange

  • IBMWebSphere MQWebSphere Business Integration Message BrokerWebSphere MQ EveryplaceWebSphere Application Server

  • SpiritSoftSpiritWare JMS BusSpiritWare Integration Server

  • Fiorano ESB

  • Convergence of IdeasBuilt-in MOMQoSMultiple transport protocols (e.g.: HTTP, SMTP, JMS, MSMQ, etc)Web servicesCommon interfacesUbiquitousTransformation servicesInteroperabilityIntegrationIntelligent routingCommunication

  • AgendaService Oriented Architecture (SOA)Enterprise Service Bus (ESB)ESB Architecture and ComponentsESB design patterns ESB implementationsESB case study

  • AgendaService Oriented Architecture (SOA)Enterprise Service Bus (ESB)ESB Architecture and ComponentsESB design patterns ESB implementationsESB case study

  • Case studiesSupply Chain Management (SCM)International Investment Bank (IIB)

  • SCMB2C situationCustomers review catalogues, and place orders onlineRetailer system orders from warehousesB2B situationNo stock availableReplenishment order sent to manufacturers

  • SCM ESB solutionBroker variation patternEncapsulate service invocations behind a single request.

  • SCM ESB solution cont.Choose appropriate product mapping based on:Available productsProduct capabilities

  • IIBTypical bank architectureProprietary specific applicationsComplex and expensive to maintain legacy solutions

  • IIB ESB solutionESB/JMS implementationSpiritWave Integration Server bridging among ESBs

  • SummarySOA is an evolutionary thingNo radically new thinkingConsolidates good t