ESB Guidance 2.0

Kevin Gockhttp://www.itfocus.co.nz

Agenda

• Enterprise Service Bus (ESB)• ESB Guidance– Itinerary– Dynamic Endpoint Resolution– Web Services– ESB Management Portal

• Demo• Questions?

Definition of ESBImplementation of an infrastructure for enabling a service

oriented architecture (SOA)• Enterprise – Integrate assets of one company• Service – Provides services e.g. Routing, Transformation• Bus – Pluggable messaging endpoints

Think of an ESB as ...

Collection of architectural patterns based on• Traditional enterprise application integration (EAI)• Message-oriented middleware• Web services• .NET and Java interoperability• Host system integration• Interoperability with service registries and asset

repositories

What does an ESB look like?

What is the ESB Guidance?

• Enhancements to BizTalk• Developed by Patterns and Practices Team• Extends BizTalk– Itinerary-based invocation– Dynamic endpoint resolution– Message routing using registry or rules engine– Web Services– Fault Management and Reporting– Integration with 3rd Party SOA Governance Solutions

• Sample Applications

InstallationInstall:• BizTalk ESB Core, Exception Handling packages• Itinerary Designer• ESB Configuration Tool• Documentation• Source Code

Requires:• Windows 2008 • SQL Server 2008• Visual Studio 2008 SP1• Enterprise Library 4.0• Unity Application Block 1.1

Use Microsoft Hyper-V for virtualisation

What is an Itinerary?

• XML defining a sequence of Services to execute

• Sent by a client as a SOAP header along with message

How does an Itinerary work?

1. Client Sends Itinerary and Message (both flow together for each Service executed)

2. ESB Pipeline sets Itinerary values as message context properties3. Itinerary Subscribers:• Orchestration or ESB Agent (name=Transform/Routing)• Filter for specific name, type, state

Why have an Itinerary?

• Makes message highly distributable. • Ability for any ESB container to process the

message

Caller must be changed to pass Itinerary

Dynamic Endpoint Resolution

Allows an Itinerary service endpoint to be resolved, dynamically at runtime.

Supported Resolvers:- UDDI - LDAP- Xpath - BRE- Static

Dynamic Endpoint Resolution Example

• Itinerary – Resolvers XML Fragment:

Processing:1. Transform message using BRE2. Send the Order to– static file location– location resolved by using UDDI search

3. Send the response back to caller

Why use Dynamic Endpoints?

1. Avoid consumers binding directly to a static endpoint. If endpoint changes then the consumer needs to change also.

Example:Orchestration calls static WebServiceA.NET app calls static WebServiceAUDDI would be useful to lower maintenance by

changing the UDDI registry only.

Demo - ESB in Action!

Demo - BRE

• Resolver uses Itinerary’s data (policy=ResolveMap) for BRE to set transform

Demo – STATIC, UDDI

• Itinerary – Resolvers XML Fragment:

• STATIC defines the full location so dynamic resolution doesn’t occur

• UDDI resolves to physical drive location

Creating Itineraries

• Use VS 2008 with the ItineraryDsl project type• Validate and Export to XML

Web Services

• Itinerary On-ramp• Resolver• Transformation• Exception Handling• UDDI• BizTalk Operations

ESB Management Portal Demo

Summary

• Guidance implementing an ESB, best practices and reducing effort

• Loose coupling with Itinerary and Dynamic Endpoint Resolution

• Lots of useful Web Services• Management of the ESB via a Portal (faults, UDDI)• Still in CTP2 so there are outstanding issues• Source code for ESB and samples• Extensible and Free!

Questions?

Thank you!

Kevin Gockhttp://www.itfocus.co.nz