both TIBCO ETX and TIBCO Rendezvous, but we also use openadaptor to talk to our mainframe that has MQSeries and variety of JMS implemenations we are using or evaluation (weblogic, fiorano, sonicMq)
> Would I be right in thinking, then, that this
> thing manifests itself as a coupla jar's that
> you stick in the CLASSPATH, and some
> configuration files or DTDs?
absolutely correct, we use java Properties loaded from files. To run an "adaptor" you run the boot strap program with a configuration file.
We developed this stuff after deploying a middleware product entensiveley throughout our organisation. We wanted to accelerate the other dev teams in the bank in hooking up to the middleware.
We didn't want every dev team to be tied to the middleware APIs or to have to do all the standard things (data transformation, filtering, exception processing etc..).
You can think of it as the plumbing between the apps/databases and the middleware. Typically dev teams do this kind of work in all sorts of bespoke ways and there is lots of reduncancy of effort in development, testing and support.
example:
dev teams can pull data out of their database, filter it, transform it and publish it onto middleware. All this can be done by configuring standard building blocks and no code.
Slashdot Mirror
password protection removed
both TIBCO ETX and TIBCO Rendezvous, but we also use openadaptor to talk to our mainframe that has MQSeries and variety of JMS implemenations we are using or evaluation (weblogic, fiorano, sonicMq) > Would I be right in thinking, then, that this > thing manifests itself as a coupla jar's that > you stick in the CLASSPATH, and some > configuration files or DTDs? absolutely correct, we use java Properties loaded from files. To run an "adaptor" you run the boot strap program with a configuration file.
We developed this stuff after deploying a middleware product entensiveley throughout our organisation. We wanted to accelerate the other dev teams in the bank in hooking up to the middleware. We didn't want every dev team to be tied to the middleware APIs or to have to do all the standard things (data transformation, filtering, exception processing etc..). You can think of it as the plumbing between the apps/databases and the middleware. Typically dev teams do this kind of work in all sorts of bespoke ways and there is lots of reduncancy of effort in development, testing and support. example: dev teams can pull data out of their database, filter it, transform it and publish it onto middleware. All this can be done by configuring standard building blocks and no code.