[marklittle]

But whatever happy medium you guys come up with, just make sure it's documented and in place yesterday ;-)

[tfennelly]

But whatever happy medium you guys come up with, just make sure it's documented and in place yesterday ;-)

hehehe

I'm cool with whatever people find easiest to use - that's my goal (plus validation etc of course).

I just think that the point at which we have it now is a good balance between having it humanly understandable and manageable, yet normalised enough to eliminate most problems caused by duplication.

Of course, we can't tell until we get feedback from a broader range of people - I'm the only one that's really played with the current model while Kurt came up with the original - as the saying goes, "2 points don't make a curve".

I personally would like to get some user feedback before bringing it any further. If then, we get a clear message asking for more normalisation, I'd be more than happy. Before we decided to make yesterdays forum post, this is actually what Kurt, Dave and I had agreed. I personally think that the extra normalisation is something that's easier to add than take away. Also, whatever option we take, do we really think we'll never have to come back to this again i.e. we're going to get it right first time?

[marklittle]

I think you missed a smiley on that last sentence ;-)

[tfennelly]

I think you missed a smiley on that last sentence ;-)

Ah no, I saw that alright and thought it was great ;-) Sure I already have it done, that's why I'm taking the line I've been taking :-)

[tfennelly]

"tfennelly" wrote:

I think you missed a smiley on that last sentence ;-)

Ah no, I saw that alright and thought it was great ;-) Sure I already have it done, that's why I'm taking the line I've been taking :-)

heheh... were you saying I forgot to add one on mine, or I didn't see the one you had on yours?

[marklittle]

If it's implemented in a certain way now, then that has my vote for this release, purely because it's done (and I assume tested ;-) However, if you guys want to debate this some more please do so: just don't too long ;-)

[tfennelly]

----------------------------------------------------------------------------------------------------------------------------
(Above is the line drawn under this discussion *for now* )

:-)

[marklittle]

And it's such a pretty line too ;-)

[kurtstam]

I really don't like leaving the configuration denormalized, but I have taken Tom's arguments to heart and I think I have found the 'happy medium'. In it I have simply nested the host/server/service. I think this flows much better and I think it is very close to what Tom was already working on but taking it one step up in the hierarchy (bringing hosts and servers back).

<hosts>
 <host name="filebank" dnsName="localhost">
 <servers>
 <server name="fileBankServer" host="fileBank">
 <properties>
 <property name="java.naming.provider.url" value="localhost:1099"/>
 <property name="java.naming.factory.initial" value="org.jnp.interfaces.NamingContextFactory"/>
 <property name="java.naming.factory.url.pkgs" value="org.jboss.naming:org.jnp.interfaces"/>
 </properties>
 <buses>
 <bus name="bank-jms-channel" server="fileBankServer" resourceType="QUEUE" userName="" password=""/>
 <bus name="bank-ftp-channel" server="inhouse-jboss-4.0.4" resourceType="FTP" userName="kurt" password="secret"/>
 </buses>
 <services>
 <service name="filebank-gateway" category="gateway" server="loanbroker-listener" description="This listener picks up files deposited by the fileBank"
 class="org.jboss.soa.esb.FileBankGateway">
 <listeners>
 <listener description="A File-Based listener" bus="bank-ftp-bus"/>
 <listener description="A JMS-Based listener" bus="bank-jms-bus"/>
 </listeners>
 <actions>
 <action name="TestDefaultRouteAction" process="route" class="org.jboss.soa.esb.actions.CbrProxyAction" service-category="MessageRouting"
 service-name="ContentBasedRoutingService" />
 </actions>
 </service>
 </services>
 </server>
 <server name="inhouse-jboss-4.0.4">
 <properties>
 <property name="java.naming.provider.url" value="localhost:1099"/>
 <property name="java.naming.factory.initial" value="org.jnp.interfaces.NamingContextFactory"/>
 <property name="java.naming.factory.url.pkgs" value="org.jboss.naming:org.jnp.interfaces"/>
 </properties>
 <services>
 </server>
 <server name="loanbroker-listener" host="loanbroker"/>
 </servers>
 </host>
 <host name="jmsbank" dnsName="localhost"/>
 <host name="loanbroker" dnsName="localhost"/>
 <host name="jms-provider" dnsName="localhost"/>
 </hosts>

So for instance the jndi information for the service or bus is simply found in the encapsulating server element.

Question, should a 'bus' be a type of service? I tend to think it is actually.

--Kurt

[tfennelly]

OK, we're back! But this time we can say we have truely reached a consensus. Kurt is going to add his name to this once he comes back from lunch - he promised :-)

So we've finally agreed on an approach that keeps both of us happy. We had a very detailed negotiation and we're both happy campers now. This doesn't undo any of the work we've been doing.

The config has 2 main sections - "providers" and "services". The providers section encapsulates the bus/channel info (we both hate the name "bus" here :-) ). Basically they're "Bus Providers" and there can be different types - JMS, FTP etc. The "services" section then defines the services - their Gateway and ESB Aware Listerns, Actions etc. The listeners reference whatever bus/channel it is that they receive messages on. Simple as that :-)

