9
Conceptual Architectural Problem Point-to-PointHub and Spoke (BizTalk) Message Bus Time to DeliveryHigh: 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 ConsistencyNoneLittle/None: Some across Microsoft adapters; next to none with ISV adapters Little/None: none across LOB and 3 rd party adapters; service containers only as consistent as dev who wrote them ScalabilityPoor: scale outward, not upward Good: scales upward and outward, but cost prohibitive Excellent: scale upward and outward and can minimize cost ManageabilityPoor: depends on host capabilities Mid: heavily tied to WMI, and involves a lot of planning Mid: depends on how its implemented

10
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

11
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

13
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

14
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”

25
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

30
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”

33
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