.NET Remoting / SOAP / JBOSS.Net

[attiksystem]

Hi,

I'm currently investigating how it would be possible to link a .NET fat client (WinForms) to JBOSS.

I have read about JBOSS.NET. Correct me if I'm wrong, but this extension relies on the SOAP protocol exclusively, which is a protocol that relies on XML encoded data sent over the network. Although SOAP is certainly great to connect to the rest of the world, I don't have the feeling it is a protocol particularly well suited to build a WinForms-JBOSS system, from a performance point of view. I think a binary protocol could be more powerful, use less network ressources.

I have also read about .NET Remoting. The commercial Ja.NET library relies on this protocol, which can send and receive data as a binary stream. This sounds more powerful to me.

Here is my question: what are the advantages of using SOAP, instead of .NET Remoting, for accessing JBOSS from .NET? Are there other alternatives, like IIOP?

Thanks for your comments

Note: I haven't been testing all these technologies really, so maybe I miss an important point here. Feel free to correct me if I'm wrong.

Philippe Lang

[scharlau]

Phillipe,

I think you've overlooked something. JBoss.NET is nothing to do with MS.NET, but rather a name associated with web services integrated into JBoss.

I just looked up .NET Remoting and maybe you could use this to create the client, but as for the server, you'd have to run that on something other than JBoss, as it would need to be a Win platform. Also the article I saw mentioned that while it was easier to use than Java RMI, it was more difficult than creating a web service.

JBoss.NET is a project for deploying Web Services (ie SOAP) on JBoss and is based on the Apache Axis Engine. SOAP is designed to be a method for accessing services running on a platform from a variety of clients. As SOAP messages are XML structures, it (in theory at least) doesn't matter if the server is Unix running a Java service, and the client is Linux running PHP. The server should speak 'SOAP' and the client speak 'SOAP' so they should communicate.

However, there are still interoperability bugs, so not everything works 'out of the box', but you can check places like SoapBuilders http://groups.yahoo.com/group/soapbuilders/ for more details.

Therefore in principle, you should be able to do a fat .NET client to speak to something running on JBoss via the JBoss.NET web services. Look around in under this branch of the forum for other examples and things to get you going with JBoss.NET.

cheers,

Bruce

[attiksystem]

Hello,

Thanks for your answer.

> I just looked up .NET Remoting and maybe you could
> use this to create the client, but as for the
> server, you'd have to run that on something other
> than JBoss, as it would need to be a Win platform.

I thought that maybe it would be possible to write some kind of ".NET Remoting" toolkit in java, which would allow a fat .NET client to talk to jboss, almost transparently, even if it runs under Linux. (Why not something automatically generated by xdoclet?)

Philippe

[bleupen]

if you make use of a course-grained service API and client-side caching, your performance should be fine.

personally, i like this approach. give most users what they really want: a Windows client and a fast/scaleable server!

b