Hosted Service on MF (DPWS) communicating with a WCF Client
Tim G.
again a DPWS related question from me ....
Consider the following scenario:
I have a Service being hosted on an MF Device (actually it's the Emulator)
and I would like to have a WCF (4.0) client consuming that service. I do not
want to use the (new) discovery features of WCF (since they will only work
within the same subnet and might cause problems when going over a router).
Now I found a lot of questions and some answers regarding that scenario;
however, I could not find up-to-date answers or even working code samples -
therefore I am asking this question in this newsgroup.
The most promising article is this one [Jim Mateer, Feb. 11, 2009]:
http://blogs.msdn.com/netmfteam/pages/getting-started-with-dpws-in-the-net-micro-framework.aspx
Now my questions:
The article above is talking about some bugs in the DPWS Stack - have they
been solved with the latest release?
Can anyone provide a working example of a MF-Service and a WCF-Client?
Below are my results/problems - maybe somebody has some suggestions?
Regards,
Tim
When I try to implement a WCF-client "talking" to my MF Service, I get the
following error (Hosting the service on the MF Emulator of VS2009 and running
the client in VS2010; MF 4.0, and WCF 4.0) when trying to call a service
operation on the client proxy.
##########################
The header 'To' from the namespace 'http://www.w3.org/2005/08/addressing'
was not understood by the recipient of this message, causing the message to
not be processed. This error typically indicates that the sender of this
message has enabled a communication protocol that the receiver cannot
process. Please ensure that the configuration of the client's binding is
consistent with the service's binding.
##########################
At the same time I get an exception (in the VS2009 instance, but it is not
causing the emulated device to crash):
##########################
#### Exception System.Xml.XmlException - 0xec000000 (11) ####
#### System.Xml.XmlReader::ReadElementString [IP: 003b] ####
#### Ws.Services.WsaAddressing.WsWsaEndpointRef::.ctor [IP: 0013] ####
#### Ws.Services.WsaAddressing.WsWsaHeader::ParseHeader [IP: 0142] ####
#### Ws.Services.WsSoapMessageParser::ParseSoapMessage [IP: 001f] ####
####
Ws.Services.Transport.HTTP.WsHttpMessageProcessor::ProcessRequestMessage [IP:
0009] ####
#### Ws.Services.Transport.HTTP.WsHttpMessageProcessor::ProcessRequest
[IP: 0160] ####
####
Ws.Services.Transport.WsThreadManager+MessageProcessor::ProcessRequest [IP:
0007] ####
#### Exception Ws.Services.Faults.WsFaultException - 0x00000000 (11) ####
#### Ws.Services.WsaAddressing.WsWsaHeader::ParseHeader [IP: 01a5] ####
#### Ws.Services.WsSoapMessageParser::ParseSoapMessage [IP: 001f] ####
####
Ws.Services.Transport.HTTP.WsHttpMessageProcessor::ProcessRequestMessage [IP:
0009] ####
#### Ws.Services.Transport.HTTP.WsHttpMessageProcessor::ProcessRequest
[IP: 0160] ####
####
Ws.Services.Transport.WsThreadManager+MessageProcessor::ProcessRequest [IP:
0007] ####
##########################
My app.config (for the WCF-client) looks like the following:
##########################
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.serviceModel>
<bindings>
<customBinding>
<binding name="TestServiceSOAP">
<textMessageEncoding maxReadPoolSize="64"
maxWritePoolSize="16"
messageVersion="Soap12WSAddressingAugust2004"
writeEncoding="utf-8">
<readerQuotas maxDepth="32" maxStringContentLength="8192"
maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
</textMessageEncoding>
<httpTransport manualAddressing="false"
maxBufferPoolSize="524288"
maxReceivedMessageSize="65536" allowCookies="false"
authenticationScheme="Anonymous"
bypassProxyOnLocal="false"
hostNameComparisonMode="StrongWildcard"
keepAliveEnabled="true" maxBufferSize="65536"
proxyAuthenticationScheme="Anonymous"
realm="" transferMode="Buffered"
unsafeConnectionNtlmAuthentication="false"
useDefaultWebProxy="true" />
</binding>
</customBinding>
</bindings>
<client>
<endpoint
address="http://10.100.0.150:8084/32f6aea8-9ba6-4d1d-9da6-896a5e711478"
binding="customBinding"
bindingConfiguration="TestServiceSOAP" contract="TestService"
name="TestService" />
</client>
</system.serviceModel>
<system.diagnostics>
<switches>
<add name="Remote.Disable" value="1" />
</switches>
</system.diagnostics>
</configuration>
##########################
Manuel M.
According to the errorcode it means: XML_E_ELEMENT_NOT_FOUND
The error codes can be found under XMLExceptions.cs in the ProtingKit
YOu can try to find out if the element differs from the one sent by the big
Framework.
Regards
Manuel M.
--
Menghin Manuel
NTE Naturenergie.Technology and Engineering GmbH
Tim G.
"Manuel M." wrote:
> The first exception seems to be the XMLException:
> According to the errorcode it means: XML_E_ELEMENT_NOT_FOUND
>
> The error codes can be found under XMLExceptions.cs in the ProtingKit
Alright, thanks for that.
> YOu can try to find out if the element differs from the one sent by the big
> Framework.
Well first of all, the question is: WHAT Element is the problem (According
to the received fault, it should be the "To"-Element)?
At a fist glimpse this seemed like an addressing issue (host and client
using different versions of WS-Addressing), but since I used:
"Soap12WSAddressingAugust2004", addressing should be fine (?).
I have already started to look at the SOAP-Messages (using a network
sniffer) - however, I was hoping not to have to dive too deep into
SOAP-Messaging, because I am using DPWS on one end and WCF on the other end
(which should in theory encapsulate most of the SOAP-related issues).
What I would really need, was a working sample-project (including the
sources) using the latest versions of the MF and WCF - or, somebody telling
me, that he encountered the same problems, but has not (yet) found a
satisfying solution (of course you can implement your own web-service stack
on the MF, designed specifically to work with WCF, but I would rather use the
existing DPWS-stack, since, in theory, communication should easily be
possible).
Regards,
Tim
Tim G.
"Tim G." wrote:
> At a fist glimpse this seemed like an addressing issue (host and client
> using different versions of WS-Addressing), but since I used:
> "Soap12WSAddressingAugust2004", addressing should be fine (?).
Seems like that was one mistake, at least when I compare the working
SOAP-messages created by a MF-client and the ones that I get from the
WCF-client. One should probably use:
"Soap12WsAddressing10"
> I have already started to look at the SOAP-Messages (using a network
> sniffer) - however, I was hoping not to have to dive too deep into
> SOAP-Messaging, ...
Well ... seems like there is no way around - I was using a graphically
designed WSDL (using the graphical editor for the Eclipse IDE), which lead to
really nice code for the MF (using MfSvcUtil), but the generated code for WCF
(using SvcUtil) is not too nice; it was even incorrect - manually fixing the
(most obvious) errors still yields the same ws-fault.
we'll see ...
Lorenzo Tessiore
we will have a Beta in Mid May that will have WCF4.0 samples
Regards
Lorenzo
aZubi
I had the same problem with the generated code. Although now my scenario is
the opposite (WCF host and MF client), as you can see in this post
(http://social.msdn.microsoft.com/Forums/en/wcf/thread/cfc0c21d-e0c2-47be-a6f5-93d9c9934881), the generated action string was different.
But now I have problems with deserializing the response message. I get an
error parsing the message?
Did you finaly make your scenario work?
aZubi
"Tim G." wrote:
> Hi,
>
> "Lorenzo Tessiore" wrote:
> > Hello,
> > we will have a Beta in Mid May that will have WCF4.0 samples
>
>
> That's perfect - I really appreciate that.
> In the mena time I found out, that one of my problems was the
> WCF-Codegeneration. As I mentioned above, I was using a graphically designed
> WSDL (using Eclipse), which led to really nice code on the MF; however on the
> WCF side the generated code was not that nice - after using the "/wrapped"
> switch on SvcUtil, it got a little bit better, but the Action-string (that
> finally also ended up in the Action-field of the SOAP-message) was simpliy
> wrong (or at least different from the ones in the generated MF code).
> To be even more specific: on the WCF-side the Action-string was the same as
> the name of the operation (specified in the WSDL) - on the MF the action was
> named "name of the operation" + "Request" (which was exactly what I had
> designed graphically and can be found in the WSDL).
>
> So after manually correcting the generated WCF code (which is somewhat
> inconvenient in the long run) my MF-service finally answers to the client's
> request; however, the client still has problems with message de-serialization
> ...
>
> For now, I will try to generate the WSDL and MF service-code from a
> (self-hosted) WCF dummy-service. I hope that this will solve the
> interoperability issues.
>
>
> Regards,
> Tim
Tim G.
"aZubi" wrote:
> Hello Tim,
> [snip]
> Did you finaly make your scenario work?
Actually I did get my scenario to work (finally). First of all, I did no
longer generate the WSDL graphically, but directly via a C#-Code contract
file (in WCF). After that I could establish basic communication, but I had
some troubles, transmitting a Byte-Array. The problem was, that the WCF
deserializer automatically assumes Base64-encoding, whereas the MF-Serializer
does a "plain-string" conversion of each byte.
So right now, I have fixed this by modifying a few lines within the
generated code (which is a pain) and I am hoping on the next 4.1 release
where the MTOM-bugs should be fixed. Then I hope to be able to use MTOM and
no longer Base64 or plain-string encodings for my byte array.
However - I just recently tried to introduce WS-Faults and again, it seems
as if there were some interoperability issues with the WCF-side -.-
Regards,
Tim