Expose LOB Services on the Cloud Using AppFabric Connect for Services

Article
1/17/2024

[ Please contribute your knowledge and experience to this document. The community within and outside Microsoft regularly evaluates changes and accepts, refines, or reverts them as appropriate. To read the original document, click here. ]

Exposing services on the cloud is a key requirement for creating composite applications that can extend the reach of on-premises applications and services to clients that exist outside an organization’s firewall. AppFabric Connect for Services now enables users to expose their on-premises services on the Azure AppFabric Service Bus via a relay service.

Before we go deeper into details of exposing services on the cloud, and in particular LOB services, let us understand how the space of application and service deployment has evolved given the advent of cloud-related technologies. We can divide the application and service deployment space into two broad categories:

On-premises deployment: An application or service that runs within an organization’s firewall and is typically accessible to only clients that are within the firewall.
On-cloud deployment: An application or service that runs on the cloud and can be accessed by clients within or outside the firewall.

However, there can be a requirement where organizations want to extend their existing on-premises applications or services to the cloud so that the clients outside the organization’s firewall can also access and consume it. Windows Azure AppFabric Service Bus provides the capability to take web services that are accessible only from within an organization and extend their reach to external clients. Azure AppFabric Service Bus provides a relay service that can listen to external clients on behalf of the on-premise web services at a given public address.

While Azure AppFabric Service Bus provides a platform where service owners could expose the relay endpoint for their on-premises service, AppFabric Connect for Services enables service owners to create the relay endpoints in the first place. AppFabric Connect for Services provides an updated WCF Adapter Service Development Wizard (originally shipped with BizTalk Adapter Pack 2010) that enables users to expose operations on their on-premise line of business (LOB) applications as WCF services to external clients via the Service Bus relay service.

Who Should Read This Whitepaper?

This whitepaper is intended for the following users:

Organizations that want to extend the reach of their on-premises LOB applications to cloud by exposing them as WCF services with endpoints in Windows Azure AppFabric Service Bus.
Users that want to consume the service extended to the cloud to perform operations on LOB applications that are deployed inside an organization’s firewall.

This whitepaper assumes familiarity with Azure AppFabric Service Bus, Azure AppFabric Access Control Service (ACS), and Windows Communication Foundation (WCF).

What does the WCF Adapter Service Development Wizard do?

The WCF Adapter Service Development Wizard essentially exposes the operations on LOB applications as WCF services. The wizard enables you to select the operations that you want to expose as services and then creates the following:

An on-premise endpoint for the WCF service.
A Service Bus endpoint for the WCF service.
A Service Bus endpoint for exchanging metadata pertinent to the WCF service.

Security Considerations when Exposing Services on Cloud

Whether an organization uses standard LOB applications or customized legacy applications, the data available through the applications is business-critical data. Security becomes of paramount concern when organizations expose the data, or operations that can be performed on the data, as services outside an organization’s protected environment. To address such concerns, organizations can follow certain security best-practices to ensure that only authenticated clients get access to the service.

Client authentication by Service Bus relay service. All the Service Bus relay bindings expose a binding property, ‘RelayClientAuthenticationType’ that controls whether the client consuming the service is required to present an authentication token to the relay service. This property can be set to either ‘None’ or ‘RelayAccessToken’. If the property is set to ‘RelayAccessToken’, the client must provide an authentication token to the Service Bus. The authentication token must be communicated separately to the client, for example, as an e-mail message by the organization hosting the service. In addition to implementing security, setting ‘RelayClientAuthenticationType’ is also a cost-effective solution for the organization hosting the service. If there is no authentication by the Service Bus, any client would be able to hit the service endpoint even if it is eventually denied by the service. As a result, the organization would incur a chargeback even though there was no business operation that resulted.
Client authentication by the LOB application. Even after a client is authenticated by the Service Bus, it should again authenticate itself with the underlying LOB by passing the user credentials that is authorized to perform operations on the LOB. For example, when writing a WCF console application, you must use the ClientCredentials class to specify the username and password to connect to the LOB.
Message-level and transport-level security. WCF inherently provides message-level and transport-level security for services. For more information on message- and transport-level security, see http://msdn.microsoft.com/en-us/library/ms733137.aspx.

