INT-4: Introducing Sonic ESB®

INT-4: Introducing Sonic ESB®
Remove the marketing hype. What is SOA Talk about what is an ESB as opposed to Sonic Jaime Meritt Director, ESB Product Management Rob Straight Principal Product Manager

Your Speaker Jaime Meritt Rob Straight Director ESB Product Management
A little bit about us… Jaime Meritt Director ESB Product Management Responsible for ESB Product Family strategy and planning Architect Sonic ESB Rob Straight Principal Product Manager, OpenEdge Responsible for integration strategy and planning INT-4: Introducing Sonic ESB

Agenda ESB Fundamentals The Role of an Enterprise Service Bus
How an Enterprise Service Bus Works Next Steps INT-4: Introducing Sonic ESB

Information Technology
The Pressure on IT Must reuse existing assets …not designed to collaborate Must show rapid, measurable ROI Can’t introduce operational risk …IT Bound By Constraints Develop new products and services Speed business transactions Comply with governance Integrate acquisitions Outsource business functions Business Demands Change… Information Technology Nothing new here – we’re in an ever changing, challenging world – more so than ever before - more constraints on resources (time & cost) and need to make changes with low cost, low risk and quickly! Speed & Agility are the key, and IT has to make it happen! People & organizations are resistant to change- this is human nature, to avoid risks that change might bring. But change abounds as a normal course of business. Known changes the can be planned for (technology, regulatory compliance) Expected changes, but not knowing exactly how or when they will happen (cost of labor increase) Unforeseen changes (Internet, global terrorism) Some changes have to be dealt with, e.g. regulatory compliance imposed from outside the organization. It comes down responding to change (while managing risk). There is a strong need to respond to change quickly, and if possible use change to your competitive advantage. Adapt and be agile, or die. The fittest (most able to adapt to change) species survives, not the strongest. - Survival of the fittest per Charles Darwin and On The Origin of the Species. INT-4: Introducing Sonic ESB

Introducing SOA & SOBA Service-Oriented Architecture > Service-Oriented Business Applications An approach for building agile and flexible business applications Loosely coupled services = flexible business processes SOA is not A product or application A specific technology A specific standard A specific set of rules After the dot com boom and bust, an new era of cost containment began. IT organizations were asked to do more with less: make use of existing assets and resources to get the job done. No longer is “rip and replace” a viable alternative. Instead, as much value as possible needs to be extracted from existing systems. Loose coupling, no hard connections No one technology, standard, rules etc … more of an architectural concept! INT-4: Introducing Sonic ESB

The Accidental Architecture
High cost of operations Low reuse of assets Resistant to change Difficult to visualize and govern Mainframe .NET J2EE OpenEdge Open Source Isolated silos of fragmented process INT-4: Introducing Sonic ESB

Enterprise Service Bus
Infrastructure for SOA Integration Binds disparate systems into SOA Flexibly, reliably and efficiently routes data and events, manages processes Inserts mediation capabilities (for transformation, data enrichment, etc.) Promotes high asset reuse, agility, manageability and governance Mainframe .NET J2EE OpenEdge Open Source INT-4: Introducing Sonic ESB

The Enterprise Service Bus
Web Services only address a subset of the issues J2EE™ APPLICATION PACKAGED APPLICATION & LEGACY SYSTEMS .NET™ APPLICATION How do you: SOA-enable existing applications? Resolve incompatibilities? Compose and reuse service capabilities? Don’t forget: Distribution Scalability Reliability Security XML SOAP HTTP WEB SERVICES INTERFACE OPENEDGE FUTURE SERVICES INT-4: Introducing Sonic ESB

The Enterprise Service Bus
An ESB provides flexible integration of business applications in an SOA Across organizational boundaries and to remote sites With low latency, high reliability and continuous availability Evolve, scale and extend throughout the enterprise It’s quite common for ESB deployments to cross large geographic boundaries. In practice, though, the department in the building across campus can be as much a challenge to integrate because the systems run in different security domains or have different owners. We find that most of our customers appreciate the distributed architecture of Sonic ESB, either because the endpoints that it integrates are themselves distributed, or because they need the distributed architecture of Sonic ESB in order to scale to meet high throughput requirements. Regardless, the flexibility of Sonic ESB architecture—the ability to change process, service or schema independent of physical deployment—is an important aspect of pretty much every Sonic ESB deployment. Any number of locations Any number of services Any number of processes INT-4: Introducing Sonic ESB

