WCF client to access Java SOAP server 1.2

Question

To all WCF experts out there... Maybe you can shed some light on the following questions.  Any pointers regarding WCF client to non-Microsoft implementation on .NET Framework 3.x will be appreciated too.  Thanks in advance.

1. I already have an object that can serialize to a valid XML input message; minus soap specific elements.  If I pass it directly, it will fail because the object type is so different than type generated by svcutil.exe.  What's the best way of passing this to the service?  I know when I serialize my object, and the one created by svcutil to XML, they are identical. 
2. I guess this should be the first question.  To access a non-microsoft SOAP 1.2 service, is WCF the way to go on .NET Framework 3.0/4.0?
3. Reference:  Are there any good books/sites that you can refer regarding WCF client (specially non-Microsoft implementation)?  I've seen so many WCF service, but very less focus on the client.

Answer 1

1. You should compare the xml your object generates to the one you need. If they are not identical you should decorate your object with flags that customize its serialization. xml serializer probably better fits this mission:

http://msdn.microsoft.com/en-us/library/83y7df3e(v=vs.71).aspx

2. You can use even .Net 2 without WCF for that. It is recommended though to use WCF, and probably 4.0 is better, but this is definitely not a must.

3. It depends what exactly you want to know. Most sites deal with issues which are orthogonal to either service or client (e.g. security). If you are interested in a particual non-.Net client (e.g. WSIT, Axis) you should read on it. In my blog I wrtie a lot about web services interoperability between WCF and non-.Net:

http://webservices20.blogspot.com/

---

http://webservices20.blogspot.com/
WCF Security, Interoperability And Performance Blog

Answer 2

Thanks Yaron.  I'm still reading your blog. 

I guess this is a newbie question.  I know that my xml input matches exactly vs using the svcutil-generated classes as input.  Eventhough the serialized objects produces the same XML format, these two objects are totally different.  How can use my object, and pass it through WCF?  Do I have to configure WCF client to accept my object instead of the object type specified by svcutil?

For example:

// Defined in reference.cs
public void GetMovies( SvcUtilGeneratedType search){}

How can I pass my own Search object with a different type?  Is it even possible?  Objects instantiated by SvcUtilGeneratedType and MyObject will produce an exact XML structure like this:  (Of course the XML structure is much more complicated that the example below.)

<root ...>
 <pre:searches>
  <pre:search name="Movie1">...</pre:search>
  ...
 </pre:searches>
</pre:root>

Thanks!

 

 

---

-CoolWaterXII

Answer 3

Hi

One option is to use the svcutil /r flag:

http://msdn.microsoft.com/en-us/library/aa347733.aspx

it will reference your type instead of creating a new one.

 

Another option is to write the client proxy by yourself. This is not exactly as changing the proxy code as you suggested (although this may work as well). An example is here:

http://en.csharp-online.net/WCF_Essentials%E2%80%94Working_with_Channels

---

http://webservices20.blogspot.com/
WCF Security, Interoperability And Performance Blog

Answer 4

Hi,

How can I pass my own Search object with a different type?  Is it even possible?  Objects instantiated by SvcUtilGeneratedType and MyObject will produce an exact XML structure like this:  (Of course the XML structure is much more complicated that the example below.)>>>

I don't think this is possible since the object you passed to wcf service has to be recognized by the service and should be matching the svcutil generated type exactly. Otherwise how is the service going to process the object you passed to the service after deserialization.

Thanks

Binze 

 

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.