Any reason in particular why you wouldn't want to go over something like SOAP?
Thanks for the quick reply Kurt. It is about access to the native COM
itself (which , as you must be aware, has it's own binary protocol).
We have this library using which we can access the COM servers
directly from Java. I am not sure where SOAP comes in. Kindly correct
me if I have misundertsood your question...we intend to do something
on the lines of DCOM BC for OpenESB
I have tried to draw a picture representing what we have in mind... please correct me if I my understanding is flawed or there is a better way to
Yes, a native COM gateway/bridge makes sense. Web Services (or SOAP/HTTP) would be an alternative option, but definitely not if performance is one of your criteria.
it is non native COM gateway and can be used even from non windows platform, that is the idea behind using http://j-interop.sourceforge.net . I could not follow what you meant by Web services option, is there a way to interoperate with COM runtime using Web Services? For sure, the web service could directly redirect the call to a COM server, but we intend to directly call the COM server.
Do you mean such a scenario/ approach ?
----->[ESB] ---> [Listerner] ---> [Web Service] ---invoke dll or j-interop --> [Com Server]
----->[ESB] ---> [Listerner] --j-interop ---> [Com Server]
Thanks for the reply,
By "native COM" I simply meant no translation into SOAP/HTTP. However, if you look at the MSFT site you'll find references to how to integrate COM/DCOM with Web Services.
1. A COM gateway would listen for COM events. We use Notifiers to send messages out of the ESB (not listeners). So you'd want to make a COM
Notifyer too if I understand your drawings right.
2. I think both Mark and I are assuming you want to talk COM out of performance reasons. Is that right? I would be easier to go across something like WebServices.
3. Maybe you can elaborate a bit more on what it is you want to use this for?
Hi Mark and Kurt,
Thanks for your replies and recommendations. In the last couple of day, we investigated the Web services with COM approach. Unfortunately we found out that it is an invasive procedure(changes on the server) and requires a lot of setup. And is as you mentioned performance intensive. One of the reasons why we chose j-Interop for communication with COM was that it is completely non invasive . It is a pure java library implementing COM binary protocol, and its performance is acceptable to us. We are building a SAAS platform where we see a lot of potential for an ESB (currently we need to support SAP R/3). I apologise I cannot go much into details due to IP reason.
As for point 1 by Kurt:-
Sorry about the misunderstanding of "Listener", but from my point of understanding the notifier is only a special kind of action which listens on a channel.
May be we used an invalid naming? Please correct me if I am wrong.
We will start the initial analysis and architecture of our gateway/bridge. Is it possible for us to post the papers here for review ?
Yes, this is the appropriate place to post.
I was looking at the Groovy docs (for an unrelated issue) and noticed that Groovy 1.5 has support for talking to COM components. The ESB is currently using Groovy v1.0, but if it was upgraded to v1.5, then this feature + a Groovy Scripted Gateway could provide a solution for you. Just a thought!
What other groovy features does Groovy 1.5 offer :-)?
Not sure, but is there any truth in the rumor that you're about to make a contribution... "GoldFarts" ... "Groovy for Old Farts" lol ;-)
No truth in that rumour ;-) Though I am waiting for you ;-)