The Role of an Enterprise Service Bus
A practical approach to SOA There is no SOA “big bang” - incremental adoption is the only path for success The ESB allows for project by project development utilizing “SOA foundational technologies” and best practices Start with a “business change project” and show immediate value Changes in marketing strategy Mergers and acquisitions Regulatory requirements Breaking down functional silos Creating an E-value chain Incrementally add other business change projects using standards-based integration options INT-4: Introducing Sonic ESB

Making sense of SOA standards Transports HTTP JMS Data Model XML (POX) SOAP Transformation XSLT XQuery Interface and Orchestration WSDL BPEL Registry UDDI Enterprise Security Reliability INT-4: Introducing Sonic ESB

Loose Coupling – How Loose is Loose? ? The less you know the better!! Systems were not originally designed to work together so services vary widely Data Model Semantics Location Time Security Interface Version Web Services gets all of the hype, but it’s not the only approach The ESB provides infrastructure to resolve these incompatibilities INT-4: Introducing Sonic ESB

Provides enterprise grade SOA integration infrastructure Standards-Based integration infrastructure for connectivity, transformation, and security Service Enable heterogeneous endpoints Mediate service exchanges to resolve incompatibilities Intelligent Routing and Service Orchestration to compose and reuse services SONIC ESB® ENTERPRISE SERVICE BUS J2EE™ APPLICATION PACKAGED APPLICATION & LEGACY SYSTEMS .NET™ APPLICATION OPENEDGE APPLICATION WEB SERVICE INT-4: Introducing Sonic ESB

How an Enterprise Service Bus Works
Connect existing applications to the bus ‘On-ramps’ and ‘off- ramps’ for the ESB Proprietary and complex applications B2B protocols Packaged applications Mainframe and legacy Extensibility APIs to build additional adapters OPENEDGE APPLICATION LEGACY SYSTEMS MAINFRAME PACKAGED APPS .NET™ APPLICATION B2B PARTNER J2EE APPLICATION ENTERPRISE SERVICE BUS INT-4: Introducing Sonic ESB

Application infrastructure integration Business logic in OpenEdge 10 / 4GL Process & integration logic in ESB OpenEdge tools for configuring adapters Deploy OpenEdge apps as ESB services JEE and .Net J2EE™ APPLICATION OpenEdge Application .NET™ APPLICATION PARTNER SYSTEM WEB SERVICE Dave Cleary, Tuesday 10:30 – 11:30 AM INT-4: Introducing Sonic ESB

Data store integration Access data in OpenEdge and foreign data sources Service interface to database queries XML to query/result mapping Load balancing and connection pooling XML TRANSLATE RESULTSET SONIC DATABASE SERVICE XML MAPPING RDBMS SQL CALL OR STORE PROCEDURES INT-4: Introducing Sonic ESB

Mediation and Intelligent routing Fn() Service Adapter Simple data format translation Queuing and Publish/Subscribe Content based routing to select service implementation based on business messages Itineraries Routing slip pattern provides a simple sequencing mechanism State travels with the message to obviate the need for bi-directional communications Compose and reuse itineraries to separate concerns Service Request Service Response Service Implementation Data Business Logic Service Interface Time Location Type Version Interface Cardinality Lookup Model (is a response expected or not) Notification Request-reply Mode (does the sender wait for a response or not) Synchronous Asynchronous Cardinality (M:M or 1:1) Pub-sub Point-to-pointNormalize data flows through bus Mediation is an essential capability of the ESB and provides three principal benefits. First, mediation allows the ESB to reconcile incompatible protocols, data formats, and interaction patterns of connected services. By bridging these differences among services with the built-in mediation functionality of the ESB, it is much easier to rapidly set up communications among diverse services. The ESB mediates not just message format and protocol, but also interaction patterns, so synchronous services can communicate with asynchronous services—and vice-versa—without any changes to the services’ coding itself. The ability to mediate services without requiring changes to the services themselves leads to the key second benefit of mediation: it eliminates inflexible, hard-coded service interdependencies. Service interdependencies, especially hidden ones, are the enemy of flexibility in a SOA, because they make it difficult to understand the impact of a service change. By isolating and making explicit the mediation among services, the ESB makes it dramatically easier to manage change in a complex environment. The flexibility of mediation can be seen more broadly to provide a third benefit, namely that the ESB makes it easy to combine and extend existing services to meet new requirements. Mediated services become general-purpose building blocks which may be orchestrated in order to automate end-to-end business processes INT-4: Introducing Sonic ESB

