Finding the EPR for a provider from a notifier

[derek.adams]

I am trying to write a notifier that sends an outgoing message to an FTP server. Rather than having to specify all of the FTP server details in the notifier XML, I was hoping to give the notifier a provider name and get the FTPEpr and its RemoteFileSystem. Is there a way to do this using he current APIs?

[kurtstam]

Hi Derek,

I actually was in that code today. Note that we have routers and notifiers. Routers route to service endpoints, notifiers route non-ESB-aware-services, who are not in the registry.

However when I get that scout bug fixed we could start adding a second class of EPRs which represent non-ESB-aware endpoints. Question is, who is going to add these EPRs to the registry. The thirdparty systems that represent these non ESB aware endpoints won't "autoregister" like the ESB aware services do.

So there are 2 issues to fix before we can start using EPRs for notifiers, and personally I still see these notifiers as reversed gateways.

my 2 cents on this..

--Kurt

[derek.adams]

Kurt,

That sounds like exactly what I was looking for. Thanks for the clarification!

For the registration of non-ESB-aware endpoints, it seems like the EPR instances (created from the -esb.xml) could have provider category and provider name properties added in the schema. The EPR instances that have those properties would be added to the registry on startup and would be discoverable by other components.

Deployment of the actual providers that implement functionality for the EPRs is something I have been wondering about too. Right now, the providers for file, FTP, JMS, etc are tightly coupled to the framework itself. It seems like the providers should be deployed separately in their own SARs, and hot-deployed by the ESB. The SAR would include all of the implementation code and some kind of descriptor that contains a list of the EPRs available from the provider. Each EPR listed would have a unique identifier so that it could be referenced from the -esb.xml to create an EPR instance (would require using the generic schema elements rather than the provider-specific ones).

It sounds like a lot of work, but I think it would make contributing new providers to the ESB much easier.

Thanks,
Derek

[marklittle]

However when I get that scout bug fixed we could start adding a second class of EPRs which represent non-ESB-aware endpoints. Question is, who is going to add these EPRs to the registry. The thirdparty systems that represent these non ESB aware endpoints won't "autoregister" like the ESB aware services do.

Although an EPR can represent anything (including a vanilla URL), not everything need be represented as an EPR outside of the ESB domain. There are pros and cons to this, of course. But it's worth adding to the discussion "pot".

[marklittle]

"derek.adams" wrote:
Deployment of the actual providers that implement functionality for the EPRs is something I have been wondering about too.

You mean the service implementations, right?

Right now, the providers for file, FTP, JMS, etc are tightly coupled to the framework itself.

OK, maybe you don't ;-) Can you explain?

It seems like the providers should be deployed separately in their own SARs, and hot-deployed by the ESB. The SAR would include all of the implementation code and some kind of descriptor that contains a list of the EPRs available from the provider. Each EPR listed would have a unique identifier so that it could be referenced from the -esb.xml to create an EPR instance (would require using the generic schema elements rather than the provider-specific ones).

This is slightly confusing, but then that could be because I don't get the "provider" definition.

[derek.adams]

Sorry about the confusion -- I guess the easiest way to explain it is through an example.

Case 1: I want to add a new Telnet (or whatever other protocol) gateway to the system. Rather than adding it to the core JBossESB source code, I would like to be able to deploy the new implementation such that all of the impl code is contained in a separate jar. The JBossESB deployer would detect when the jar is added to the deploy directory and would add the gateway impl to the list it supports. Some of the meta-information in the jar would indicate how the new gateway would be referenced from the jboss-esb.xml. It is my understanding that EPRs are lightweight facades that provide info to the underlying gateway impl, so I was suggesting that the available EPR classes for an impl would be listed in the jar metadata. So, I would create my impl, jar up the libs/classes/metadata, drop telnetImpl.jar into the deploy directory, and all deployments could reference the new technology without changes to the core libs.

Case 2: I want to replace the FTP gateway/EPRs/etc included with JBossESB with my own impl. If the packaged implementations for file, FTP, JMS, etc are just jars in the jbossesb.sar folder, I could build my own and replace the appropriate jar (i.e ftpImpl.jar) with my new code... preferably without bouncing the server.

Does that make more sense?
Thanks,
Derek

[marklittle]

OK, that makes perfect sense and is something we'd want to support. From the outset we've been saying that everything should be replaceable and treated *like* a replaceable service. I don't think the current architecture is quite right for that at the moment, but we'll get there. This may be something that a number of us just take for granted and don't call out explicitly enough, so I've created a task for this http://jira.jboss.com/jira/browse/JBESB-512.

[bill.burke]

We should create another discussion on this based on the MC beanitizing of ESB that I want to do.

Derek, what if ESB supported JCA? That would be a perfect way to plug in inbound/outbound adapters.

[derek.adams]

I think using JCA would be a great idea. It would take care of a lot of things that need to be there like transactions, security, and connection management. It would also allow JBossESB to integrate with all the existing EIS that already have resource adapters.

[weston.price]

I think using JCA would be a great idea. It would take care of a lot of things that need to be there like transactions, security, and connection management.

Well said :-)

[weston.price]

Also, please see

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=106571

This is a top level discussion about combing JBossRemoting and JCA into one project. One of the main goals would be to support JBossESB connectivity requirements both in terms of JCA as well as other aspect of connectivity as a whole.

[marklittle]

JCA support is a definite requirement http://jira.jboss.com/jira/browse/JBESB-415, it's more a case of how in 4.x, versus the 5.0 release of ESB. I'd like to see JCA in ESB 4.2, although it'll definitely be an easier integration path in 5.0.

[bill.burke]

JCA should not be a problem for 4.2. I know how it could be done based on the current code base.

[burrsutter]

JCA inbound or outbound in 4.2?

Assuming outbound means that the ESB can use the JCA container/adapter to then make connections to the outside world (e.g. database, SAP, whatever) then the new 4.2 ESB Server should be capable.

However, if inbound means something akin to the current/planned listeners/gateways (FTP, JMS, SOAP, HTTP(S), RMI, File, Hibernate, etc) then I'm not so sure about that item.

Do I have the correct understanding of inbound vs outbound? And for the inbound ones, where do we get them and/or how hard is it to re-write them?

Burr

[weston.price]

And for the inbound ones, where do we get them and/or how hard is it to re-write them?

Same as the outbound: you either build them, or you buy them. Just because we can do outbound JDBC doesn't mean this comes out of the box. This had to be buillt. Inbound follows the same premise.

Currently we support JMS (generic) and POP/IMAP for inbound connectivity. The other types could simply be written as necessary. In some cases this often means wrapping an existing module to conform to the JCA SPI.