by community-syndication | Mar 27, 2007 | BizTalk Community Blogs via Syndication
Good news from W3C, SML and WSDL 2.0 are almost out the door: · The Web Services Description Working Group released three Last Call Working Drafts for the Web Services Description Language (WSDL) Version 2.0: Part 0: Primer , Part 1: Core Language…(read more)
by community-syndication | Mar 27, 2007 | BizTalk Community Blogs via Syndication
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
by community-syndication | Mar 27, 2007 | BizTalk Community Blogs via Syndication
By Jesus Rodriguez This is the first of two articles intended to illustrate Java Messaging Service (JMS)-based Web Services using Oracle Application Server. Specifically, this article focuses on how to achieve JMS .NET interoperability through JMS-based…(read more)
by community-syndication | Mar 27, 2007 | BizTalk Community Blogs via Syndication
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
by community-syndication | Mar 27, 2007 | BizTalk Community Blogs via Syndication
Microsoft released a new version of the core documentation PDF. It comes as one self extracting zip from 55MB.
Although this results in giant one PDF file from 117MB containing almost 20000 pages, I like the fact that it is only one PDF.
Download the documentation here.
by community-syndication | Mar 27, 2007 | BizTalk Community Blogs via Syndication
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.
by community-syndication | Mar 27, 2007 | BizTalk Community Blogs via Syndication
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
by community-syndication | Mar 27, 2007 | BizTalk Community Blogs via Syndication
Do you have a hankerin’ for a 117 meg (55 meg compressed) PDF file containing the full documentation set (almost 20k pages) for BizTalk Server 2006? Hanker no more because it is now available here . Is this too much to digest at one sitting? Let me know…(read more)
by community-syndication | Mar 27, 2007 | BizTalk Community Blogs via Syndication
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
-
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.
-
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>
-
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.
-
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)
-
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.");
}
%>
-
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
-
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:
-
Click Site Actions to see the new action on the Site Actions menu.
-
Click Site Settings on the Site Actions menu to see a new action in
the Look and Feel section of the Site Settings page.
-
Navigate to a document library and open each menu on the toolbar to see a new action
on each menu.
-
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.
-
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.
by community-syndication | Mar 27, 2007 | BizTalk Community Blogs via Syndication
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