TIBCO.EMS .NET client / WCF channel
Asked Answered
S

2

10

Folks,

TIBCO has announced support for WCF channels back in April - has anything of that materialized by now??

Where and how can I download either these new WCF channel bits, or where can I get my hands on a current .NET 2.0/3.5 version of the "TIBCO.EMS .NET client library" ??

We're a small ISV without any ties to TIBCO so far, but a large client of ours required us to interop with his TIBCO EMS system, without being able to provide the technical background info we need :-(

Thanks for any hints and pointers ! Marc

Follow-up - 2009-Jan-14: Not much response here.... those of you using TIBCO EMS - how do you interface with it, e.g. communicate and send data back and forth??

UPDATE (April 2010)
I've had an opportunity to check out the "native" TIBCO.EMS.dll from .NET, as well as their WCF implementation, and my conclusion is: use the native API. It's easy, it's simple, it works.

The WCF parts are horrendous. They're incomplete, very unconventional, they don't feel like a good WCF citizen. TIBCO only provides a transport element - you can't just use a ready-made emsBinding or something - you'll have to define that yourself. I was very disappointed - I had expected more from a company the size and reputation of TIBCO....

Saidee answered 23/11, 2008 at 15:22 Comment(0)
V
11

Your communication stack will be a lot simpler if you simply use Tibco EMS .NET client directly. It's styled after JMS, which is widely used in enterprise software development. Hence there are a lot of tech books on how to do JMS programming. Java and C# are so similar that it's easy to do the mental translation to apply that to Tibco EMS .NET client programming.

Having designed and implemented a lot of communications channels for distributed applications, my experience has been the simpler the stack the more reliable and trouble-free in operation.

The problem with abstraction layers of the ilk of WCF is that there is almost always a leaky abstraction issue lurking somewhere.

V2 answered 29/1, 2009 at 1:11 Comment(2)
@RogerV: yes, thank you for that. The Tibco WCF implementation leaves a lot to be desired.... while the native EMS library seems to work just fine.Saidee
I use TIBCO EMS .net client to integrate with some of our clients & it works fine as many said here. But, I'm not able to write unit tests because of their concrete classes and internal constructors and the lack of interfaces. How did you overcome this issue?Vacation
D
3

For tibco and wcf you need to be running at least version 4.4.3 as the minimum that tibco supports. Otherwise you will have to use there standard protocol. They do have .net so you should not have to do interop. I have not used the WCF component as of yet as the place where I work is still on 4.3.0 and while they say it should work it is not supported. We just got the bits as we are supposed to update to 5 soon.

To get these bits your going to have to get it from your client if they want you to work with it. That would be my opinion other than that your best bet would be to contact Tibco to see if you can work something out.

The big question though will be what version of Tibco EMS your client is using.

Depalma answered 29/1, 2009 at 1:2 Comment(2)
OK, thanks - not sure yet what version they're running, and what interface they'll be using. I have a C# interface to IBM Websphere MessageQueue already - but I was a bit surprised they said it would be a "SOAP-to-EMS" interface - like calling a webservice....hmmm.....Saidee
If data is being pushed one way, then in vendor integration it's pretty common to give the outside vendor a simple web service call that passes a message in to be queued on the message broker (or ESB). Alas, a lot of vendors tend to find bi-directional, async messaging too much to groc.V2

© 2022 - 2024 — McMap. All rights reserved.