Service Orchestration: Enabling reuse with WS-BPEL 2.0 Process layer provides higher level abstraction for creation coarse grained services Compose processes out of existing services and processes Correlate events within and across running processes Familiar developer constructs: conditionals, loops, delays, scoped state Manage concurrent (often long-running) service interactions Compensate for completed activities in the event of failure COMPOSED SERVICES SERVICES CORRELATE EVENTS Today, BPEL is the most widely-accepted standard for service orchestration. Simpler than Java or C#, yet rich with support for Web services, it is a natural choice for SOA development. Most people are aware that BPEL helps you compose processes out of existing services and processes, but that’s only a part of the BPEL story. It also provides a host of features that take care of a lot of the detail work related to correlation of events within and across running processes. BPEL provides a rich set of control flow features that are familiar programmatic constructs, such as loops, conditionals, delays, and scoped state. BPEL manages concurrent, long-running transactions, and so it provides a means by which process state is stored to disk for scalability and recovery. And, BPEL has sophisticated features for compensation from failures, giving you a standard way to define units of work that must be completed or reversed in their entirety. SERVICES INT-4: Introducing Sonic ESB

The problem: Back-end integration Browser Change requires re-coding Chatty protocols over WAN? How do I secure over firewall? Will WS scale up? Hard to coordinate changes across organizational silos. Portal Presentation Layer App Server WS JDBC WS JDBC WAN The remote information access problem comes up in the context of back-end integration. In simple scenarios, using the integration that comes with a portal is quite sufficient. Application Application INT-4: Introducing Sonic ESB

The problem: Can’t re-use dedicated integration layer Browser Web Svc Partner System Portal Presentation Layer App Server JDBC WS JDBC WS JDBC WS WS JDBC WAN WAN Application Application INT-4: Introducing Sonic ESB

The ESB solution Integrates each back end system as managed service Across remote sites and security domains Can run asynchronous back-end queries in parallel Infrastructure extensible to new uses without disruption, without remote system recoding Browser Web Services Consumer Portal Extensible for future uses Without negotiation with aps Owners at the endpoints You manage App on-ramp remotely, use apis as reqd. no negotiation after gaining access Application Application INT-4: Introducing Sonic ESB

The problem: Accelerate business process cycle Latency of batch processing BATCH CYCLE BATCH CYCLE BATCH CYCLE TIME LOST: Sales order processing STP – straight through processing of trades in financial services Flow-through provisioning – provisioning of new service for a customer, whether over the phone or at a retail shop JIT inventory Maybe they are in different geographies, but more likely, they are in their own departments, and have their own way of doing things, and do these things at their own pace. FTP FTP FTP ORDER ENTRY ERP FULFILL - MENT BILLING ORDER CASH Sales Manufacturing Shipping Finance INT-4: Introducing Sonic ESB

The problem: Accelerate business process cycle Latency of batch processing Error remediation 80% of data transfer done this way BATCH CYCLE BATCH CYCLE BATCH CYCLE TIME LOST: FTP FTP FTP ORDER ENTRY ERP FULFILL - MENT BILLING ORDER CASH Error: Retransmit Sales Manufacturing Shipping Finance INT-4: Introducing Sonic ESB

BPEL Integration example 2 1 3 REPEAT START END WSDL LEGACY ORDER BUILD SHIP Use BPEL to iterate on 3-step process Each step invokes legacy resources But BPEL is completely binding-agnostic It knows only of WSDL How do I integrate with the target systems? Here is a VERY simple BPEL process, that just executes three steps in an infinite loop. The diagram showing the process flow in between the horizontal braces is actually a real BPEL diagram. But I took some artistic license in representing the “repeat” diagram because it is too hard to show in a PowerPoint slide. Anyway, you get the idea. By design, the BPEL language itself provides no means to integrate or even communicate with the services it orchestrates. Every BPEL vendor has to supply a binding of some type. The BPEL spec is silent on this in order to provide room for vendors to innovate. INT-4: Introducing Sonic ESB

BPEL Integration example 1 2 3 2 1 3 REPEAT START END BPEL SERVER ORDER ORDER SHIP BUILD BPEL Server uses Sonic ESB to bind WSDL interfaces to heterogeneous resources connected to the ESB. BUILD SHIP BPEL orchestrates WSDL services into a process ESB binds WSDL to heterogeneous resources INT-4: Introducing Sonic ESB

