This project is read-only.

Interoperability?

Topics: Developer Forum, User Forum
Jun 9, 2008 at 3:14 PM
I'm looking for ESB bus based on MS products - but I'm new to ESB.NET product and have one question.
In our organization we have many systems written in Java and .NET - some of them exposes Web Services, and some consumes Web Services.
Using ESB.NET it's possible to put together those Web Services written in Java and old services written in .NET? It is easy and simple? Or there are special and complicated tasks for WebService developer, to prepere thet WebService for ESB.NET?
I don't want to change old services or for example to write long book 'How to configure clients to use Contract Web Service' for vendors who write client apps
and want to use some of services...
Somebody can point me to some part of documentation?
Regards
mrozik
Jun 10, 2008 at 12:30 PM
Edited Jun 10, 2008 at 12:45 PM
Hi Mrozik,
When it comes to Web Services, there's no issue in consuming them.
In developing your ESB.NET services, you consume your Web Services or other code using the standard .NET Web Service oriented tools.
i.e. WCF Client, ASMX Client, WF Web Service Connectors etc.
As such, it makes little difference if the Web Services are .NET or Java based.

From within the ESB.NET Service, again, consuming .NET code is again straight forward.

It is when you consume the ESB.NET services that you have a bit of a paradigm shift.

In the Releases, the download titled:
 Sample ESB.NET Client using ESB.NET Request Handler Proxy and Envelope libraries
shows how to consume an ESB.NET Service from a .NET based client, using the ESB.NET client-side libraries.


In essence, from both the client's point of view, and from the ESB.NET Server side point of view, it is message oriented communication.
You create a request (Envelope) with one or more payloads (XML documents, Binary Attachments, etc...), set the service name etc. and send it to an ESB.NET server & get a response etc. etc.
The ESB.NET Server can then route the request to appropriate instances as required. Routers are pluggable.

There are some ways to make ESB.NET services look like traditional Web Services (for point 'n click clients etc.), however that paradigm doesn't scale very well, hence the federated broker - messaging and routing approach...
It also promotes the use of Convention Over Configuration to ease the amount of work required to deliver a service.
On the ESB.NET Server Side, Configuration can be introduced Transparently to Service Consumers as required.

Cheers
Minas