<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.xsd">

 <providers>
 <jms-provider connection-factory="com.xyz.provider.XYZConnectionFactory"
 jndi-context-factory="....jboss"
 jndi-URL="xyz://server1:9876" jndi-pkg-prefix="com.xyz">

 <jms-bus busid="x-queue">
 <jms-message-filter dest-type="QUEUE" dest-name="queue/A" selector="service='Reconciliation'" />
 </jms-bus>
 <jms-bus busid="service-queue">
 <!--
 See how we add a JMS selector to this filter at the listener level. Look
 for listeners that use the "service-queue" bus.
 -->
 <jms-message-filter dest-type="QUEUE" dest-name="XYZ" />
 </jms-bus>
 </ms-provider>

 <jms-provider connection-factory="com.xyz.provider.XYZConnectionFactory"
 jndi-context-factory="....activemq"
 jndi-URL="xyz://server1:9876" jndi-pkg-prefix="com.xyz">

 <jms-bus busid="y-queue">
 <jms-message-filter dest-type="TOPIC" dest-name="topic/Z" />
 </jms-bus>
 </ms-provider>

 <ftp-provider some-ftp-provider-prop="blah-ftp-prop" ..... >
 <!--
 See how we specify a filter for this FTP bus at the listener level. Look
 for listeners the use the "blah-ftp-bus" jus.
 -->
 <ftp-bus busid="blah-ftp-bus" some-ftp-bus-param="x"/>
 </ftp-provider>

 </providers>

 <services>
 <service category="Bank" name="Reconciliation" description="Bank Reconciliation Service">

 <listeners>
 <!-- Gateway Listeners -->
 <jms-listener name="Reconciliation-JMS-Gateway"
 is-gateway="true"
 busidref="x-queue"
 maxThreads="1"/>
 <ftp-listener name="Reconciliation-FTP-Gateway"
 is-gateway="true"
 busidref="blah-ftp-bus">
 <ftp-message-filter dir="reconciliation" />
 </ftp-listener>

 <!-- The Service Listener -->
 <jms-listener name="Reconciliation-Service"
 is-gateway="false"
 busidref="service-queue"
 maxThreads="2">
 <jms-message-filter selector="service='Reconciliation'" />
 </jms-listener>
 </listeners>

 <actions>
 .......
 </actions>

 </service>
 <service category="Bank" name="Auditing" description="Bank Auditing Service">

 <listeners>
 <!-- Gateway Listeners -->
 <jms-listener name="Auditing-JMS-Gateway"
 is-gateway="true"
 busidref="y-queue"
 maxThreads="1"/>
 <ftp-listener name="Auditing-FTP-Gateway"
 is-gateway="true"
 busidref="blah-ftp-bus"
 busidref="blah-ftp-bus">
 <ftp-message-filter dir="auditing" />
 </ftp-listener>

 <!-- The Service Listener -->
 <jms-listener name="Auditing-Service"
 is-gateway="false"
 busidref="service-queue"
 maxThreads="2">
 <jms-message-filter selector="service='Auditing'" />
 </jms-listener>
 </listeners>

 <actions>
 ......
 </actions>

 </service>
 </services>

</jbossesb>

[kurtstam]

OK Here is a dotted line for you:

Kurt
.............................................................

with my signature ;)

[dmarchant]

Not to bring up the whole configuration concepts up again but what about generalizing the providers and listeners?

The reason I say this is that as you start to experiment with different listeners (protocols and transports) the way to configure them should be easy to add. The listeners especially as this could start to become a large set of variations.


For example, currently the configuration is:

<ftp-provider some-ftp-provider-prop="blah-ftp-prop" ..... >
 <!--
 See how we specify a filter for this FTP bus at the listener level. Look
 for listeners the use the "blah-ftp-bus" jus.
 -->
 <ftp-bus busid="blah-ftp-bus" some-ftp-bus-param="x"/>
 </ftp-provider>

And:

 <jms-listener name="Auditing-JMS-Gateway"
 is-gateway="true"
 busidref="y-queue"
 maxThreads="1"/>

Why not just generalize it to be:

<provider type="ftp" (optionally implementation="com.xyz.MyFTPProvider" )>
 <attribute name="some-ftp-provider" value="22" />
<bus id="blah-ftp-bus">
<attribute name="some-ftp-provider" value="22" />
 <message-filter >
 <attribute name="dir" value="Reconcilation" />
 </message-filter>
</bus>
 </provider>

And:

 <listener name="Auditing-FTP-Gateway"
 is-gateway="true"
 busidref="blah-ftp-bus"
 maxThreads="1"/>

Just some thoughts as this would make it consistent across configuring providers and listeners. It also makes the tooling support become easier as you can just have a template of attribtutes for a given provider and listener.

It also cleans up some of the listener/bus code in dealing a little.

Thoughts?

[dmarchant]

Actually change the attributes tagging to be property to go along with the other configuration approaches.

- Dan

[tfennelly]

This is actually supported today.

Any provider can be configured using the base config types.

See GeneratorUnitTest.test_generate_files(), jbossesb_config_01.xml and jbossesb_config_02.xml. jbossesb_config_01.xml uses the specialised types, while jbossesb_config_02.xml uses the base types, yet they are functionally equivalent as far as the core ESB is concerned.

[dmarchant]

Great I will take a look