Big Issue in .Net Service Bus When trying to communicate between JAVA and C# technology in SOAP approache

Last week i was thinking to create a tutorial to show people, how different technologies can interact by using .Net Service Bus.

However after last week`s experiment, seems that, .Net Service Bus hasn`t implement such functionality yet.

Ok..seeing is believing.....let me show you how i found out the fact.

My source code can be download from below.
Publisher In C# http://shrimpysprojects.googlecode.com/files/PublisherDemoInSoapV1.rar

Subscriber In Java http://shrimpysprojects.googlecode.com/files/DotNetServiceSubscriber.zip


Over View:

What i did for last week is that, i create a publisher service in C#, plugin into .Net Service Bus, then i create a java subscriber, and ask for service from the .Net Service Bus.


Part one, C# Publisher Service

In this service, i am going to use wsHttpRelayBinding.

Actually i had tried most of the bindings, basicHttpRelayBinding, webHttpRelayBinding and even netTcpHttpRelayBinding.

Q: why TcpHttpRelayBinding
A: 老板 also working on the same issue, try to make java communicate with C#, he try netTcp as well, i think the reason it that, when using java sdk, it only support sb as prefix.

The result turn out to be that,
with netTcp and wsHttp, i got http 500 internal error,
with basicHttp and webHttp i got http 400 bad request error.

Later in this artile i will show u the soap package as well.

Let start to set up the project first.


Step One:

Create a normal C# console application


Step Two:
Create interface for service contact and the impl of interface


Step Three, App.config

Final Step, Invoke service API, register the service onto .Net Service Bus


In the end, the whole project will look like this:


Now right click on the project, choose

Debug-->Start new instance

Theoretically you are supposed to get the app up and run




Part Two, create WSDL file

Base on the C# interface, render a set of WSDL file, so that later we can use it to create java subscriber.

I created a WCF project, base on the contact (interface) to create the WSDL, XSD files

When testing wshttpRelayBinding and netTcpRelayBinding
the WCF project use wsHttpBing to generate WSDL, XSD file

When testing basicHttpRelayBinding and webHttpRelayBinding
the WCF project use basicHttpBinding and webHttpBinding to generate WSDL, XSD file

Please refer to my source code .

The WCF project was create within the publisher project, it was a sub project.
Publisher In C# http://shrimpysprojects.googlecode.com/files/PublisherDemoInSoapV1.rar

if you want the WSDL file, go into DotNetServiceSubscriber.zip, under src/wsdl, you will find what u want.

Subscriber In Java http://shrimpysprojects.googlecode.com/files/DotNetServiceSubscriber.zip


PS: make sure you have fixed the endpoint and the url reference,

e.g
Cox i put all the wsdl and xsd file together in one folder,
when getting the file from WCF, in some file, you will see

Http://xxxxxxxxxxxxfilename.wsdl

make sure your change it to

filename.wsdl

also, change the endpoint to

sb://solutioname.servicebus.windows.net/endpointname

Part Three, create java subscriber

Base on the WSDL file, create a subscriber to connect to .net service bus.

Step one, create a .net service bus java project

Please refer to my prevous article to set up a java project first.

.Net service bus maven project set up with JavaSDK

Step two, add "wsimport" into POM

wsimport can easily parse WSDL and XSD file and generate us java code

Create a folder call "wsdl" under your src folder, and place all WSDL and XSD file into this folder.
Then edit your POM file as below


As you see from above, if you build the project, extra java code will place into your src folder,
these extra java code is the contact we can use with .Net service Bus Java SDK.



Final Step , create subscriber

Learnt from the sample of jdotnetservice.com, i create the subscriber as below






Now all the preparation have been done,
It is time to witness .Net Service cannot allow Cross techology communicate with SOAP approache.

Launch your publisher service, then run the java subscriber....

and you will get error information like these:


With the error info above, we don`t know what stage we had up to, so i sniffer all the package,
you can see from the pic below, we actually pass all the authentication, and find the service on the bus.

However the bus failed to link the java end and C# end together.

Q : WHY i can say that???
A: Because my C# code hasn`t get invoke yet...all the error happened before getting into my C# code


Also from the package sniffer, we can see the fault message


Ok...let dig this problem one more step further..
In my C# project, i also create C# subscriber, it works perfectly. so i sniffer its package as well..

so now we can compare what are the difference between soap package sent out from the C# subscriber and java subscriber

SOAP package from C# subscriber:


SOAP package from Java subscriber when WSDL was generate from wsHttpRelayBinding:

SOAP package from Java subscriber when WSDL was generate from basicHttpRelayBinding or webHttpRelayBinding:


We can see that, the java SDK absolutely got some problem, otherwise, the chatroom will not always be there.

But this wouldn`t be the case that affect the communication, as we can see, in C# subscriber, it did not have a "from".

and when comparing these three file, we can see that, java subscriber use WSDL generate from basicHttp or webHttp binding , the soap package sent out would be almost the same as the C# subscriber..

But this raise a issue...

For what i experience, Java SDK for .Net Service Bus only support SOAP 1.2, (Another article will be come soon, taking about limitation of .Net Service Bus java sdk. which base on my prevouse prototype work, i created a java publisher and a java subscriber, and let them talk with each other)

So when creating C# publisher, we suppose to use wsHttpRelayBinding

However, from the SOAP package, there are big different betweent the C# subscriber and java subscriber which was using WSDL from wsHttp binding...