WCF (Indigo)

Consuming WCF Services from COM using C++

Shawn Cicoria — Wed, 29 Aug 2007 01:28:50 GMT

A little while back Martin sent me a question on some of the examples in Chapter 10 of our book (Pro WCF). The point of the question was how to dynamically consume a WCF services (late bind) from C++ using COM.

The root of the capability lies in the moniker implementation, which is provided for inside of System.ServiceModel.ComIntegration. There's a series of types, attribute type as well, that the ServiceModel framework will build up the COM client along with the interfaces based upon a "GetObject" call from VB or even C++.

The thing with VB is it makes things so much easier. So, I finally got around to fiddling with it. I did end up with an issue, but the jist is easy to follow.

The source code link here has a couple of samples that dynamically call a COM interface - one using the "script" moniker which is for Windows Scripting Host Components (built a whole site based upon that years ago) and WCF.

Let's take a look at calling a Scripting Component using C++ COM. Note that the CoGetObject is a call that combines 3 distinct calls into 1 convenient method. Take a look at the attached sample wsc file to see the inners of the component.

The script moniker is the key. Just as we'll see in a bit the service moniker. Both are defined in the registy under HKCR\script and HKCR\service as to which COM component implements the moniker (IMoniker) interface.

The main steps are: 1) Initialize COM, 2) GetObject, 3) Get Dispatch Interface for method, 4) Invoke interface

Sample Solution

    1 int CallWscComponent()
    2 {
    3     HRESULT hr;
    4     IDispatch* objWsc;
    5 
    6     hr = CoGetObject(L"script:D:\\Data\\Projects\\CallingWcf\\test.wsc",
    7         NULL,
    8         IID_IDispatch,
    9         (void**)&objWsc);
   10 
   11     if (FAILED(hr))
   12     {
   13         Message(TEXT("Client: CoGetObject"), hr);
   14         return(hr);
   15     }
   16 
   17 
   18     DISPID dispid;
   19     CString strFxName = "methodname";
   20     OLECHAR * szMember2 = strFxName.AllocSysString();
   21 
   22     hr = objWsc->GetIDsOfNames(
   23         IID_NULL,
   24         &szMember2,
   25         1,
   26         LOCALE_SYSTEM_DEFAULT,
   27         &dispid);
   28 
   29     if (FAILED(hr))
   30     {
   31         Message(TEXT("Client: GetIDsOfNames"), hr);
   32         return(hr);
   33     }
   34 
   35     DISPPARAMS dispparamsNoArgs = {NULL, NULL, 0, 0};
   36 
   37     hr = objWsc->Invoke(
   38         dispid,
   39         IID_NULL,
   40         LOCALE_USER_DEFAULT,
   41         DISPATCH_METHOD,
   42         &dispparamsNoArgs, NULL, NULL, NULL);
   43 
   44     if (FAILED(hr))
   45     {
   46         Message(TEXT("Client: Invoke"), hr);
   47         return(hr);
   48     }
   49 
   50 }

Now, here's an example of using an untyped proxy and Mex discovery.

The first thing is to do is build the moniker:

LPTSTR moniker = L"service:mexAddress=\"http://localhost:8899/WebService/Service.svc/mex\",\
                  address=\"http://localhost:8899/WebService/Service.svc\",\
                  contract=IMyService, \
                  contractNamespace=http://tempuri.org/,binding=BasicHttpBinding_IMyService, \
                  bindingNamespace=http://tempuri.org/";

Now, here's a quick walk-through of calling WCF through COM.

    1 void CallWcf()
    2 {
    3     HRESULT hr;
    4     IDispatch* objWsc;
    5 
    6     hr = CoGetObject(moniker,
    7         NULL,
    8         IID_IDispatch,
    9         (void**)&objWsc);
   10 
   11     if (FAILED(hr))
   12     {
   13         Message(TEXT("Client: CoGetObject"), hr);
   14         return(hr);
   15     }
   16 
   17     DISPID dispid;
   18     CString strFxName = "MyOperation3";
   19     OLECHAR * szMember2 = strFxName.AllocSysString();
   20 
   21     hr = objWsc->GetIDsOfNames(
   22         IID_NULL,
   23         &szMember2,
   24         1,
   25         GetUserDefaultLCID(),
   26         &dispid);
   27 
   28     if (FAILED(hr))
   29     {
   30         Message(TEXT("Client: GetIDsOfNames"), hr);
   31         return(hr);
   32     }
   33 
   34     DISPPARAMS dispparamsNoArgs = {NULL, NULL, 0, 0};
   35     EXCEPINFO pExcepInfo;
   36     memset(&pExcepInfo, 0, sizeof(EXCEPINFO));
   37 
   38 
   39     hr = objWsc->Invoke(
   40         dispid,
   41         IID_NULL,
   42         GetUserDefaultLCID(),
   43         DISPATCH_METHOD,
   44         &dispparamsNoArgs, NULL, NULL, NULL);
   45 
   46     if (FAILED(hr))
   47     {
   48         Message(TEXT("Client: Invoke"), hr);
   49         return(hr);
   50     }
   51 
   52 }

