Your SlideShare is downloading. ×
0
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
CSE@UNSW Implementing SOA using ESB: beyond hype
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

CSE@UNSW Implementing SOA using ESB: beyond hype

639

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
639
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 1 1
  • The Service Oriented Society Our society has become what it is today through the forces of Specialization Standardization It is now almost exclusively “service” oriented Transportation Telecommunication Retail Healthcare Financial services
  • The Service Oriented Society Our society has become what it is today through the forces of Specialization Standardization It is now almost exclusively “service” oriented Transportation Telecommunication Retail Healthcare Financial services
  • Service Merriam Webster: “the work performed by one that benefits others”. Service provider performs an operation that benefits the consumer Service is defined as a contract between the provider and consumer.
  • Service-oriented architecture (SOA) is an approach to defining integration architectures based on the concept of a service . It combines proven concepts and techniques from several proceeding architecture and design styles (i.e., Object Oriented Design, Component Based Design, and Enterprise Application Integration technology), with new open standards and integration technologies. The goal of SOA is to enhance the IT infrastructure agility and flexibility through reduced interdependencies and loose coupled service interactions. A Service Oriented Architecture (SOA) is an architecture that is made up of components and interconnections that stress interoperability, location transparency and platform independence . Definition and delivery of core application functions through a series of coarse-grained services meant to be assembled through a message-oriented infrastructure Enterprise Service Bus Integration Hub Service Invocation and Execution Framework Service Locator
  • ESB is: Integration Hub Service Invocation and Execution Framework Service Locator
  • 05/06/10 The convergence is occurring because these ideas of data coordination, and business process management, and composite applications, and business activity monitoring have all moved together. And they are in turn driving another kind of convergence. They're driving a convergence between the world of application development and the world of application integration. New ESB (Enterprise Service Bus) approach: MOM-based (Message-Oriented Middleware) Plugs in EAI connectors, JMS/SOAP messages More 'intelligent' than hub-spoke Web Services Transformation Reliable routing NOT a SOA, P2P arch—but centrally controlled and managed by the ESB code; provides pre-packaged transport for SOA MOM/ESB-like facilities from: IBM (based on MQSeries) MSFT – Indigo product (Longhorn, 2006)? Sonic's ESB 5.5/Integration Suite (shipped Jun/04) Others: SeeBeyond, Cape Clear, Fiorano, PolarLake LTD, ObjectWeb Consortium (open-source) The only standards effort so far is JSR208 (Sun/Sonic)
  • A Service Oriented Architecture (SOA) is an architecture that is made up of components and interconnections that stress interoperability, location transparency and platform independence . Definition and delivery of core application functions through a series of coarse-grained services meant to be assembled through a message-oriented infrastructure Enterprise Service Bus Integration Hub Service Invocation and Execution Framework Service Locator
  • Coarse-grained communication by using document-based messaging. The message should be self-contained, self-describing providing enough information to get the job done. build extensibility and versioning support into your content model Compatible changes Backwards compatibility – service can accept old versions of message Forwards compatibility – service can accept new versions of message. “ Must Ignore” strategy– receivers ignore elements they do not understand Refer to “Versioning XML Languages” Challenges: Support for long running operations or integration with high latency systems Support network and application outages Scale to a large number of clients Guidelines: use asynchrony when appropriate Decouple request from response Response provided in callbacks or through polling mechanism Maintain context across a group of related requests Conversations Unique identifier passed in as parameter or custom header Add QoS Centralized configuration, policy management, and monitoring Service provisioning Auditing and logging SLA management Location transparency – dynamic, data-dependant routing Message translation - transformation
  • The Service Oriented Society Our society has become what it is today through the forces of Specialization Standardization It is now almost exclusively “service” oriented Transportation Telecommunication Retail Healthcare Financial services
  • XML used to pass messages between tiers Portable between heterogeneous platforms because it is a standard, self describing, text based format XML has become pervasive in all enterprise architecture tiers ESB is a platform that combines messaging, Web services, data transformation, and intelligent routing to reliably connect and coordinate the interactions between diverse applications both within the enterprises and between business partners [2]. ESB promises to move SOA beyond simple point-to-point service integration by facilitating large-scale implementation of the SOA principles with suitable service levels and manageability.
  • 05/06/10 Slide Purpose: Show typical architecture of services, Web services and applications, reiterate issues. Tightly Coupled - Have to know the location of the app, have to know the API of the app Synchronous – Typical communications are RPC-based, meaning that a request is sent and the application needs to wait for a reply before continuing any work. Unfortunately if the application is not running, it creates a bottleneck for the entire system. Fine-grain – Calls to applications are at the detailed method level and are compiled at development time, which restricts the flexibility of the system. As you can see from the diagram, with point to point integrations, there are many, many connections and different API formats. This produces an architecture that does not scale very well and is extremely difficult to manage, specifically, trying to adimister, audit, or analyze the network is very difficult, as well as planning for the future. The architecture is extremely brittle to make global configuration changes to or deployment changes. Often times the orchestration of events of a distributed process are hard-wired, so if a change needs to be made in a process, the code needs to be updated and recompiled. Additionally, a “roll-your-own” security model has been implemented, with each application using different security models – making security enforcement a nightmare.
  • 05/06/10 One way to solve this problem is to look for a better design pattern. Mainstream IT designers typically have not looked for solutions in the form of patterns. Handbooks of solutions to known problems are available to engineers in disciplines more mature than IT. If there were a handbook of IT patterns, the section on brokers would contain several entries. The field of patterns seems to have been most heavily influenced by an architect named Christopher Alexander who wrote a book called A Pattern Language, in 1977. The book has 253 pattern entries, each of which is a mini-handbook on solving a particular architectural problem. The solutions range from small scale to very large scale; for example a Six-foot balcony or Density Rings. Patterns are defined in a very specific way in Alexander’s book; Name - meaningful and short Context - a description of situation where the pattern applies Problem – the relevant forces or constraints Solution - instructions on how to construct one Example - a picture or description depicting typical implementations
  • Standards-based platform for reliable coordination of applications as loosely-coupled, event-driven services
  • 05/06/10 Definition: An Enterprise Service Bus (ESB) is a new architecture that exploits Web services, messaging middleware, intelligent routing, and transformation. ESBs act as a lightweight, ubiquitous integration backbone through which software services and application components flow. As an ideal solution for implementing an SOA, ESB provides not only a reliable backbone but also a flexible integration layer among software applications and services which are interacting with each other in a language and platform independent manner. The main features of an ESB can be summarized as follows: Communication Integration Transformation services Intelligent routing Content-based routing ESB has its own communication capabilities that allow participating services to carry out interactions using various, either proprietary (e.g. IBM WebsphereMQ, MSMQ, etc) or open standard, transport protocols (e.g. HTTP, JMS, SMTP, etc) in a publish/subscribe or point-to-point fashion. Communication capabilities also offer synchronous, asynchronous, messaged-based communication and queued messaging facilities similar to MOM. ESB also offers integration among various style communication approaches such as Web services, Java Connector Architecture (JCA), COM, and JMS. The mechanisms are used in a standard and service-oriented way, independent of the particular technologies. This facilitates service aggregation among legacy adapters, EAI middleware, Application Servers and even database systems. Since the message formats expected by services differ from one to another, ESB provides transformation services to make sure that messages received by any target service are in the format it desires. This feature is essential in B2B collaboration, among enterprises. Messages that flow in an ESB are XML-based, therefore transformation services are potentially implemented by using a standard-based approach such as XSLT or XQuery, etc., rather than a proprietary engine . Intelligent routing services provide core functionality in the ESB. In SOA, it is possible to define the business services that are composed of other services; therefore the itinerary of messages must be well understood by the ESB, and further ESB may want to dynamically modify the path, such as in case there’s a failure in the network. Moreover, ESB enables dynamic routing strategies by using the content-based routing services to examine the incoming message and based on the content and business rules encompassed in the message, automatically routes the message to the target destination .
  • 05/06/10
  • The ESB provides the means to manage the service infrastructure and the capability to operate in today’s distributed, heterogeneous environment. Routing and addressing services providing location transparency. An administration capability At least one messaging paradigm (e.g. request / response, pub/sub, etc.).· At least one transport protocol that is or can be made widely available. Takeaway: This chart shows a high level mapping of the product portfolio to the reference architecture. A separate follow-up session on further technical detail can be scheduled to discuss this in detail. Takeaway: The IBM Business Integration portfolio delivers capabilities required for all types of integration through a comprehensive architecture. These capabilities can be implemented on a build-as-you-go basis, and yet, because of the architecture and its service orientation, capabilities and project level solutions can be easily added as new requirements are addressed over time. Background: The IBM Business Integration Reference Architecture shows the key areas of capability that are required for comprehensive, enterprise wide strategies and solutions. At the core of the architecture is the Enterprise Service Bus. This architectural construct delivers all the inter-connectivity capabilities required to leverage and use services implemented across the entire architecture. The ESB can be implemented today to meet any of the quality of service requirements for the integration solution. Enterprise applications and enterprise data are accessible from the ESB through a set of access services. These access services provide the bridging capabilities between legacy applications, pre-packaged applications, enterprise data stores, etc and the ESB. Using a consistent approach, these access services expose the data and functions of the existing enterprise applications, allowing them to be full re-used and incorporated into functional flows that represent business processes. The set of services above the ESB provide all the middleware capabilities required to implement integration solutions of any type: - Information Services provide the capabilities required to federate, replicate, and transform data sources that may be implemented in a variety of ways. - Process Services provide the control services required to manage the flow and interactions of multiple services in a way that implements a business process. - Application Services provide the set of runtime services required for new applications and new business logic to be included in the integrated system. - User Interaction Services provide the capabilities required to deliver IT functions and data to end users, meeting the end-user's specific usage preferences. - Community Integration Services provide the document, protocol, and partner management services required for efficient implementation of business-to-business processes and inter-actions. Integration solutions must be managed once they are implemented and deployed into production. Managing these systems requires a set of capabilities that span the needs of IT operations professionals and business analysts who manage the business operations of the enterprise. These capabilities are delivered in the architecture through a set of comprehensive monitoring services that allow business dashboards, administrative dashboards, and other IT level displays to be used by IT and line-of-business personnel. Tools are an essential component of any comprehensive integration architecture. The BI Reference Architecture includes a set of tools that allow people to efficiently complete specific tasks and create specific output based on their skills, their expertise, and their role within the enterprise. Business Analysts who analyze business process requirements need modeling tools that allow business processes to be charted and simulated. Software Architects need tool perspectives that allow them to model data, functional flows, system interactions, etc. Integration Specialists require capabilities that allow them to configure specific inter-connections in the integration solution. Programmers need tools that allow them to develop new business logic with little concern for the underlying platform. Yet, while it is important for each person to have a specific set of tool functions based on their role in the enterprise, it is very important that the tooling environment allow deep collaboration among all these people. A common repository and functions common across all the developer perspectives (e.g. version control functions, project management functions, etc) are provided in the BI Reference Architecture through a common tool platform. Additional Information: The IBM Business Integration Reference Architecture is a complete and comprehensive architecture that covers all the integration needs an enterprise. Its services are well integrated but are delivered in a modular way, allowing integration implementations to start at a small project level. As each additional project is addressed, new integration functions can be easily added, incrementally enhancing the scope of integration across the enterprise. The architecture also supports Service Oriented Architecture strategies and solutions, given that the middleware architecture itself is designed using principles of service orientation and function isolation.
  • 05/06/10 This chart and the one that follows it take a different approach to constructing and ESB – we take a service centric view, where the assumption is that the environment begins with standards based services and then makes additions to that. Once again, we use the BI Reference Architecture as a starting point, though we have made some accommodations so that we can fit the various components in the appropriate places; the Enterprise Service Bus, the Application Access Services and the Application Services have been expanded and the Data Access Services has been made smaller. We begin with application servers. Things to note about this addition: Even though these scenarios are about IBM ESB implementations, it is important to observe that the ESB is agnostic to the brand – or brands - of application server that are used. From the ESB viewpoint, the application server is simply a standards based user of the ESB. One of the key capabilities of an ESB is its ability to mediate the service based interactions between application servers. The most common way that application servers use Web Services is SOAP /HTTP. This implies a synchronous transport, rather than a message based transport. While this does not seem to adhere to the common, analyst view of an ESB it must be supported as it is the way that most people have been implementing Web Services thus far. One of the primary thoughts about how/where ESBs will be used is when new application components are being developed (as opposed to integrating existing applications/packages) and most new application development is taking place on application servers. Further, much of this is service based application development, using Web Services specifications and protocols and the introduction of application servers provides support for Web Service specifications and protocols, making the environment much more dynamic and standards based than before. Also, capabilities such as JAX-RPC and WSIF enable these protocols to flow on transports such as messaging. So, the introduction of application servers into the mix enables an ESB that is much more like the analyst view of the ESB, providing support for Service based specifications and protocols. Also, it is more straightforward to see how standards based interfaces to applications can be provided, either directly (as in the PeopleSoft example – PeopleSoft supports Web Service based access to it’s applications) or indirectly via adapters which are encapsulated within service based facades. Note that for the PeopleSoft Services, we do not specify JMS as the access mechanism because it cannot be determined from the diagram – there are many possibilities. JMS is the access method for the Adapters. Finally, we should note that the support for mediations are available for the synchronous environment, as follows: The Web Services Gateway provides mediation support via Filters that are applied to the WSIF components, where used. JAX-RPC Handlers allow for mediation within the API. The BI reference architecture and the products that deliver these services. This chart follows on from the previous one and adds support for messaging and message based mediations. The following components are added: A message based transport mechanism (WebSphere MQ) with a standard JMS interface. This is represented by the 2 queue managers and the white block arrow. Robust mediation support in the form of publish/subscribe support (Event Broker) or content based routing and transformation support (Message Broker). Here, we are at the stage that many MQ based customers are today where they are running a ‘traditional’ Application Connectivity layer that is quite capable fulfilling the requirements of an ESB. The use of broker capabilities enables a dynamic set of capabilities as routing and transformation capabilities are encapsulated within the bus, rather than within external applications. Now that we have multiple transports available within the ESB, applications like PeopleSoft might use a (web) service based interface or direct JMS messaging Note that this picture is just the same that the one that we had at the conclusion of building from a message centric view. This is just as it should be – regardless of the starting point, the end result is the same. This chart builds to show the various stages that might be used in implementing an Enterprise Service Bus architecture using the IBM BI product family. We use the BI Reference Architecture as a starting point, though we have made some accommodations so that we can fit the various components in the appropriate places; the Enterprise Service Bus and the Application Access Services have been expanded and the Data Access Services has been made smaller. The very simplest scenario has a transport mechanism (WebSphere MQ) with a standard JMS interface. Mediation support, if required, is provided by user written applications (these are shown in pink … bottom, right) that can provide content based routing and transformation between users of the bus. This will provide a basic implementation that can be used by service based users of the bus. Note that the use (or not) of standards based service protocols (such as SOAP) is entirely optional and is the responsibility of the applications using this bus implementation. Neither is there any obvious use of WSDL to define the interfaces to these services. While it would be challenging to describe this as an ESB, it is clear that we have the WebSphere MQ classes of message delivery and support for basic routing and transformation and, therefore, the basis of the ESB infrastructure where we can treat users of this bus as services. We can add to this scenario applications that are users of the bus. PeopleSoft, as an example, has a JMS interface that could be used to interact with the bus. Next we might add some more formal, robust mediation support in the form of publish/subscribe support (Event Broker) or content based routing and transformation support (Message Broker). Here, we are at the stage that many MQ based customers are today where they are running a ‘traditional’ Application Connectivity layer that is quite capable fulfilling the requirements of an ESB. Note, however, that this goes beyond the analyst view of an ESB and it likely to be used only when there is significant interaction with legacy or packaged applications which might require significant amount of transformation support. The use of broker capabilities enables a more dynamic set of capabilities as routing and transformation capabilities are encapsulated within the bus, rather than within external applications. But, there are still not too many open standards being used here – unless the applications themselves are using SOAP based messages. WebSphere Business Integration Adapters can be used to interact with packaged applications or other components that are not messaging enabled. Next, we might add in the various classes of service available within the WebSphere BI family. We show this as a ‘background’ as it underpins all elements of the solution. Note that the IBM Qualities of Service is placed on top of the ‘Model, design, development, test tools’ area. This does not imply replacement, it just says that there was no-where else to put the words. These are assumed on subsequent pages and removed.
  • 05/06/10 Slide Purpose: High level features of SonicXQ and connectivity options Main message(s): SonicXQ provides a robust set of features and connectivity options to address the challenges in application integration. Purpose/Message With the tremendous success of Sonic ESB, we’ve been leading the charge for integration reform by championing a unique, distributed standards-based approach to solving enterprise integration problems. We’ve evolved our product strategy to now include the Sonic Business Integration Suite. With this new approach, Sonic continues to offer the integration market compelling business and technological value. Product and Technology Evolution Powered by the world’s first enterprise service bus (ESB), the Sonic Business Integration Suite™ offers a flexible, comprehensive platform for distributed, standards-based enterprise integration. This revolutionary XML technology can scale to meet the demands of any integration project, and offers the following capabilities: Secure, reliable enterprise class communications backbone Sophisticated business process management XML storage and processing Comprehensive, integrated development environment (IDE) Robust, pre-built adapters for immediate connectivity to any legacy or enterprise Information system Powerful management framework The Sonic Business Integration Suite facilitates rapid development of integrations projects and deployment on virtually any scale. Our unique ESB-based approach allows you to incrementally build an enterprise integration network one project at a time, avoiding the high cost and risk of monolithic integration products. Built upon an ESB foundation, the suite also offers optional integration capabilities such as sophisticated business process management as well as storage and processing of in-flight XML business data and events. Our flexible architecture allows you to purchase specific integration capabilities where and when you need them. A comprehensive set of robust adapters enables immediate connectivity with virtually any existing system, exposing them as services. Sonic is changing the economics of integration - dramatically extending integration reach while reducing the total cost of project development and deployment with the Business Integration Suite.
  • The Service Oriented Society Our society has become what it is today through the forces of Specialization Standardization It is now almost exclusively “service” oriented Transportation Telecommunication Retail Healthcare Financial services
  • Tool layer: Using Java and Swing with Fiorano ESB Native API to develop management-level tools such as network management, server configuration… Services layer: building blocks, services, there’re pre-built services + tools to deploy user-defined services in various languages: java, c++, c#, VB,… Peer layer: critical layer, as a thin daemon, light weight server, offline caching and message routing facilities, communicate with Messaging layer Messaging layer: transport infrastructure, allow JMS-compliant middleware platform to be plugged into the backbone messaging tunnel. Service provider (Enterprise server): server important operations need to be handled in a centralized manner: management of security attributes, application repository, state management for distributed workflow application, scheduling…
  • The Service Oriented Society Our society has become what it is today through the forces of Specialization Standardization It is now almost exclusively “service” oriented Transportation Telecommunication Retail Healthcare Financial services
  • The Service Oriented Society Our society has become what it is today through the forces of Specialization Standardization It is now almost exclusively “service” oriented Transportation Telecommunication Retail Healthcare Financial services
  • Instead of sending request to all manufacturers, retailer just send one request to ESB, and it will be forwarded to participating manufacturers in the ESB
  • Transcript

    • 1. Implementing SOA using ESB: beyond hype Abdelkarim Erradi Trung Nguyen Kien September 2004
    • 2. Agenda
      • Service Oriented Architecture (SOA)
      • Enterprise Service Bus (ESB)
      • ESB Architecture and Components
      • ESB design patterns
      • ESB case study
    • 3. Agenda
      • Service Oriented Architecture (SOA)
      • Enterprise Service Bus (ESB)
      • ESB Architecture and Components
      • ESB design patterns
      • ESB case study
    • 4. 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)”
    • 5. Service Orientation is a New Computing Paradigm
      • Not as a new name for
        • API
        • Component
      • 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 leveraged
        • by large numbers of consumers
        • in unforeseen context
    • 6. So… what is a service?"
      • There really are just two types of services Message Producers
          • Act and add stuff to messages
        • Message Consumers
          • Take stuff from messages and act on it
      • Messages flow through "pipelines"
        • Pipeline is a sequence of services
        • Messages grow and shrink on the way
      • Technology Agnostic Interaction
      An approach to logic partitioning that maximizes the re-use of application-neutral services.
    • 7. SOA Drivers Outsourcing Desire for increased Reuse Business Process Automation B2B Integration
    • 8. Constructing software in the web era (J2EE, .Net, …) App Server Client DB CCI CCI CCI ERP CRM request response Model ERP EAI b2b Internet CCI: Client Communication Interface Controller View
    • 9. A Component now Becomes a Service Running Outside the Consumer Boundaries Consumer DB CCI CCI CCI ERP CRM Service Service Service Registry 1 register SOAP SOAP SOAP XML XML XML 3 invoke 2 Discover and/or Bind Policies
    • 10. SOA is …
        • technology
        • product
        • protocol
        • standard
      Is not
      • Set of
        • policies
        • practices
        • frameworks
        • architectural patterns
      Is
    • 11. SOA is … (Cont’d)
      • SOA enables application functionality to be provided and consumed as sets of services
      • Services can be invoked, published and discovered
      • are abstracted away from the implementation using a single, standards-based form of interface.
    • 12. Services vs. Components and Objects
      • Similarities
        • Like classes and components, services have one or more interfaces
        • Publisher and consumer agree on the interface
      • Differences
        • SOA is about schemas, not object types
        • SOA talks about messages, not method calls
      • Relation
        • Services are built using classes and components
    • 13. SOA Tenets : PEACE
      • P olicy-based compatibility
      • E xplicitness of boundaries
        • We should opt-in to make our code accessible
      • A utonomy
        • Independent deployment, versioning and security
      • C ontract E xchange
        • Share contracts and schemas not classes or objects
      Clemens Vasters CTO, newtelligence AG Don Box Architect, Microsoft Corp.
    • 14. Applications as Fiefdoms
      • Application are like fiefdoms
      • They protect their citizens
        • State
        • Data
      • They don’t trust foreigners -> every alien is subject to authentication and inspection
      • The gate (service interface) in the only entrance into the fiefdom
      • Transactions and security implications
    • 15. From Components to (Web) Services
      • Requires a client library
      • Client / Server
      • Extendable
      • Stateless
      • Fast
      • Small to medium granularity
      • Loose coupling via
        • Message exchanges
        • Policies
      • Peer-to-peer
      • Composable
      • Context independent
      • Some overhead
      • Medium to coarse granularity
    • 16. Shift To A Service-Oriented Architecture
      • Function oriented
      • Build to last
      • Prolonged development cycles
      • Coordination oriented
      • Build to change
      • Incrementally built and deployed
      From To
      • Application silos
      • Tightly coupled
      • Object oriented
      • Known implementation
      • Enterprise solutions
      • Loosely coupled
      • Message oriented
      • Abstraction
      Source: Microsoft (Modified)
    • 17. Achieving Loose Coupling
      • Loose coupling – reduction of dependencies between components that communicate with one another in order to allow them to operate and evolve independently
      • Requires:
        • Coarse-grained communication
        • Support for message evolution
        • Support for asynchronous messages
      Requester Requester Runtime Receiver Runtime Receiver Requester Server Receiver Server Requester Store Receiver Store
    • 18. Agenda
      • Service Oriented Architecture (SOA)
      • Enterprise Service Bus (ESB)
      • ESB Architecture and Components
      • ESB design patterns
      • ESB implementations
      • ESB case study
    • 19. 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.
    • 20. Why ESB?
      • Inflexible
        • Tightly-coupled (Location & implementation aware)
        • Synchronous (RPC, availability dependent)
        • Fine-grained (Method level, development-time binding)
      • Many connections and data formats
      • Not scalable
      • Extremely difficult to manage
      Overcome Point-to-Point integration problems
    • 21. Hub and Spoke Pattern Point to Point Hub & Spoke Hub and spoke organizing principles 1. Don’t connect anything directly to anything 2. Applications are autonomous and share no databases directly 3. Knowledge of interconnections removed from source and targets and moved to the hub Benefits 1. Operational simplification 2. Adaptation to change 3. Reuse leverage
    • 22. Enterprise Service Bus (ESB)
      • Enterprise messaging
        • Reliable, secure interactions across the extended enterprise
        • Distributed deployment architecture for high scalability
      • XML as native data type for document exchange
      • Intelligent routing of business transactions
        • Itinerary, content and rule-based routing
        • Transformation of business data between applications
      • Service container end-points
        • Web services, JCA and Application Server support
        • Unified management and monitoring of entire services network
    • 23. ESB Characteristics
      • XML oriented
        • Messaging
        • Transformation
        • Intelligent routing services
      • Basic connectivity (Web Services, JCA Adapters, JMS)
      • Service-oriented architecture
      • Support for highly distributed deployments
      • Manageability
      • Robustness
      • Scalability and Performance
      • Security
      • Breadth of connectivity
      • Development / Deployment toolset
    • 24. ESB = MOM++
    • 25. Managing Web Services: A New Vendor Taxonomy Web Services Broker Multiprotocol ESB Web Services Controller Web Services Application Manager
      • Actional
      • AmberPoint
      • Oblix (Confluent)
      • Hewlett-Packard/ Talking Blocks
      • Infravio
      • Itellix
      • Computer Associates (Adjoin)
      • Hewlett-Packard/ Openview
      • Reactivity
      • Service Integrity
      • Westbridge
      • Fiorano Software's ESB
      • IBM's Services Integration Bus (a future product)
      • IONA Technologies' Artix
      • Kenamea's Web Messaging Platform
      • KnowNow's Event Routing Platform
      • Microsoft's Indigo (a future product)
      • PolarLake's JIntegrator
      • Software AG's EntireX
      • Sonic Software's ESB
      • SpiritSoft's Spiritwave
      • WebV2's Process Coupler
      • Blue Titan's Network Director
      • Cape Clear's 4 Server
      • Digital Evolution's DE Management Server
      • Flamenco Networks
      • Primordial's Web Services Network
      • Systinet's Web Services Bus
      • webMethods' Fabric
      Enterprise Service Bus Enterprise Systems Management Development Integration Management Web Services Middleware
    • 26. Aspects of the Enterprise Service Bus - IBM Enterprise Service Bus POLICY WSDL Described Services Uncluttered Business logic Customized Routing Service Selection Data Logging Format Translation Mediations Queues Pub/Sub Req/Rep Assured Secure Available Comms patterns and QoS WBI Adaptors MQ SOAP/HTTP JMS CEI .NET Wide connectivity
    • 27. IBM’s Business Integration Reference Architecture Enterprise applications Enterprise data Data Access Services Application Access Services IBM Software Offerings Monitoring Services Model, design, development, test tools Common Runtime Infrastructure WebSphere BI Modeler WebSphere BI Monitor Web Services Gateway WebSphere BI Event/Message Broker WebSphere MQ WebSphere BI Adapters DB2 Information Integrator Classic WebSphere Studio DB2 Information Integrator WebSphere Business Integration Server WebSphere Business Integration Connect WebSphere Application Server Enterprise Service Bus Process Services Community Integration Services Application Services Information Services WebSphere Portal Server User Interaction Services
    • 28. The SonicXQ Platform WSDL HTTP HTTP-S ActiveX C/C++ Java SonicXQ SonicMQ EJB/J2EE JDBC 3rd-Party JCA Adapters MQSeries TIBCO JMS FTP/SMTP P4GL SOAP Distributed Processing Framework Transformation Content-Based Routing Itinerary Mgmt JCA Adapter Toolkit Web Services Support Distributed Management Framework Distributed Services Framework / API Dynamic Routing Architecture (DRA) Parallel Clustering Active Routing Connection Mgmt Explorer (GUI Administration) End-to-End Security Pub/ Sub Point to Point Bridges
    • 29. Agenda
      • Service Oriented Architecture (SOA)
      • Enterprise Service Bus (ESB)
      • ESB Architecture and Components
      • ESB design patterns
      • ESB implementations
      • ESB case study
    • 30. Is there any concrete architecture?
      • There’re different views of ESB implementation but general ideas are same.
      • Let’s look at the implementation from few vendors.
    • 31. Cape Clear
      • Cape Clear Business Integeration Suite
        • Cape Clear Studio
        • Cape Clear Manager
        • Cape Clear Server
        • Cape Clear Data Interchange
    • 32. IBM
      • WebSphere MQ
      • WebSphere Business Integration Message Broker
      • WebSphere MQ Everyplace
      • WebSphere Application Server
    • 33. SpiritSoft
      • SpiritWare JMS Bus
      • SpiritWare Integration Server
    • 34. Fiorano ESB
    • 35. Convergence of Ideas
      • Built-in MOM
        • QoS
        • Multiple transport protocols (e.g.: HTTP, SMTP, JMS, MSMQ, etc)
      • Web services
        • Common interfaces
        • Ubiquitous
      • Transformation services
        • Interoperability
        • Integration
      • Intelligent routing
        • Communication
    • 36. Agenda
      • Service Oriented Architecture (SOA)
      • Enterprise Service Bus (ESB)
      • ESB Architecture and Components
      • ESB design patterns
      • ESB implementations
      • ESB case study
    • 37. Agenda
      • Service Oriented Architecture (SOA)
      • Enterprise Service Bus (ESB)
      • ESB Architecture and Components
      • ESB design patterns
      • ESB implementations
      • ESB case study
    • 38. Case studies
      • Supply Chain Management (SCM)
      • International Investment Bank (IIB)
    • 39. SCM
      • B2C situation
        • Customers review catalogues, and place orders online
        • Retailer system orders from warehouses
      • B2B situation
        • No stock available
        • Replenishment order sent to manufacturers
    • 40. SCM – ESB solution
      • Broker variation pattern
      • Encapsulate service invocations behind a single request.
    • 41. SCM – ESB solution cont.
      • Choose appropriate product mapping based on:
        • Available products
        • Product capabilities
    • 42. IIB
      • Typical bank architecture
      • Proprietary specific applications
      • Complex and expensive to maintain legacy solutions
    • 43. IIB – ESB solution
      • ESB/JMS implementation
      • SpiritWave Integration Server bridging among ESBs
    • 44. Summary
      • SOA is an evolutionary thing
        • No radically new thinking
        • Consolidates good things
      • The Message is the Message!
        • Think "message" instead of "call"
        • Asynchronous messaging
        • Loose coupling
      • ESB can help
        • Integration Hub
        • Service Invocation and Execution Framework
        • Service Locator
    • 45. SOA is still far ahead of us
      • We still need to shape what SOA means
        • More standards are required
        • BPM and SOA will complement each other
      • We need lots of work to achieve and deliver the SOA value and go beyond “toy” applications of SOA
        • At best we are capable of delivering web services today
        • We need ESB!
      • Standards “convergence” is now of primary importance
    • 46. Recommendations
      • Technology alone is not enough!
      • Design with loose coupling in mind
        • Decoupling is an investment in future change
      • The important issues for interoperability of autonomous computing system are around messaging and defining the interactions
      • Schema, protocol, meta-data, and versioning are essential to success
    • 47. Resources
      • MSDN SOA Resources
        • http://msdn.microsoft.com/architecture/soa
      • Bishop, S., Hopkins, A., Milinski, S., Nott, C., Robinson, R., Adams, J., Verschueren, P. & Acharya, A. IBM Redbook 2004, Patterns: Implementing an SOA using an Enterprise Service Bus. Available: http://www.redbooks.ibm.com/redbooks/pdfs/sg246346.pdf
      • Craggs, S., 'Best-of-breeds ESBs: Identifying best-of-breed characteristics in Enterprise Services Buses (ESBs)', EAI Industry Consortium, June 2003
      • Sonic Software 2004, 'Distributed Service-Oriented Architecture: Delivering Standards-based Integration, the Advantages of an ESB'.
    • 48. Q & A ?

    ×