Tip: It’s not essentially a security setting, but organizations can also secure the services hosted on the cloud by not making the endpoints publicly discoverable. Service Bus provides an ATOM feed which lists all the publicly discoverable endpoints under a given Service namespace. Making the endpoints discoverable or not is controlled through a property “EndpointDiscovery”, which can be set using the WCF Adapter Service Development wizard. The disadvantage of not making the endpoints publicly discoverable is that if you have a large number of clients that would be using the service you hosted, you will have to communicate the endpoint URL to each of those clients.

Business Scenario

This whitepaper provides information on how to use the WCF Adapter Service Development Wizard in BizTalk Adapter Pack 2010 to expose operations on the on-premises LOB applications as web services that have a Service Bus relay service on the cloud, listening to external clients. This whitepaper is written around a business scenario to help demonstrate the feature. The scenario is as follows:

An organization, Fabrikam, provides stocks to its employees.
The stocks are managed by a stock brokering firm, Contoso.
The details of the stock holdings are stored in the table, Stock, in a SQL Server database. The SQL Server database is housed within the organization premises, protected by a firewall. The table contains the following fields:

Employee ID	Company Name	Ticker Symbol	Holdings	Price Per Share	Total Value
-	-	-	-	-	-

Contoso wants to provide the employees of Fabrikam (all outside the firewall), the option of retrieving information related to their stock holdings from the SQL Server database table by providing their employee ID and the company name.

The whitepaper describes the procedures Contoso must follow to expose operations on the SQL Server database table as web services via the Service Bus relay service. The whitepaper also provides the procedures on how Fabrikam can write a client application to invoke the service exposed by Contoso.

Prerequisites

Make sure you have the following components installed or configured before you proceed further:

