Extendable Transports List

[acure]

Hi
It will be usefull to make a transport list extendable without rebuild whole esb.
I think that it need to make CourierFactory and ListenerUtil (and may some other classes) configurable.
But its only my own suggestion.

Acure

[tfennelly]

Sure, I think that would be useful on a number of levels:
1. From a users perspective, it'd be easier to add new transports.
2. From a project perspective, it'd easier to maintain the related code in this area.

I looked at this a while ago, playing around with annotations on the EPR classes for defining the protocols supported by that EPR, plus an "ArtifactFactory" for creating Courier and EPR instances associated with these transports. More however would be needed in the area of the listener configs i.e. supporting the config mappings in an extensible way, or eliminating the need to do mappings all together (the ultimate goal!!).

[marklittle]

An EPR is tied to a specific transport protocol. Maybe you mean annotations on the service definition?

[marklittle]

"acure" wrote:
Hi
It will be usefull to make a transport list extendable without rebuild whole esb.
I think that it need to make CourierFactory and ListenerUtil (and may some other classes) configurable.
But its only my own suggestion.

Acure

Yes, you're right: the current architecture is a little restrictive. Look for improvements in this area during 2008.

[tfennelly]

An EPR is tied to a specific transport protocol. Maybe you mean annotations on the service definition?

Nope, I wasn't talking about annotations on the service. I'm just talking about how EPRs are implemented at a code level and how they can be hooked together with their associated couriers etc using a Java annotation on the EPR. A single EPR *implementation* can be written to handle multiple associated protocols.

[marklittle]

I think we're mixing terms then. The EPR format is defined by WS-A and a single instance of that format is tied to a specific protocol. The EPR implementation within the codebase is maybe what you're on about?

I personally think the whole courier approach needs a serious revisit anyway ;-)

[tfennelly]

I think we're mixing terms then. The EPR format is defined by WS-A and a single instance of that format is tied to a specific protocol. The EPR implementation within the codebase is maybe what you're on about?

Yep, I'm just talking about the implementation. It's out implementation that's not extensible and not what an EPR is ala WS-A.

I personally think the whole courier approach needs a serious revisit anyway ;-)

+1,000,000,000,000....

[tfennelly]

"tfennelly" wrote:
It's out implementation that's not extensible and not what an EPR is ala WS-A.

That was confusing lol... what I mean is... the extensibility issue lies with our EPR impl, CourierFactory etc. There's no extensibility issue (that I'm aware of at least) with EPR ala the WS-A spec :-)

[kconner]

I personally think the whole courier approach needs a serious revisit anyway ;-)

It will certainly be 'revisited' for the next major release. :)

[marklittle]

Yes, we have a better EPR implementation hidden away that is also WS-A 1.0 compliant :-)

[marklittle]

Hey Kev, I hadn't realised it was that long ago!

[acure]

Hi
First) - i cant wait :) - than i have to do it. Do you have some advices ? Did you think about this - how to implement more extendable transports?
Second) - jboss esb licence id LGPL - than if i will change source i have to share this changes. How to do it ? I have to solve others task from jboss esb jira too.

Thanks - Antony

[marklittle]

Transports at what level? If it's the gateways, then you can always add more capabilities to JCA: it's just vanilla JCA inflow that we use after all.

If you create JIRAs and attach the code, then the development team will look at it.

[acure]

I have to give new internal transport add possibility. We have a few groups working on projects based on jbossesb with our additions, and specific project's requirements force us to implement new internal transports :/. This is a reason that we have to do as fast as possible - that means "ourself".

Acure