I had the opportunity to do some prototyping with this technology consuming Groove Web Services. The idea itself is cool - use an abstraction layer (i.e. behavior) that can read WSDL and allow higher level method invocation rather than getting into intricate SOAP/XML details. The problem is that the .htc file is buggy - I found 4 bugs in it so far, 2 of which I could work around.
In the event that this may help someone else who goes down this path, here is what I ran into and attempted to work around:
1) Found bug in getWsdl() function where XMLDocument being removed and set to null after first import occurs. This is problem because GrooveAccounts.wsdl imports Accounts.xsd as well as Core.xsd. Work-a-round was to move code to end of loadImports() function.
2) Found problem where "SOAPAction" header element was being converted into "soapaction" (i.e. lowercase transformation) which was not correctly understood by Groove Web Services (GWS) Server. Problem was addresed by instantiating "Msxml2.ServerXMLHTTP.3.0" instead of "Microsoft.XMLHTTP" COM object.
3) Found bug in parseComplexType() function for GrooveSpaces.wsdl where the namespace uri being associated with parsed object is not the same uri used to reacquire reference to parsed object. At this point, I could not found if the problem was with the original uri and the one used to reacquire reference. Issue seems to be inability to parse GrooveEvents.xsd, which uses extended data type.
4) Tried to workaround #3 by making uris match for parsed object resolution while in debugger - but ran into another parsing problem which prevented the GrooveSpaces.wsdl from being loaded. Issue seems to be inability to parse GrooveEvents.xsd, which uses extended data type.