Additional Stuff on Integrating WCF Services with COM+

Shawn Cicoria — Mon, 27 Aug 2007 22:05:48 GMT

In my (along with Chris Peiris) MSDN article (Integrating WCF Services with COM+), there were a few things I wanted to change, but given the edit review cycle, I decided to wait until it was published and just blog about some additional concepts. What follows are just a couple of extra pictures that give a view of how WCF ServiceModel.ComIntegration works in regards to calling COM+ Components from WCF Clients.

Let's take a little step back to COM+ and COM+ Applications. There are 2 types of COM Applications - Library and Server. The former is an inprocess hosting of your COM component; the latter is hosted in a server process, generally DllHost, which hosts your library along with controlling activation, recycling, etc.

Based upon the Application type, you have a different choices for hosting the COM+ component. The implications of each choice impact both performance (additional marshalling), manageability, and accessibility from legacy clients.

COM+ Library Package WCF Integration

The following is a quick view of what's happening with Library Packages and hosting of COM+ Applications.

When you're running the COM+ Integration Wizard from SvcConfigEditor you'll be presented with a single choice as shown below. This translates into a ComSvcConfig switch of /hosting:complus.

What are the implications of this model? Well, it's inprocess so marshalling across process doesn't happen. Although, all the ComIntegration parts of the framework kick in. You also have message based activation (it's hosted in IIS/WAS) so there's isn't necessarily a server process running continously.

COM+ Server Package - COM+ Hosted

When you get to Server Applications, you have a couple of options.

The first is COM+ hosted. This provides simultaneous access from DCOM and WCF clients. You then control process lifetime through the COM+ configuration settings - such as run as an NT Service, etc. You lose message based activation - You think about the process lifetime.

COM+ Server Package - IIS/WAS Hosted

The last option is IIS/WAS hosted Server Application. This is where you get both the advantage of DCOM & WCF access along with Message Based activation - but at the expense of making a cross process call between IIS/WAS and the Server Package process.

MSDN Article Finally Out - Integrating WCF Services with COM+

Shawn Cicoria — Fri, 17 Aug 2007 11:26:20 GMT

Well, an article, whose content was mostly taken from the WCF Book, is finally published on MSDN. It took quite a long time from "acceptance" to appearance. I believe it was back in February 2007 that it was finalized from a content perspective. Since then, I haven't heard much till today.

There were lots of updates that given the editing and review process, I held off on so it wouldn't be delayed. I'll now take the time and publish up on my blog - mostly more information on the different hosting models, perspectives and some issues.

Integrating WCF Services with COM+

WCF LOB Adapter SDK - WCFLOBASDK - Lot's of words, but lot's of help...

Shawn Cicoria — Mon, 13 Aug 2007 14:00:26 GMT

The BizTalk server team has released the aforementioned tool to facilitate the development of "Adapters" (not just BTS, but general WCF) for creation of WCF extensions to consume existing service interfaces. Mostly, it facilities building well structured classes that meet the WCF extensions requirements. Clearly, you still need to code up the actual interfaces, connection code handling, etc.

This SDK is usable without BizTalk and can be used to create interfaces to existing systems. Then, expose and consume these WCF bindings in your applications once they've been "installed".

Get the bits here: http://go.microsoft.com/fwlink/?LinkID=96184.

After you install you get a couple of Wizards and templates (CSharp Only). The 1st Wizard is available as "WCF LOB Adapter". This creates the based project that becomes the adapter that is then consumed (or referenced) later by choosing "Add Adapter Service Reference..." from the Project context menu.

Best bet is to walk through some of the samples. The samples make use of an installer that both installs your adapter in the GAC along with making changes to the machine.config in order to surface your custom adapter to the Add Adapter Reference tool as a WCF (system.serviceModel section) extension.

Minor issues

Note, that under Vista, some issues when running the MSI (installer). Ensure to elevate to Administrator (by running a cmd shell and Runas Administrator) then execute the MSI and no issues. I've seen this on 2 distinct machines.

There is a stand-alone help file (chm) that if you want to take a look at the capabilities, reference, etc., you can peruse it. To get it just unpack the Zip file that's at the link and browse to the WCFLOBASDK\Program Files\WCF LOB Adapter SDK\Documents directory.

After installation the Help integration also gives you a quite distinct TOC entry - it ends up being the help collection identifier:

There are a few limitations, one notably at this point is no support for IDuplexChannel and FaultContracts (the latter a limitation of the WSDL builder tool that's part of the SDK). So, the work-around is hand-coding.

You still get both Synchronous and Asynchronous wizard code generation for the Retrieval, Browse, and Search interfaces.