Transcript Microsoft BizTalk Server 2006 R2

Microsoft BizTalk Server
2006 R2
The Features, The Framework and
The Future
Agenda
•
•
•
•
•
•
•
•
•
BizTalk R2 Features (WinFX and BPM Tools)
What an Adapter provides
Why the R2 LOB Adapter SDK exists
Architecture
Benefits
The LOB Adapter SDK vs WCF
The LOB Adapter SDK and the BizTalk Roadmap
Demos
Q&A
R2 Goals and Supporting Features
Support for Composite Applications via
Service-Oriented Architecture
.NET Framework 3.0 Support
LOB Adapter SDK
LOB and WCF Adapters
BAM monitoring of WF workflows
and WCF services
Support for End-to-End B2B Processes
Native EDI engine
X12, EDIFACT, AS2 support
B2B Standards Support
HIPAA, HL7, SWIFT, RosettaNet
Global Supply-chain Collaboration
GXS partnership
Support for People-Ready Processes
BizTalk LOB Adapters
Office SharePoint Server 2007
Integration
Partner BPM Solutions
Modeling, simulation, rules
Support for End-to-End RFID Processes
Device Abstraction and Management Tools
Event Filters, Alerts and Transforms
API: Design, Runtime, Management
Back-office Integration
BPM Tools in R2
• ESB Guidance toolkit
–
–
–
–
–
–
Exception handling
Management portal for ESBs
Core ESB namespacing, APIs, and code samples
Web and WCF services for endpointing
Enveloping (itineraries)
Code for writing on and off ramps
• Software as a Service (SaaS) support
• SOA-enabling tools
– Federated processes across trading partners and
devices
Microsoft BizTalk Server
2006 R2
LOB Adapter SDK
(formerly Adapter Framework)
Common Adapter Functionality
• Connectivity
– Physical connectivity to target system
• Metadata
– Harvest metadata from target system
– Search, Browse, Resolve metadata
• Message Exchange Flow
– Implement Handlers for supported Message Exchange patterns like
Outbound, Inbound etc.
• Other
– Transaction bridging, Ordered delivery etc
Evolution of Architectures
Point-to-Point
Hub and Spoke
Message Bus
unmanaged / decentralized
managed / centralized
managed / decentralized
Suitable for small
environments
Supports loose coupling
of systems
Common communication
infrastructure
n² lines of connectivity
Message Broker
No unification
n lines of connectivity
Common command
infrastructure
Difficult to manage
Centralized management
Highly-coupled
Limited scalability
Single point of failure
n lines of connectivity
Proprietary
communication protocols
Complex management
Hybrid Hub/Bus Architecture
Processing Hosts
Receive Hosts
Send Hosts
Outbound
Inbound
Network Load Balancer
MsgBox 1
Monitoring BizTalk Server
(MOM)
Admin Host
BizTalk
Mgmt DB
MsgBox 2
Cluster
Tracking
DB
MsgBox 3
Cluster
BizTalk Server
Tracking Host
Cluster
SAN
Data
Indexes
Logs
Data
Indexes
Logs
Conceptual Architectural Problem
Point-to-Point
Hub and Spoke
(BizTalk)
Message Bus
Time to Delivery
High: each host
has custom logic
Mid to Low: As most
are pre-written, time is
spent to use adapters
High: most time is spent
writing code to get on the bus
(create adapter endpoints and
service containers)
Architectural
Design Footprint
Large: hosts are
tightly-coupled
Large: messaging
engine and adapters
are tightly-coupled
Small: distributed message bus
and distributed integration
capabilities
Consistency
None
Little/None: Some
across Microsoft
adapters; next to none
with ISV adapters
Little/None: none across LOB
and 3rd party adapters; service
containers only as consistent
as dev who wrote them
Scalability
Poor: scale
outward, not
upward
Good: scales upward
and outward, but cost
prohibitive
Excellent: scale upward and
outward and can minimize cost
Manageability
Poor: depends on
host capabilities
Mid: heavily tied to
WMI, and involves a lot
of planning
Mid: depends on how its
implemented
Technical Problem
• No unified framework on which to develop
adapters in .NET
• Today’s adapters are specific to the consuming
host
– Too many (different) adapters
– A lot of redundant functionality
Solution
• Provide a framework for and the
implementation of adapters that are
– High quality (written in WCF, C#, Managed Code)
– Metadata-driven
– Host agnostic
– Customized to the LOB system
– Scalable
– Distributable
Adapter Bindings Architecture
Office Biz Apps
WCF Apps
BizTalk Server
WCF Service Programming Model
MIIS
SQL-SSIS
MIIS Controller
ADO.NET provider
WCF Channel Architecture
WCF HTTP binding
AF Runtime
AF Runtime
AF Runtime
Siebel adapter
SAP adapter
My adapter
WCF
Web Service
Siebel
SAP
My System
Architectural Benefits
• Enables surfacing multiple programming models (i.e. WCF
channel, ADO.NET, Service Model Programming)
• Enables exposing a Web Service face to the system being
adapted automatically (via the Adapter host)
• WCF channel architecture extensibility points enable easy
customization of Adapter behavior
• Development Tools
– AF ships with a rich set of development tools to automate and simplify
much of the coding required for Adapter development
– Consistent deployment and administration experience
Adapters and WCF
If Adapter consumption is identical to WCF Service
consumption then when does one write an Adapter
and when does one write a vanilla WCF Service to
expose existing systems for integration?
– Adapters are appropriate when it is impractical to capture the
target system’s functionality in a static monolithic contract,
i.e.,
• The metadata of the system is “dynamic” i.e., new functions can get
added, e.g., Oracle stored procs
• There is a lot of metadata e.g., SAP
– WCF service is more appropriate when the target system
metadata is more or less “static” and “small”
Adapter vs. WCF Services
Fixed Service Contract
Dynamic Composable Contract(s))
Large
Metadata
Adapter
Contract1
Contract2
LOB
WCF Service
The Service
Contract
Contract3
Contract n
Demo: Adapter Service Reference
Adapter Architecture
Adapter
Handler
Connection
Connection
Management
Metadata Handler
Channels Implementation
URI Builder
Connection
Factory
Credentials
Extractor
LOB
Metadata Driven
XML reader/writer
Metadata Management
Implemented
by
WSDL
Builder
Metadata
Browse / Search
AF
Developer
AF Artifacts
• Code Generation Wizard
• OM for components to be implemented
by developer
• Common Metadata Search/Browse
UI component
• BizTalk design time
integration components
Demo: Code Generation Wizard
Object Model Overview
Required
Adapter
Connection
Factory
Optional
Metadata
Resolver
Handler
Connection
Inbound
Handler
Metadata
Search
Handler
Outbound
Handler
Metadata
Browse
Handler
Custom
Operation
Metadata
Type
Metadata
Inbound
Message
XML Reader
Outbound
Message
XML Writer
Transaction
Bridging
Session
Correlation
In-order
Delivery
Guaranteed
Delivery
Only in Beta1, will be implemented by AF in Beta2
Consuming Adapters
• Identical to consuming WCF bindings
• Adapters can be consumed via
– WCF Channel programming model
– WCF Service Programming Model
• The WCF Adapter shipping in the R2 box enables
consumption of all WCF services and bindings
• Send/Receive ports should be configured with
WCF-CustomAdapter with the associated binding
pointing to the specific Adapter binding
Demo: Consuming an Adapter
Connectivity Design
Outbound
Handler
Inbound
Handler
Adapter
Connection
Factory
Connection
LOB
Metadata
Resolver
Handler
Metadata
Browse/Search
Handler
Creating Connectivity
• Implement the Connection Factory
– Establishes connection pool based on URI, user
credentials
• Implement Connection
– Defines low-level communication contract with the
target system
– Encapsulates native communication APIs and/or
connection handles
• Implement Handler(s)
– Defines the message exchange pattern(s)
supported by the adapter
Handlers
•
Outbound Handler
– To support One-Way Send or Request/Response patterns
•
Asynchronous Outbound Handler
– Async flavor of the above.
•
Inbound Handler
– To support One-Way Receive or Reply patterns
•
Metadata Resolver Handler
– To expose metadata governing the execution of target system logic
•
Metadata Search Handler
– To search for metadata in systems where unfiltered metadata is
too large or unwieldy
•
Metadata Browse Handler
– To browse for metadata in systems with large metadata where some meaningful
categorization is possible
Steps To Implement Metadata Support
• Implement calls to any native metadata harvesting
APIs for target system
• Implement OperationMetadata objects and
TypeMetadata objects for methods and
types harvested
– Each distinct programming model supported by the target
system needs an OperationMetadata class e.g., COM
programming model access, Win32 library etc.,
• Implement search, browse methods for metadata if
appropriate
Metadata Services Provided In The AF
• Encapsulation
– Enables OO representation of target system metadata
– OperationMetadata & TypeMetadata are key base classes
• Caching
– Internal in-memory cache for metadata
• WSDL Generation
– Automatic WSDL generation from OO metadata model (can
be overridden for scenarios requiring custom WSDL
generation)
Timing Diagram-Design Time
WCF Client / svcutil
AF channel impl
Metadata Handler
Wsdl Builder
Metadata Mgmt
Connection Mgmt
ConnectionFactory
Connection
MDResolverHandler
Message
Message (MEX)
Get WSDL()
GetOperationMD()
Handler
{Uses pool/
Connection Builder}
{Use Metadata Mgmt to get all
operations and complex types Metadata}
BuildHandler<T>()
BuildConnection
()
Connection
BuildHandler<T>()
Handler
ResolveOperationMD()
LOB Call()
Data
OperationMD
Operation MD
GetTypeMD()
ResolveTypeMD()
LOB Call
Data
TypeMD
Type MD
Build Wsdl
Wsdl
Build Reply
MEX reply
Reply
LOB
Timing Diagram-Run Time
WCF Client
AF channel impl
Connection Mgmt
ConnectionFactory
Connection
OutboundHandler
Metadata Mgmt
MD Resolver Handler
Build Ch Factory
Create Request Channel
Open()
{Uses pool/
Connection Builder}
GetHandler<T>()
BuildConnection()
Connection
BuildHandler<T>()
Handler
Handler
Request(Message)
Execute(Message)
Get OperationMD / TypeMD
BuildHandler<T>()
BuildHandler<T>()
Handler
Handler
{Write Message
Using XMLWriter}
Resolve OperationMD / TypeMD
LOB Call
Data
OperationMD / TypeMD
OperationMD / TypeMD
LOB Call
Data
{Create Message
Using XMLReader}
Get TypeMD
Message
Message
Resolve TypeMD
LOB Call
Data
TypeMD
TypeMD
LOB
How Do Adapters Differ From WCF
Transport Bindings?
• Adapters differ from regular WCF transport bindings
in the following ways
– Adapters are Metadata Centric
• Require metadata at run time
• Require metadata cache mgmt
• To provide rich metadata at design time they require filtering
/pruning/search /browse protocol
– Adapters are always Connection Oriented
• The connection is a very central concept for the adapter
• Require connection pooling and life cycle mgmt
• Adapters are effectively “in-proc WCF Services”
Microsoft BizTalk Server
2006 R2
Future Directions
Packaging
• BizTalk 2006 R2 includes separate installs
–
–
–
–
BizTalk 2006 R2 Server
BizTalk 2006 R2 Accelerators
BizTalk WCF LOB Adapters
BizTalk WCF LOB Adapter SDK
• Microsoft plans to offer the WCF LOB Adapter
SDK as a free download
• The .NET Adapters will most likely be sold as a
standalone product or given out to select
customers depending upon licensing agreements
Future Directions
• Microsoft’s officially stated goals for vNext:
– Radical gains in productivity thru advances in
model-driven development and management
– Rich business process modeling and simulation for
the business analyst
– Further advance and integrate the use of
Windows Workflow Foundation
– Continued commoditization of low-level
integration
Future Predictions
BizTalk 2006
BizTalk 2006 R2
BizTalk vNext
Adapters
Adapters & AF
AF 2.0
XLANG
XLANG
Custom WF
Activities / Xml
Itineraries
Communications
Ports
Ports & WCF
WCF
Workflow
HWS
HWS
WF
Transformation
XSLT
XSLT
XLINQ
ADO.NET /
Adapters
ADO.NET /
Adapters
ADO.NET / DLINQ
2.0
3.0 (Partial)
3.5 Complete
Integration
Business Processing
Data Access
.NET Fx Support
Resources
• Questions: [email protected]
• BizTalk Team Server Blog:
http://blogs.msdn.com/biztalk_server_team_
blog
• Microsoft’s site on SOA and ESB guidance:
http://www.microsoft.com/soa
• Beta 2 bits available for download at
http://connect.microsoft.com
Software Development & Integration / Program & Project Management /
Architectural Oversight / Software Integration / Business Process Improvement /
HIPAA / Consulting / Staffing / Knowledge Sharing & Mentoring
Corporate Office
100 West Rd. Ste. 408
Baltimore, MD 21204
Calverton Office
4061 Powder Mill Road, Ste. 700
Calverton, MD 20705
410-583-9393
301-273-2126
[email protected] • www.softwareconsortium.com