Commerce Server 2007: B2B Solution Development Overview (Series Post #2)

Designing and developing a B2B E-Commerce solution using Commerce Server 2007 and BizTalk Server 2006 and the new Commerce Server BizTalk Adapters can be fairly complex but there are a few best practices which can simplify this process. This may sound a little radical if you've never developed this type of solution before but I recommend beginning your Commerce Server development efforts with the BizTalk applications that your solution will use to communicate with the outside world, especially with your ERP system.

 

One of the most exciting new features in Commerce Server 2007 is the addition of four new BizTalk adapters that are specifically designed to make it easier to integrate Commerce Server data with other layer-of-business (LOB) systems using BizTalk Server 2006. These four adapters are designed to work with the Orders, Catalog, Inventory and Profiles subsystems, and allow Commerce Server to perform bi-directional information exchange between any number of different back-end systems. Since the overall goal of any e-commerce solution is to fulfill a customer’s order, having a means to easily integrate the web “front-end” with the ERP system’s “back-end” is vital. These new adapters make it possible to perform all sorts of real-time and near real-time integrations without writing a ton of custom code; and these adapters are not third-party “bolt-ons,” they were designed specifically for integrating with Commerce Server 2007.

As you would expect, the data received from and sent to the Commerce Server adapters is in XML format and like any other BizTalk document instance, it can be processed using all the available BizTalk tools. This includes data transformation (mapping from one schema to another), orchestration and rules engine processing, as well as transportation to external systems by other BizTalk adapters, such as the FILE, SMTP and FTP adapters. This rich functionality now allows for true integration between your Commerce Server web applications and other external systems with a minimum of development effort and cost.

Development Overview

  • Develop your integration schemas, maps, pipelines and orchestrations using BizTalk Server 2006 and the new Commerce Server adapters first. These should include outbound purchase orders, order updates, inventory updates, catalog updates, customer and organization (profile) updates, and any other information you need to exchange with your ERP system. During this work, you're likely to find out what "custom information" (not provided by Commerce Server by default) your ERP system requires to process and fulfill an order.

  • Extend the Commerce Server Orders subsystem to accommodate this "custom information" required to process and fulfill an order. This can be done by extending the Orders and LineItem classes in Commerce Server to add the custom properties and methods your application requires. The online documentation has a very good explanation of how to get started on this.

  • Create your product and inventory catalog schemas adding any "custom information" required to process and fulfill an order. This is done using the Catalog and Inventory Schema Manager tool provided with Commerce Server 2007. Add any required product- or inventory-related custom properties to your schema and test, test, test. Decide how you plan to present your catalogs to users on your site and most of all… KEEP IT SIMPLE!

  • Modify the standard UserObject, Organization and Address profile schemas to include any "custom information" required to process and fulfill an order. You'll find that not all custom information "fits" into the catalog or orders system directly. Some things (such as a customer number from your ERP system) fit into the Profiles subsystem better. So, you'll need to make some profile changes or perhaps add a few new profiles of your own.

  • Go ahead and start writing some site code using the new StarterSite or CSharp.pup as the basis for your Web site. Now that you know all the custom information that your integrated e-commerce system needs to process and fulfill an order, you're ready to begin writing your site code. You already know what an "Order" looks like and what fields your product "Catalog" holds. You also know where to get the "customer number" from your modified Organization profile. All you need to do now is put it all together with your site code.

For more details on using the new Commerce Server BizTalk Adapters, take a look at the article I wrote for Microsoft's TechNet web site last August.

Integrating Commerce Server Orders with BizTalk Server

Technorati Tags: Commerce Server 2007, BizTalk Server 2006

Share this post: Email it! | bookmark it! | digg it! | reddit!| kick it!

Commerce Server 2007: B2B Solution Development Overview (Series Post #2)

Designing and developing a B2B E-Commerce solution using Commerce Server 2007 and BizTalk Server 2006 and the new Commerce Server BizTalk Adapters can be fairly complex but there are a few best practices which can simplify this process. This may sound a little radical if you've never developed this type of solution before but I recommend beginning your Commerce Server development efforts with the BizTalk applications that your solution will use to communicate with the outside world, especially with your ERP system.

 

One of the most exciting new features in Commerce Server 2007 is the addition of four new BizTalk adapters that are specifically designed to make it easier to integrate Commerce Server data with other layer-of-business (LOB) systems using BizTalk Server 2006. These four adapters are designed to work with the Orders, Catalog, Inventory and Profiles subsystems, and allow Commerce Server to perform bi-directional information exchange between any number of different back-end systems. Since the overall goal of any e-commerce solution is to fulfill a customer’s order, having a means to easily integrate the web “front-end” with the ERP system’s “back-end” is vital. These new adapters make it possible to perform all sorts of real-time and near real-time integrations without writing a ton of custom code; and these adapters are not third-party “bolt-ons,” they were designed specifically for integrating with Commerce Server 2007.

As you would expect, the data received from and sent to the Commerce Server adapters is in XML format and like any other BizTalk document instance, it can be processed using all the available BizTalk tools. This includes data transformation (mapping from one schema to another), orchestration and rules engine processing, as well as transportation to external systems by other BizTalk adapters, such as the FILE, SMTP and FTP adapters. This rich functionality now allows for true integration between your Commerce Server web applications and other external systems with a minimum of development effort and cost.

Development Overview

  • Develop your integration schemas, maps, pipelines and orchestrations using BizTalk Server 2006 and the new Commerce Server adapters first. These should include outbound purchase orders, order updates, inventory updates, catalog updates, customer and organization (profile) updates, and any other information you need to exchange with your ERP system. During this work, you're likely to find out what "custom information" (not provided by Commerce Server by default) your ERP system requires to process and fulfill an order.

  • Extend the Commerce Server Orders subsystem to accommodate this "custom information" required to process and fulfill an order. This can be done by extending the Orders and LineItem classes in Commerce Server to add the custom properties and methods your application requires. The online documentation has a very good explanation of how to get started on this.

  • Create your product and inventory catalog schemas adding any "custom information" required to process and fulfill an order. This is done using the Catalog and Inventory Schema Manager tool provided with Commerce Server 2007. Add any required product- or inventory-related custom properties to your schema and test, test, test. Decide how you plan to present your catalogs to users on your site and most of all… KEEP IT SIMPLE!

  • Modify the standard UserObject, Organization and Address profile schemas to include any "custom information" required to process and fulfill an order. You'll find that not all custom information "fits" into the catalog or orders system directly. Some things (such as a customer number from your ERP system) fit into the Profiles subsystem better. So, you'll need to make some profile changes or perhaps add a few new profiles of your own.

  • Go ahead and start writing some site code using the new StarterSite or CSharp.pup as the basis for your Web site. Now that you know all the custom information that your integrated e-commerce system needs to process and fulfill an order, you're ready to begin writing your site code. You already know what an "Order" looks like and what fields your product "Catalog" holds. You also know where to get the "customer number" from your modified Organization profile. All you need to do now is put it all together with your site code.

For more details on using the new Commerce Server BizTalk Adapters, take a look at the article I wrote for Microsoft's TechNet web site last August.

Integrating Commerce Server Orders with BizTalk Server

Technorati Tags: Commerce Server 2007, BizTalk Server 2006

BizTalk Server 2006 Documentation in PDF Format

We have published an update to the BizTalk Server 2006 core documentation PDF here. Here are some of the juicy details:



  • The PDF is in a self-extracting zip and weighs in at about 55 megs.

  • When extracted, the PDF is about 120 megs.

  • The PDF contains almost 20,000 pages.

  • Links are highlighted in blue but are not active. Enabling links is a potential future enhancement.

  • Searching a document this size takes time.

Again, this is a single PDF file containing all of the BizTalk Server documentation. If you prefer a more granular approach, please post your thoughts.

WCF Adapter Content Forthcoming!


Thanks to my co-worker and good friend PM Sonu Arora, I will begin posting content on the WCF LOB Adapter SDK on this site. For more information on this SDK and very useful programming information, add a link to her blog at http://blogs.msdn.com/sonuarora/


 


 


The Windows Communication Foundation (WCF) Line-of-Business (LOB) Adapter SDK is a collection of runtime engine and tools to help Adapter Developers in creating service-oriented interfaces to existing LOB applications using WCF.  The goal of the WCF LOB Adapter SDK is to facilitate uniform development of reusable metadata-oriented WCF-based adapters that enable enterprise applications, databases and messaging platforms to integrate with each other.  The Adapter SDK is based on WCF and it surfaces an adapter to a LOB application as a WCF Binding. 


 


Relationship with BizTalk Server


BizTalk Server ships with BizTalk Adapter Framework which promotes creating custom adapters for use within BizTalk Server.  BizTalk adapters use the BizTalk Server Administration Console for adapter management, BizTalk Explorer for adapter configuration, and the Adapter Framework for design-time APIs.  WCF LOB Adapter SDK is the evolution of BizTalk Adapter Framework.  Since WCF LOB Adapter SDK is based on new architecture, the adapters built to Adapter SDK will continue to co-exist side-by-side with the adapter written using BizTalk Adapter Framework.    Microsoft and Microsoft’s Technology Partners have built adapters using BizTalk Adapter Framework.  The future direction recommended by Microsoft is to start using WCF LOB Adapter SDK for building new adapters. 


 


Relationship with WCF


The Adapter SDK is based on WCF.  It is exposed as a WCF Binding and implements WCF System.ServiceModel.Channels.TransportBindingElement for handling communication between a client and a service.  It extends WCF with metadata browse, search and resolve interfaces for Adapter Consumer to selectively compose the Service Description contract.  The Adapter SDK enables Adapter Developers to easily create WCF binding(s) and channel(s) for layering existing applications with service-oriented interfaces.  


Adapters differ from regular WCF transports due to these main characteristics:


          Adapters are metadata-centric


o   Require metadata at run-time


o   Require metadata cache management


o   To provide rich metadata at design-time they require search/browse/resolve protocol


          Adapters are always connection-oriented


o   Connection is very central concept for the adapter


o   Require connection pooling and connection life-cycle management


          Adapters are effectively “in-proc WCF Services”


Consuming an adapter is no different than consuming a WCF Service from the perspective of a WCF client and the adapter consumer is not required to learn a new programming model.  The client can use either the WCF Service Programming Model or WCF Channel Architecture to communicate with an adapter.


A typical WCF service programming lifecycle begins by a Service Provider defining a static service contract, implementing this contract and hosting the service.  Each service is defined entirely by a fixed monolithic contract.   This contract needs to be updated by the service provider in order to reflect any changes in the existing application. The Adapter built using WCF LOB Adapter SDK, on the other hand, surfaces the contracts on-demand by consumer.   The consumer browses through the available metadata in the adapter using the standard interfaces and then selects the operations and types for inclusion in a dynamic contract.    The metadata can be updated when the existing application change providing up-to-date interfaces for the new clients.  Adapters are more appropriate in scenarios where a non-WCF based system is being exposed for integration.


For an Adapter Consumer, the adapter can be accessed like a typical WCF Service and the consumer doesn’t have to learn a new programming model.  The same adapter developed using the Adapter SDK can be reused in multiple .NET applications including Custom WCF Client Applications, BizTalk Server, SharePoint Server and SQL Server Integration Services.  In addition, Adapter SDK provides a common facility for Adapter Developers to expose rich LOB metadata to the Adapter Consumers, who can selectively compose and create dynamic WCF contracts from this available metadata in the adapter.


 


Goals


Here are three main goals of the WCF LOB Adapter SDK


1.       Uniformity



  • No unified adapter development framework for .NET

  • Every “integration technology” implements its own adapter framework

  • Provides an abstraction layer between service oriented world and proprietary application interfaces

2.       Reusability



  • Adapters written using BizTalk adapter framework specific to BizTalk

  • Duplication of effort – e.g. at least 5 SAP adapters in Microsoft

  • Surfaces adapter as a WCF binding, widening reach

3.       Consumer-Driven Dynamic Contracts



  • Provides interfaces for browsing, searching and resolving metadata

  • Provides a service-tier that reflects changes in the existing application type model

  • Extends WCF to provide an ability to generate dynamic contracts (service description) from available metadata

 

MOSS: How to: Add Actions to the User Interface

I ran across this great article if you’re looking embark on customising your Sharepoint
2007 menus…from Site Settings through to drop down Actions menus, then here is a
great MSDN article to start.

http://msdn2.microsoft.com/en-us/library/ms473643.aspx

— snip —

How to: Add Actions to the User Interface 

Using Features makes it easy to add actions to menus of the user interface in Windows
SharePoint Services. This example shows how to add actions to various menus through
a Feature and how to activate it within the deployment.

Location and Group ID

To define a custom action for a particular menu, you must identify the menu by setting
the location to the appropriate Windows SharePoint Services namespace, and by using
the ID that Windows SharePoint Services uses to identify the specific location.

For example, to add a custom action to the Site Settings page, set the Location attribute
of the CustomAction element
to Microsoft.SharePoint.SiteSettings.and specify a particular area within the
page through the GroupId attribute.

The following table shows Location and GroupId values that are possible.

Area

Location

GroupId

Display form
toolbar

DisplayFormToolbar

n/a

Edit form toolbar

EditFormToolbar

n/a

New form toolbar

NewFormToolbar

n/a

List view toolbar

ViewToolbar

n/a

Edit control
block menu (per item)

EditControlBlock

n/a

New menu for
list and document library view toolbars

Microsoft.SharePoint.StandardMenu

NewMenu

Actions menu
for list and document library view toolbars

Microsoft.SharePoint.StandardMenu

ActionsMenu

Settings menu
for list and document library view toolbars

Microsoft.SharePoint.StandardMenu

SettingsMenu

Upload documents
menu for document libraries

Microsoft.SharePoint.StandardMenu

UploadMenu

Site Actions
menu

Microsoft.SharePoint.StandardMenu

SiteActions

Site Settings
Site Collection Administration links

Microsoft.SharePoint.SiteSettings

SiteCollectionAdmin

Site Settings
Site Administration links

Microsoft.SharePoint.SiteSettings

SiteAdministration

Site Settings
Galleries Links

Microsoft.SharePoint.SiteSettings

Galleries

Site Settings
Look and Feel links

Microsoft.SharePoint.SiteSettings

Customization

Site Settings
Users and Permissions links

Microsoft.SharePoint.SiteSettings

UsersAndPermissions

Site Actions
menu for surveys

Microsoft.SharePoint.StandardMenu


Different actions may require using different CustomAction attributes to identify
the menu in which to place a custom menu item. But you may also need to specify other
parameters for the action, for example, to specify a version, user permissions required
to perform the action, or placement in relation to existing actions in the menu. The
custom actions of the following example show a variety of attributes.

URL Tokens

Windows SharePoint Services supports the following tokens with which to start a relative
URL:

~site – Web site (SPWeb)
relative link.

~sitecollection – site collection (SPSite)
relative link.

In addition, you can use the following tokens within a URL:

{ItemId} – Integer ID that represents the item within a list.

{ItemUrl} – URL of the item being acted upon. Only work for documents in libraries.
[Not functional in Beta 2]

{ListId} – GUID that represents the list.

{SiteUrl} – URL of the Web site (SPWeb).

{RecurrenceId} – Recurrence index.

Procedures

To add actions to the user interface in a site collection
  1. Create a UserInterfaceLightUp folder within the setup directory at the following
    location: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES.

  2. Create a Feature.xml file in the new UserInterfaceLightUp folder to provide the manifest
    for the feature, such as the following.

    Copy
    Code

    <?xml version="1.0" encoding="utf-8" ?>
    <Feature Id="GUID" 
        Title="Light Up"
        Description="This example shows how you can light up various areas inside Windows SharePoint Services."
        Version="1.0.0.0"
        Scope="Site"
        xmlns="http://schemas.microsoft.com/sharepoint/">
      <ElementManifests>
        <ElementManifest Location="Lightup.xml" />
      </ElementManifests>
    </Feature>
  3. To replace the GUID placeholder in the previous Id attribute, generate a GUID by running
    guidgen.exe located in the Local_Drive:\Program Files\Microsoft Visual Studio
    8\Common7\Tools
    directory.

  4. Create a Lightup.xml file to define elements for the various actions included within
    the feature. For the sake of example, the URL for each action points to an .aspx file
    and passes it a value that identifies the source of the request, as follows:

    Copy
    Code

    <?xml version="1.0" encoding="utf-8" ?>
    <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <!-- Document Library Toolbar New Menu Dropdown -->
      <CustomAction Id="UserInterfaceLightUp.DocLibNewToolbar"
        RegistrationType="List"
        RegistrationId="101"
        GroupId="NewMenu"
        Rights="ManagePermissions"
        Location="Microsoft.SharePoint.StandardMenu"
        Sequence="1000"
        Title="MY DOCLIB NEW MENU TOOLBAR BUTTON">
        <UrlAction Url="/_layouts/LightupHello.aspx?NewMenu"/>
      </CustomAction>
    <!-- Document Library Toolbar Upload Menu Dropdown -->
      <CustomAction Id="UserInterfaceLightUp.DocLibUploadToolbar"
        RegistrationType="List"
        RegistrationId="101"
        GroupId="UploadMenu"
        Rights="ManagePermissions"
        Location="Microsoft.SharePoint.StandardMenu"
        Sequence="1000"
        Title="MY DOCLIB UPLOAD MENU TOOLBAR BUTTON">
        <UrlAction Url="/_layouts/LightupHello.aspx?UploadMenu"/>
      </CustomAction>
    <!-- Document Library Toolbar Actions Menu Dropdown -->
      <CustomAction Id="UserInterfaceLightUp.DocLibActionsToolbar"
        RegistrationType="List"
        RegistrationId="101"
        GroupId="ActionsMenu"
        Location="Microsoft.SharePoint.StandardMenu"
        Sequence="1000"
        Title="MY DOCLIB ACTIONS MENU TOOLBAR BUTTON">
        <UrlAction Url="/_layouts/LightupHello.aspx?ActionsMenu"/>
    </CustomAction>
    <!-- Document Library Toolbar Settings Menu Dropdown -->
      <CustomAction Id="UserInterfaceLightUp.DocLibSettingsToolbar"
        RegistrationType="List"
        RegistrationId="101"
        GroupId="SettingsMenu"
        Location="Microsoft.SharePoint.StandardMenu"
        Sequence="1000"
        Title="MY DOCLIB SETTINGS MENU TOOLBAR BUTTON">
        <UrlAction Url="/_layouts/LightupHello.aspx?SettingsMenu"/>
      </CustomAction>
    <!-- Site Actions Dropdown -->
      <CustomAction Id="UserInterfaceLightUp.SiteActionsToolbar"
        GroupId="SiteActions"
        Location="Microsoft.SharePoint.StandardMenu"
        Sequence="1000"
        Title="MY SITE ACTIONS BUTTON">
        <UrlAction Url="/_layouts/LightupHello.aspx?SiteActions"/>
      </CustomAction>
    <!-- Per Item Dropdown (ECB)-->
      <CustomAction 
        Id="UserInterfaceLightUp.ECBItemToolbar"
        RegistrationType="List"
        RegistrationId="101"
        Type="ECBItem" 
        Location="EditControlBlock"
        Sequence="106"
        Title="MY ECB ITEM">
        <UrlAction Url="/_layouts/LightupHello.aspx?ECBItem"/>
      </CustomAction>
    <!-- Display Form Toolbar -->
      <CustomAction 
        Id="UserInterfaceLightUp.DisplayFormToolbar"
        RegistrationType="List"
        RegistrationId="101"
        Location="DisplayFormToolbar"
        Sequence="106"
        Title="MY DISPLAY FORM TOOLBAR">
        <UrlAction Url="/_layouts/LightupHello.aspx?DisplayFormToolbar"/>
      </CustomAction>
    <!-- Edit Form Toolbar -->
      <CustomAction 
        Id="UserInterfaceLightUp.EditFormToolbar"
        RegistrationType="List"
        RegistrationId="101"
        Location="EditFormToolbar"
        Sequence="106"
        Title="MY EDIT FORM TOOLBAR">
        <UrlAction Url="/_layouts/LightupHello.aspx?EditFormToolbar"/>
      </CustomAction>
    <!-- Site Settings -->
      <CustomAction 
        Id="UserInterfaceLightUp.SiteSettings"
        GroupId="Customization"
        Location="Microsoft.SharePoint.SiteSettings"
        Sequence="106"
        Title="MY SITE SETTINGS LINK">
        <UrlAction Url="/_layouts/LightupHello.aspx?Customization"/>
      </CustomAction>
    <!-- Content Type Settings -->
      <CustomAction 
        Id="UserInterfaceLightUp.ContentTypeSettings"
        GroupId="General"
        Location="Microsoft.SharePoint.ContentTypeSettings"
        Sequence="106"
        Title="MY CONTENT TYPE SETTINGS LINK">
        <UrlAction Url="/_layouts/LightupHello.aspx?General"/>
      </CustomAction>
    </Elements>

    Other common GroupId values that can be used include ViewToolbar, ViewSelectorMenu,
    and PersonalActions (Welcome menu)

  5. Add a LightupHello.aspx file such as the following in the \TEMPLATE\LAYOUTS directory
    to serve as target for the links created in the previous step.

    Copy
    Code

    <%@ Page Language="C#"  Inherits="System.Web.UI.Page"%>
    <%
    string clientQuery = Page.ClientQueryString;
    if (clientQuery == "NewMenu")
    {
        Response.Write("You came from the new document menu.");
    }
    else if (clientQuery == "UploadMenu")
    {
        Response.Write("You came from the upload menu.");
    }
    else if (clientQuery == "ActionsMenu")
    {
        Response.Write("You came from the actions menu.");
    }
    else if (clientQuery == "SettingsMenu")
    {
        Response.Write("You came from the settings menu.");
    }
    else if (clientQuery == "SiteActions")
    {
        Response.Write("You came from the Site Actions menu.");
    }
    else if (clientQuery == "ECBItem")
    {
        Response.Write("You came from the document's context menu.");
    }
    else if (clientQuery == "DisplayFormToolbar")
    {
        Response.Write("You came from the display item properties form.");
    }
    else if (clientQuery == "EditFormToolbar")
    {
        Response.Write("You came from the edit item properties form.");
    }
    else if (clientQuery == "Customization")
    {
        Response.Write("You came from the Site Settings menu.");
    }
    else if (clientQuery.StartsWith("General"))
    {
        Response.Write("You came from the Content Type Settings menu.");
    }
    %>
  6. At a command prompt, type the following commands to install the Feature in the deployment,
    activate the Feature on a specified subsite, and then reset Microsoft Internet Information
    Services (IIS) so that the changes can take effect.

    Copy
    Code

       a. stsadm -o installfeature -filename UserInterfaceLightUp\feature.xml
       b. stsadm -o activatefeature -filename UserInterfaceLightUp\feature.xml -url http://Server/Site/Subsite
       c. iisreset
  7. To see the various custom actions that you have added, navigate to the following locations
    from the home page of a Web site in the site collection:

    1. Click Site Actions to see the new action on the Site Actions menu.

    2. Click Site Settings on the Site Actions menu to see a new action in
      the Look and Feel section of the Site Settings page.

    3. Navigate to a document library and open each menu on the toolbar to see a new action
      on each menu.

    4. In a document library that contains items, click the down arrow for an item to see
      the new action on the edit control block menu.

    5. On the edit control block menu for an item, click View Properties and Edit
      Properties
      to see new actions on the Display form and Edit form toolbars.

WCF Adapter Content Forthcoming!


Thanks to my co-worker and good friend PM Sonu Arora, I will begin posting content on the WCF LOB Adapter SDK on this site. For more information on this SDK and very useful programming information, add a link to her blog at http://blogs.msdn.com/sonuarora/


 


 


The Windows Communication Foundation (WCF) Line-of-Business (LOB) Adapter SDK is a collection of runtime engine and tools to help Adapter Developers in creating service-oriented interfaces to existing LOB applications using WCF.  The goal of the WCF LOB Adapter SDK is to facilitate uniform development of reusable metadata-oriented WCF-based adapters that enable enterprise applications, databases and messaging platforms to integrate with each other.  The Adapter SDK is based on WCF and it surfaces an adapter to a LOB application as a WCF Binding. 


 


Relationship with BizTalk Server


BizTalk Server ships with BizTalk Adapter Framework which promotes creating custom adapters for use within BizTalk Server.  BizTalk adapters use the BizTalk Server Administration Console for adapter management, BizTalk Explorer for adapter configuration, and the Adapter Framework for design-time APIs.  WCF LOB Adapter SDK is the evolution of BizTalk Adapter Framework.  Since WCF LOB Adapter SDK is based on new architecture, the adapters built to Adapter SDK will continue to co-exist side-by-side with the adapter written using BizTalk Adapter Framework.    Microsoft and Microsoft’s Technology Partners have built adapters using BizTalk Adapter Framework.  The future direction recommended by Microsoft is to start using WCF LOB Adapter SDK for building new adapters. 


 


Relationship with WCF


The Adapter SDK is based on WCF.  It is exposed as a WCF Binding and implements WCF System.ServiceModel.Channels.TransportBindingElement for handling communication between a client and a service.  It extends WCF with metadata browse, search and resolve interfaces for Adapter Consumer to selectively compose the Service Description contract.  The Adapter SDK enables Adapter Developers to easily create WCF binding(s) and channel(s) for layering existing applications with service-oriented interfaces.  


Adapters differ from regular WCF transports due to these main characteristics:


          Adapters are metadata-centric


o   Require metadata at run-time


o   Require metadata cache management


o   To provide rich metadata at design-time they require search/browse/resolve protocol


          Adapters are always connection-oriented


o   Connection is very central concept for the adapter


o   Require connection pooling and connection life-cycle management


          Adapters are effectively “in-proc WCF Services”


Consuming an adapter is no different than consuming a WCF Service from the perspective of a WCF client and the adapter consumer is not required to learn a new programming model.  The client can use either the WCF Service Programming Model or WCF Channel Architecture to communicate with an adapter.


A typical WCF service programming lifecycle begins by a Service Provider defining a static service contract, implementing this contract and hosting the service.  Each service is defined entirely by a fixed monolithic contract.   This contract needs to be updated by the service provider in order to reflect any changes in the existing application. The Adapter built using WCF LOB Adapter SDK, on the other hand, surfaces the contracts on-demand by consumer.   The consumer browses through the available metadata in the adapter using the standard interfaces and then selects the operations and types for inclusion in a dynamic contract.    The metadata can be updated when the existing application change providing up-to-date interfaces for the new clients.  Adapters are more appropriate in scenarios where a non-WCF based system is being exposed for integration.


For an Adapter Consumer, the adapter can be accessed like a typical WCF Service and the consumer doesn’t have to learn a new programming model.  The same adapter developed using the Adapter SDK can be reused in multiple .NET applications including Custom WCF Client Applications, BizTalk Server, SharePoint Server and SQL Server Integration Services.  In addition, Adapter SDK provides a common facility for Adapter Developers to expose rich LOB metadata to the Adapter Consumers, who can selectively compose and create dynamic WCF contracts from this available metadata in the adapter.


 


Goals


Here are three main goals of the WCF LOB Adapter SDK


1.       Uniformity



  • No unified adapter development framework for .NET

  • Every “integration technology” implements its own adapter framework

  • Provides an abstraction layer between service oriented world and proprietary application interfaces

2.       Reusability



  • Adapters written using BizTalk adapter framework specific to BizTalk

  • Duplication of effort – e.g. at least 5 SAP adapters in Microsoft

  • Surfaces adapter as a WCF binding, widening reach

3.       Consumer-Driven Dynamic Contracts



  • Provides interfaces for browsing, searching and resolving metadata

  • Provides a service-tier that reflects changes in the existing application type model

  • Extends WCF to provide an ability to generate dynamic contracts (service description) from available metadata