You must have WCF LOB Adapter SDK 2010 installed. This is a prerequisite for installing BizTalk Adapter Pack 2010. You can install it from here (http://go.microsoft.com/fwlink/?LinkId=204208).
- Note: WCF LOB Adapter SDK 2010 can also be installed from BizTalk Server 2010 installation media.

You must have BizTalk Adapter Pack 2010 installed. This can be installed from the BizTalk Server 2010 installation media.
You must have Windows Azure AppFabric SDK version 1.0 (September update or later) installed. You can install it from here (http://go.microsoft.com/fwlink/?LinkId=204209).
You must have registered a service namespace with Azure AppFabric Service Bus. You will require this for hosting the Service Bus relay service on the Azure Service Bus. Instructions on registering the service namespace are available on the Azure AppFabric portal at http://go.microsoft.com/fwlink/?LinkId=204209.
- Note: AppFabric Connect for Services can be used to only register Service Bus endpoints with Windows Azure AppFabric 1.0.

You must have the BizTalk Server 2010 Feature Pack (October 2010) installed. You can download the feature pack from http://go.microsoft.com/fwlink/?LinkId=204701
Recommended: You can also install Windows Server AppFabric. This enables you to make some configuration settings that would otherwise be cumbersome. In addition, Windows Server AppFabric provides rich manageability features. You can download the Windows Server AppFabric installer from here (http://go.microsoft.com/fwlink/?LinkId=204210).
- Important: If you choose to install Windows Server AppFabric, you must also install the hotfix 980423 (http://go.microsoft.com/fwlink/?LinkId=204211). This fixes some issues with Windows Server AppFabric.

Exposing LOB Operations as Services on Cloud

In this section, we will provide step-by-step instructions on how to expose the Select operation on a SQL Server table as a service on the cloud. For ease of understanding, this section is divided into the following categories:

Create the SQL Server table for which you want to expose the Select operation as a service on the cloud.
Create the service to expose operations on the Stocks table.
Prepare IIS for hosting the local endpoint for the service.
Publish the service.
Configure the service to start automatically (only for IIS 7.5).
Verify whether the service is published.

Create the SQL Server Table

As mentioned in the scenario description, Contoso stores all the stock related information in a Stocks table. In this section, we provide you the script to create the Stock table in your SQL Server database. The script also populates the table with a few records. Let us assume that the Stocks table will be created in the ContosoDB database.

Once you have created the table, you are now ready to create the service to expose operations on the Stocks table.

Expose Operations on Tables as Services

As described in the business scenario, Contoso wants to enable its clients to retrieve information from the Stocks table, which means that Contoso must expose the Select operation on the Stocks table (in the ContosoDB database) as a service on the cloud. The following procedure provides information on how to use the WCF Adapter Service Development Wizard for exposing operations on a SQL Server database table as services.

Start Visual Studio 2010 and create a new project.
In the New Project dialog box, from the list of installed templates, click Visual C#. In the right pane, select WCF Adapter Service. For the project name, enter Contoso_Service and then click OK. The WCF Adapter Service Development Wizard is launched.
In the Welcome page, select the checkbox Create WCF Adapter Service for SharePoint client if the service will be consumed by a SharePoint client. If the service will be consumed by any other client, make sure the checkbox is cleared. For the procedure described in this topic, we will create a simple console application to invoke the service. Hence, you must clear the checkbox.
In the Choose Operations page, select the operation that you want to expose as a service on the cloud.
1. From the Select a binding drop-down list, select sqlBinding.
2. In the Configure a URI text box, enter the URI to connect to the SQL Server database, ContosoDB, which contains the Stocks table. A typical URI to connect to the SQL Server is:
  
  mssql://<server_name>/<sql_server_instance>/<my_database>?
  
  Assuming that the ContosoDB database is created on a SQL Server that is running on the same computer where you are running the WCF Adapter Service Development Wizard and that the database is created in the default SQL Server instance, the URI to connect to the SQL Server database will be:
  
  mssql://.//ContosoDB?
  
  For more information on the SQL Server connection URI for the WCF Adapter Service Development wizard, see http://msdn.microsoft.com/en-us/library/dd788089(BTS.10).aspx.
3. Click Connect.
4. From the Select contract type dialog box, select Client (Outbound operations).
5. From the Select a category box, expand the Tables node, and click [dbo].[Stocks].
6. From the Available categories and operations box, click Select, and then click Add. The selected operation is now listed in the Added categories and operations box. The following screenshot shows the selected options and operations.
7. Click Next.
In the AppFabric Connect page, select the Extend the reach of the service on the cloud checkbox. In the Service Namespace text box, enter the service namespace that you must have already registered with the Service Bus. For this tutorial, we assume that the service namespace is ContosoNS.

Click Next.

Note: If you select this check box, in the subsequent pages, you must configure the properties for the Service Bus endpoints. If you do not select the check box, the wizard will only create a WCF service that can be accessed locally within the organization.

In the Configure Behaviors page, configure the service behavior (for both on-premises and cloud-based services) and the endpoint behavior (for only endpoints on the Service Bus).

In the service behavior configuration section, specify the following values:

For the Property	Specify the Value
EnableMetadataExchange	Set this to True to enable metadata exchange for the WCF service. By setting this to True, you make the service metadata available using standardized protocols, such as WS-Metadata Exchange (MEX). Default is False. Note: For this procedure, you must set this property to True to generate a Service Bus metadata exchange endpoint. When you create a client to consume the service, you will need to specify the Service Bus metadata exchange endpoint. If you set this to False, the Service Bus metadata exchange endpoint is not generated.
IncludeExceptionDetailsinFault	Set this to True to include managed exception information in detail of SOAP faults returned to the client for debugging purposes. Default is False.
Name	Specify the name for the service behavior configuration.
UseServiceCertificate	Specify whether you want to use the message-level security mode of WCF. Default is True. For this tutorial, you can set this to False. Note: If you set this property to True, you must also enter the values for properties under the ServiceCertificate category.
FindValue	A string that specifies the value to search for in the X.509 certificate store. Note: Specify a value for this property only if UseServiceCertificate is set to True.
StoreLocation	A value that specifies the location of the certificate store that the service can use to validate the client's certificate. Note: Specify a value for this property only if UseServiceCertificate is set to True.
StoreName	Name of the X.509 certificate store to open. Note: Specify a value for this property only if UseServiceCertificate is set to True.
X509FindType	The type of X.509 search to be executed. Note: Specify a value for this property only if UseServiceCertificate is set to True.

Note: For more information about the certificates and the associated properties, see "X509ClientCertificateCredentialsElement Properties" at http://go.microsoft.com/fwlink/?LinkId=103771.

In the cloud endpoints behavior configuration section, specify the following:

For the Property	Specify the Value
Name	Specify a name for the endpoint behavior configuration.
EndpointDiscovery	Set this to True to if you want the endpoints are publicly discoverable. This is especially useful in scenarios when an organization has a large customer base and it does not want to run the overhead of communicating all the endpoints to all the clients. While configuring the service, if an organization sets this option to True, the endpoints will be listed on the Service Bus ATOM Feed. For this procedure, set this to True.
IssuerName	Specify the username who is the owner of the service namespace you entered in the previous page. This is required to authenticate the identity of the service namespace owner to the Service Bus.
IssuerKey	Specify the secret key for authentication of the service namespace owner.

The following screen shot shows the specified properties:

Click Next.

In the Configure Endpoints page, specify properties for both on-premises and Service Bus endpoint configuration.

From the Select a contract type box, select TableOp_dbo_Stocks. The wizard creates this contract based on the name of the table for which the operations are being exposed. If you had selected more than one operation on the Stocks table, all the selected operations would still be under the same contract. However, if you had selected an operation from another table, the wizard would have created another contract for that table.
In the on-premise endpoint behavior section, specify the binding and endpoint name. The WCF Adapter Service Development Wizard only supports WSHttpBindingElement for the on-premise endpoint. However, you can configure certain properties for this endpoint by clicking on the ellipsis (…) button that appears when you click the grid row for the binding.

For this tutorial, we are only configuring the Service Bus endpoints. So you can accept the defaults for the on-premises endpoint configuration.

In the cloud endpoint behavior section, specify the following properties:

For the Property	Specify the Value
Binding
Binding	Specify the binding for the endpoint. You can select from netTcpRelayBinding, ws2007HttpRelayBinding, and basicHttpRelayBinding. The URL schemes are different for these bindings. For netTcpRelayBinding, the URL scheme is sb. For ws2007HttpRelayBinding, the URL scheme is http/https. For basicHttpRelayBinding, the URL scheme is http/https. For this procedure, select the netTcpRelayBinding. Note: The wizard generates a relay service endpoint only if you select netTcpRelayBinding. For the other two bindings, the wizard does not generate the relay endpoints. So, if you select a binding other than the netTcpRelayBinding, you will need to provide the metadata separately to the clients because there will be no endpoint using which the clients can generate metadata.
Binding Configuration	Specify properties for the selected binding. You can do so by clicking on the ellipsis (…) button that appears when you click the grid row for the binding configuration property.
Endpoint Details (properties for the Service bus endpoint)
Name	Specify a name for the relay service endpoint.
RelayClientAuthentication	Specify whether the service bus authenticates the client before routing the message from the client to the service. If you want the service bus to authenticate the client before relaying the client request to the service, set this property to RelayAccessToken. Otherwise, set this to None. Tip: Hosting Service Bus endpoints on the Service Bus incur cost. If the Service Bus does not authenticate the client before it relays the request to the service, the service provider will have to bear the cost even if the client is not authorized to access the service. Microsoft recommends that you always set this property to RelayAccessToken for service endpoints so that only authenticated clients can traverse through the relay service. For this procedure, set this property to RelayAccessToken.
ServicePath	Specify the service path that will be appended to the service URL to create a unique endpoint for the service. By default, this is set to the contract name.
URI	Displays the URI for the relay service endpoint. The values you entered for the Service Namespace and ServicePath properties are used to create the URI. For example, a URI would look like sb://ContosoNS.servicebus.windows.net/TableOp_dbo_Stocks/. Here, “sb” is the scheme, ContosoNS is the service namespace you entered in one of the previous wizard pages, servicebus.windows.net is the Service Bus base URL, and TableOp_dbo_Stocks is the service path.
Metadata (properties for the Service Bus metadata exchange endpoint)
EnableMexEndpoint	Specify whether you want to enable the relay metadata exchange endpoint on the Service Bus. For this procedure, set this to True. Note: If you had set EnableMetadataExchange to False in the Configure Behaviors page, you would not be able to set any property for the relay metadata exchange endpoint. Note: Enabling Service Bus metadata exchange is not supported with BasicHttpRelayBinding and WS2007HttpRelayBinding because of known compatibility issues between SvcUtil and these bindings. Hence, EnableMexEndpoint is set to False if you choose any of the two bindings.
RelayClientAuthentication	Similar to the RelayClientAuthentication for service, this property specifies whether the Service Bus authenticates the client before routing the request to the metadata exchange endpoint. For this procedure, set this property to None. Note: For this topic, we will be using the Add Service Reference Visual Studio component to generate a proxy for the relay service. The Add Service Reference component requires the relay metadata exchange endpoint to generate the proxy. If we set this RelayClientAuthentication property to RelayAccessToken, we would have to modify the configuration file for Add Service Reference to include a behaviors element that will contain the token credentials for accessing the relay metadata exchange endpoint. So, for ease of use and demonstration, we are setting this to None.
URI	Displays the URI for the relay metadata exchange endpoint. The value is derived by appending “_mex” to the relay service endpoint URI.

The following screenshot shows the specified properties:

Click Apply and then click Next.

In the Summary page, review the summary and click Finish. The wizard creates the WCF service (.svc) and a web.config for the service and adds it to the Visual Studio project.

Prepare IIS for Hosting the On-premise Endpoint

As you saw in the last procedure, the wizard creates both on-premise and Service Bus endpoints for the WCF service. We also saw that the on-premise endpoint only supports wsHttpBinding and has to be hosted locally, which can only have an https scheme. Hence, to ensure that the local endpoint is hosted successfully, we must add https to the list of supported bindings. For information on how to add bindings to a site, see http://technet.microsoft.com/en-us/library/cc771629.aspx.

Publish the Service

We are now all set to publish the service. Perform the following steps to publish the service on the cloud:

In the Visual Studio project for the service, right-click the project in Solution Explorer and click Properties.
On the Properties page, in the Web tab, under Servers category, select the Use Local IIS Web Server option.
The Project URL text box is automatically populated. Specify a different URL if you want and then click Create Virtual Directory.
In Solution Explorer, right-click the project again and then click Build.
Open IIS Manager and verify whether a site directory is created.

Configure the Service to Start Automatically

Note: The steps listed below are applicable to IIS 7.5 (as part of Windows Server 2008 R2 or Windows 7) with Windows Server AppFabric installed. These steps are not applicable to IIS 7.0 on Windows Server 2008 and Windows Vista. That is because IIS 7.0 does not support auto-start for services. For Windows Server 2008 and Windows Vista, the workaround to start to bring up the services is to hit the on-premises endpoints manually, which will bring up the entire service including the Service Bus endpoints.

You must configure auto-start for the service to start automatically. But why do you need to configure this? Here’s why: A client can consume a service only when the service endpoint is available to the client. For a service hosted on-premises, the corresponding relay service endpoint will be registered on the Service Bus only when the on-premises service starts. But the on-premises service will not start until the first client request comes through. So, there’s a deadlock where the client is waiting for the service to come up and the service is waiting for the client to invoke it. To get around this deadlock, we can configure the service to start automatically without waiting for the first client request.

This section provides information on how to configure auto-start for the services.

In the IIS Manager, expand Default Web Sites, and then click on the service Contoso_Service.
In the Actions pane, under Manage WCF and WF Services section, click Configure.
In the Configure WCF and WF for Application dialog box, from the left pane, click Auto-Start and in the right pane, select Enabled.
In the dialog box informing that all the services will be recycled, click Yes.

Verify if the Service is Published

As a practice, you can verify if the Service Bus endpoints for the WCF service are published. While configuring the service, we had set a (EndpointDiscovery) property that would make all the endpoints publicly discoverable. So, to verify whether the endpoints are published, all we need to do is to view all the available endpoints in the Service Bus ATOM feed page for the specified service namespace. The URL for the Service Bus ATOM feed page has the following format:

http://%3cservice/<namespace>.servicebus.windows.net

In this procedure, the service namespace we used was ContosoNS. So the URL will be:

http://contosons.servicebus.windows.net/

Type this URL in a Web browser and press Enter. It should list all the endpoints available under the specified service bus namespace. If the service you created is registered successfully with the Service Bus, the new endpoints will also be listed on the page.

Create a Client to Invoke the Service

In this section, we will create a client to consume the WCF service for which we created a relay service and hosted on the Service Bus. The client will take an employee number as an input and will present the stock details for that employee ID. You can create any type of client to invoke the service. For example, you can also create SharePoint client to invoke the Select operation that is invoked as a WCF service. However, to consume the WCF Service through a SharePoint client you must have selected the Create WCF Adapter Service for SharePoint client checkbox on the Welcome page of the WCF Adapter Service Development Wizard. In this section, for ease of understanding, we will create a simple console application.

Start Visual Studio 2010 and create a new console application. For this topic, let us name the project as Contoso_Service_Client.
In the Solution Explorer, right-click References, and select Add Service Reference.
In the Add Service Reference dialog box, do the following:
1. In the Address text box, enter the URL for the Service Bus metadata exchange endpoint for the WCF service you hosted on the Service Bus. You can get the URL from the Service Bus ATOM feed page that listed all the publicly discoverable endpoints (http://contosons.servicebus.windows.net/). Right-click the metadata exchange endpoint, select Copy Shortcut, and paste it in the Address text box in the Add Service Reference dialog box. For this procedure, the URL for the relay metadata exchange endpoint will be:
  1. https://ContosoNS.servicebus.windows.net/TableOp_dbo_Stocks_mex/
2. Specify the namespace. For this procedure, we will use the default namespace specified in the text box, ServiceReference1.
3. Click OK.
If RelayClientAuthentication property for the relay service endpoint is set to RelayAccessToken, the client will need to pass the authentication token to authenticate itself to the Service Bus. Provide the client authentication token by modifying the app.config in the following manner.
1. Open the app.config for the client and add the following within the system.serviceModel element:
```
<behaviors>
  <endpointBehaviors>
    <behavior name="secureService">
      <transportClientEndpointBehavior credentialType="SharedSecret">
        <clientCredentials>
          <sharedSecret issuerName="<name>" issuerSecret="<value>" />
        </clientCredentials>
      </transportClientEndpointBehavior>
    </behavior>
  </endpointBehaviors>
</behaviors>
```
  In this snippet, the behavior name is specified as secureService. You can set this to any other value. You must get the values for issuerName and issuerSecret from the organization that hosted the service.
  
  Note: Clients can use other authentication mechanisms like SAML token or SWT token as well.
2. In the app.config, add the behaviorConfiguration property to the client/endpoint element for the relay service endpoint. You must set the behaviorConfiguration property to the value you specified for the behavior name. So, if you set the behavior name to “secureService”, you must set the behaviorConfiguration property as
  
  behaviorConfiguration="secureService"
  
  The updated endpoint element would now be:
```
<endpoint address="sb://ContosoNS.servicebus.windows.net/TableOp_dbo_Stocks/"
binding="netTcpRelayBinding" bindingConfiguration="TableOp_dbo_StocksRelayEndpoint"
contract="ServiceReference1.TableOp_dbo_Stocks" name="TableOp_dbo_StocksRelayEndpoint" behaviorConfiguration="secureService"/>
```
3. Save and close the app.config.

Open the Program.cs for the application and do the following:

Add Contoso_Service_Client.ServiceReference1 namespace.

Create a client as described in the snippet below:

TableOp_dbo_StocksClient client = new  TableOp_dbo_StocksClient("TableOp_dbo_StocksRelayEndpoint");

Specify the username and password to connect to the SQL Server database. This is required to authenticate the client against the backend LOB systems, in this case SQL Server.
```
client.ClientCredentials.UserName.UserName = "<username>";
client.ClientCredentials.UserName.Password = "<password>";
```

Open the client as described in the snippet below.

try
{
    Console.WriteLine("Opening client...");
    Console.WriteLine();
    client.Open();
}
catch (Exception ex)
{
   Console.WriteLine("Exception: " + ex.Message);
   throw;
}

Take the employee ID from the user as an input:

string input;
int emp_id;
Console.Write("Enter the employee ID for which you want to retrieve the stock details: ");
input = Console.ReadLine();
int.TryParse(input, out  emp_id);
Console.WriteLine();

Retrieve the records from the Stocks table based on the employee ID provided by the user:
```
Stocks[] records = client.Select("*", "WHERE [Employee Id]="  + emp_id);
```

For the specified employee ID, present the data from the Stocks table back to the client.

Console.WriteLine("The stock details for employee ID {0} are:", emp_id);
 
Console.WriteLine("*********************************************************");
Console.WriteLine("Company Name     :" + records[0].Company);
Console.WriteLine("Ticker Symbol    :" + records[0].Ticker);
Console.WriteLine("Holdings         :" + records[0].Holdings);
Console.WriteLine("Price/share      :" + records[0].CurrentPrice);
Console.WriteLine("Total Value      :" + records[0].TotalValue);
Console.WriteLine("*********************************************************");

Close the client and exit the application as shown in the snippet below:

client.Close();
Console.WriteLine("Press any key to exit...");
Console.ReadLine();
Console.ReadLine()

Press F6 to build the solution and then press F5 to run the application.
For a user with employee ID 10001, details similar to the following will be presented on the console:

Opening client...

Enter the employee ID for which you want to retrieve the stock details: 10001

The stock details for employee ID 10001 are:

*********************************************************
Company Name     :Fabrikam
Ticker Symbol    :FABK
Holdings         :34
Price/share      :27.20
Total Value      :924.80
*********************************************************

Press any key to exit...

Known Issues

This section lists some known issues with suggested workarounds for the WCF Adapter Service Development wizard.

Issues with Unicode Characters

The WCF Adapter Service Development wizard may fail to work properly if it encounters Unicode characters. For example, the wizard might not give the desired results if the LOB artifacts being exposed as services have Unicode characters in their names. Similarly, the wizard might not function properly if the ServicePath you specified in the Configure Endpoints page has Unicode characters. You should not use Unicode characters when working with WCF Adapter Service Development wizard.

Accessibility Issues on Low Resolution Monitors

The WCF Adapter Service Development wizard has accessibility issues when used at low resolutions. Only resolutions higher than 1024 x 768 are recommended.

Installation Issue with Windows Server AppFabric SDK

Windows Azure AppFabric SDK V1.0 September update fails to install on a 64-bit machine if only 32-bit version of BizTalk Adapter Pack 2010 is already installed on the same computer. This issue has been fixed in later updates of the SDK V1.0. To workaround this issue, you can do one of the following:

Install 64-bit version of BizTalk Adapter Pack 2010 alongside the 32-bit version of BizTalk Adapter Pack 2010, or
Install Windows Azure AppFabric SDK V1.0 before installing BizTalk Adapter Pack 2010.

Sample

Through MSDN Code Gallery you can find the following sample based on this article:

BizTalk AppFabric Connect for Services: Expose SQL Server Database View

Share via