BPEL Integration example with two fulfillment centers 2 1 3 REPEAT START END WSDL LEGACY ORDER BUILD LOCAL SHIP REMOTE SHIP CRM ? That means two shipping systems: one local, one remote The second shipping system needs special handling We can’t ship without looking up customer information that is in the remote fulfillment center Of course, that’s a very simple example, and real life is rarely that simple. So let’s make the example a little more interesting by extending it to a situation where we have two fulfillment centers, each with their own shipping system. And, in order to use the remote fulfillment center, we need to look up some customer information in a CRM system that is deployed there. This is not an unusual situation at all. INT-4: Introducing Sonic ESB

BPEL Integration example with two fulfillment centers REMOTE SHIP CRM BPEL SERVER A B C ORDER 1 CRM SHIP 2 B A C 3 ITINERARY 2 3 BUILD SHIP 1 Extend “SHIP” service using ESB intelligent routing CBR selects branch Itinerary directs message flow for additional mediation steps Intelligent routing obviates WAN hop – no “central brain” Separation of BPEL and ESB concerns maximizes flexibility INT-4: Introducing Sonic ESB

Distribution, Scalability, Availability, and Security 1 2 3 4 2 Inside the ESB, the communication backbone is implemented by a network of cooperating brokers. These brokers automatically switch between JMS and SOAP/HTTP protocols depending on the nature of the target service (ESB service or Web service). The brokers also maintain context information to correlate requests and responses to handle asynchronous calls. Services can be replicated to provide additional processing throughput. Clustered brokers provide dynamic scalability of message processing without disruption of running services. Dynamic Routing Architecture extends automatic broker communications beyond cluster and WAN boundaries, creating the foundation for a true bus deployment topology. Sonic’s unique Continuous Availability Architecture (CAA) provides the highest level of availability and fault tolerance for SOA by eliminating operational risk of lost data without expensive RAID, OS clustering software or third-party HA frameworks in the messaging layer. Clustered communication brokers scale to meet changing throughput requirements Brokers dynamically route messages across clusters, WAN and security domains Continuous Availability Architecture (CAA) provides communications availability Add service instances for transparent load-balancing, availability, disaster recovery INT-4: Introducing Sonic ESB

OpenEdge & Sonic SOA Infrastructure
Building your SOA infrastructure Integration Build and integrate with OpenEdge and Sonic Get on the bus with the app server adapter Focus on business logic not infrastructure Leverage existing & legacy applications Cost effective, incremental integration INT-4: Introducing Sonic ESB

The Progress Software Product Line
Overcoming IT and Business Challenges Using SOA Event Processing Mainframe Connectivity Semantic mediation tools for application and service data management with common information model visualization, impact analysis and testing SOA management platform providing monitoring, active policy enforcement and service delivery optimization Data Access Application Platform Semantic Integration SOA Management Enterprise Service Bus Message-based, distributed, event-driven architecture with Service-based components INT-4: Introducing Sonic ESB

For More Information, go to…
PSDN A New Service-Oriented Architecture (SOA) Maturity Model ( Sonic Evaluation Kit ( Service-Oriented Architecture ( Progress eLearning Community: XML Essentials, XSLT Essentials SOAP for OpenEdge Developers WSDL for OpenEdge Developers Consuming Web Services from OpenEdge OpenEdge Development with Sonic ESB INT-4: Introducing Sonic ESB

Relevant Exchange Sessions
INT-3: Realistic Service Oriented Architecture Approaches Michael Boyd – Monday (11th 2:00pm (recorded) SONIC-5: Global Approach to SOA Enabled by Sonic ESB Stephen Davies – Tuesday (12th 8:00am INT-5: Integrate over the Web with OpenEdge Web Services Matt Harrison – Tuesday (12th 8:00am SONIC-8: Extend Your ESB with SOA Management David Millman – Tuesday (12th 2:00pm INT-8: Implementing ESB Processes with OpenEdge and Sonic Dave Cleary – Tuesday (12th 2:00pm INT-4: Introducing Sonic ESB

Summary SOA is a set of architectural best practices designed to decouple business applications and improve interoperability in a heterogeneous environment The Sonic ESB combined with OpenEdge gives you a path to integration of business applications in a SOA The ESB provides an infrastructure that allows an incremental approach to SOA adoption that is designed to scale as your needs increase INT-4: Introducing Sonic ESB

Questions? INT-4: Introducing Sonic ESB

INT-4: Introducing Sonic ESB

INT-4: Introducing Sonic ESB®

Similar presentations

Presentation on theme: "INT-4: Introducing Sonic ESB®"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

INT-4: Introducing Sonic ESB®

Similar presentations

Presentation on theme: "INT-4: Introducing Sonic ESB®"— Presentation transcript:

Similar presentations

About project

Feedback