[burrsutter]

Actions vs Services for naming...

From the user's perspective Actions are not unique since they can be reused from service to service by wiring in via the jboss-esb.xml.

EPRs are "invisible" to the end-user (the developer/admin using the JBoss ESB).

Kurt said a "service instance" are unique, can have multiple per EPR and you can have multiple EPRs per registered service. So that is a little bit hard to grok but might be the closest suggestion to solving the problem.

Our administrator's goal is to handle a few basic situations:
- What things are running? (what is this unique thing we are trying to describe)
- What things are not running (or are generally unhappy)?
- What do I do to go fix the thing? Hence having the .esb name and access to the jboss-esb.xml that configured the offending "thing" is very important (relates to Tom F's suggestion).

The "thing" (from a user's perspective) is a "service", not an "action", not an "esb archive", not an "EPR" (never seen an EPR).

[burrsutter]

I would suggest we have a "nick name" option as the concatenation trick could become a big problem when displayed in a list view inside a web GUI.

[marklittle]

"burrsutter" wrote:
Actions vs Services for naming...

From the user's perspective Actions are not unique since they can be reused from service to service by wiring in via the jboss-esb.xml.

Yes, but within a deployment, the combination of esb instance, service name, action name and action instance name will be unique.

EPRs are "invisible" to the end-user (the developer/admin using the JBoss ESB).

Kurt said a "service instance" are unique, can have multiple per EPR and you can have multiple EPRs per registered service. So that is a little bit hard to grok but might be the closest suggestion to solving the problem.

Our administrator's goal is to handle a few basic situations:
- What things are running? (what is this unique thing we are trying to describe)

That's definitely a service, but our services model is based on action chaining. Which is why I think TomC was interested in also monitoring and reporting on Actions. Developers do see Actions ;-)

- What things are not running (or are generally unhappy)?

That's services, but as a user with services that have N actions, I'd like to have information on those individual actions. Finer grained.

- What do I do to go fix the thing? Hence having the .esb name and access to the jboss-esb.xml that configured the offending "thing" is very important (relates to Tom F's suggestion).

Agreed.

The "thing" (from a user's perspective) is a "service", not an "action", not an "esb archive", not an "EPR" (never seen an EPR).

It's a service that contains Actions that we may like to see reports on.

[marklittle]

"burrsutter" wrote:
I would suggest we have a "nick name" option as the concatenation trick could become a big problem when displayed in a list view inside a web GUI.

Let's agree *what* before *how* ;-)

[tcunning]

"burrsutter" wrote:
Actions vs Services for naming...

From the user's perspective Actions are not unique since they can be reused from service to service by wiring in via the jboss-esb.xml.

Yes, but within a deployment, the combination of esb instance, service name, action name and action instance name will be unique.

I'm not wholly against the concatenation approach, but it :

a) should be short as possible
b) should be something the users will recognize (and I think the most recognizable piece of information is the esb instance name)

Do we need both the action name and the action instance name? Shouldn't we be able to get by with just one of these, since the instance name should be unique within the particular service?

With the nickname approach is it possible to enforce uniqueness across nodes, or would the "nickname" only be unique within a particular node?

[tfennelly]

"tcunning" wrote:
Do we need both the action name and the action instance name? Shouldn't we be able to get by with just one of these, since the instance name should be unique within the particular service?

Yeah, I was wondering about that too. Surely the action name is all that's needed and that only needs to be unique on a per service basis, right?

"tcunning" wrote:
With the nickname approach is it possible to enforce uniqueness across nodes, or would the "nickname" only be unique within a particular node?

Personally I think the nickname will drive people bats because they'll need to perform some form of translation/mapping. I'd think that the name people see should be all they need to have to take them directly to the service/action definition in question i.e. no translation required.

[marklittle]

"tfennelly" wrote:

"tcunning" wrote:
Do we need both the action name and the action instance name? Shouldn't we be able to get by with just one of these, since the instance name should be unique within the particular service?

Yeah, I was wondering about that too. Surely the action name is all that's needed and that only needs to be unique on a per service basis, right?

So you're saying that you will never want to deploy multiple actions of the same type within the same chain? Seems like an artifical limitation, but maybe I'm missing something ;-)?

As long as the instance name contains enough information to identify the type of the action, then I don't see a problem. What I was thinking in terms of:

<action type>:<action instance id>

was that the action type might be something meaningful like DebugAction, whereas the action id could be a UID.

But all of this is syntactic sugar. As long as we can uniquely and meaningfully identify actions within a chain!

"tcunning" wrote:
With the nickname approach is it possible to enforce uniqueness across nodes, or would the "nickname" only be unique within a particular node?

Personally I think the nickname will drive people bats because they'll need to perform some form of translation/mapping. I'd think that the name people see should be all they need to have to take them directly to the service/action definition in question i.e. no translation required.

Yes, I agree. That's what I meant earlier when I said that however we name/identify these things has got to be done so that the user can immediately see what's going on. We don't want any of "OK, so BARFOO is the nickname; let me pop up my editor and check the esb.xml and see what that relates to" ;-)

[tfennelly]

So you're saying that you will never want to deploy multiple actions of the same type within the same chain? Seems like an artifical limitation, but maybe I'm missing something ;-)?

I think what you're missing is the difference between the actions "name" and "class". One should be allowed to have multiple action instances having the same "class" attribute value on a single action pipeline, but each of these must have a unique "name" for that chain e.g. in the following action chain, we have 2 transformers with the same "class", but different "name"s. The "name" is what we could use in the global version of this actions name.

 <action name="transform_01" class="org.jboss.soa.esb.actions.converters.SmooksTransformer">
 <property name="resource-config" value="/smooks-res_01.xml" />
 </action>

 <action name="my_blah_action" class="com.acme.SomeOtherAction" />

 <action name="transform_02" class="org.jboss.soa.esb.actions.converters.SmooksTransformer">
 <property name="resource-config" value="/smooks-res-02.xml" />
 </action>

[tcunning]

Yes - this what I was trying to get at - transform_CSV2XML is another good example - two SmooksTransformers and two SystemPrintln actions within the same service.

The problem I see is that we don't enforce uniqueness on either <action name="XXX" .../> within a service or <service name="YYY" .../> within a .esb - for example :

<actions>
 <action name="print" class="org.jboss.soa.esb.actions.SystemPrintln">
 <property name="message" value="[transform_CSV2Smooks_Intermediate_format] Message before CVS to XML transformation" />
 </action>
 <action name="print" class="org.jboss.soa.esb.actions.SystemPrintln">
 <property name="message" value="[transform_CSV2Smooks_Intermediate_format] Message before CVS to XML transformation" />
 </action>
</actions>

Both actions have the name "print", and this deploys and runs fine. I think that's going to be confusing to the user, and we should probably start enforcing uniqueness at deploy-time.

[tfennelly]

Right, but I think it only needs to be unique on a per service/action-chain basis, right? You should be able to have the same action on 2 different chains e.g. "transform_CSV2XML" on 2 different action chains within the same dot esb. Globally, they'd be qualified by their containing service category+service name, which would be unique within the scope of the .esb (right?).

Yeah, so we need to enforce uniqueness wherever we need to.

[tcunning]

Agreed.

[marklittle]

"tfennelly" wrote:
I think what you're missing is the difference between the actions "name" and "class". One should be allowed to have multiple action instances having the same "class" attribute value on a single action pipeline, but each of these must have a unique "name" for that chain e.g. in the following action chain, we have 2 transformers with the same "class", but different "name"s. The "name" is what we could use in the global version of this actions name.

Yes, I'd forgotten about the name in the xml config. That makes it easier to do the class name/instance name automatically.

"tfennelly" wrote:
Right, but I think it only needs to be unique on a per service/action-chain basis, right? You should be able to have the same action on 2 different chains e.g. "transform_CSV2XML" on 2 different action chains within the same dot esb. Globally, they'd be qualified by their containing service category+service name, which would be unique within the scope of the .esb (right?).

Yeah, so we need to enforce uniqueness wherever we need to.

However, I think we need to be careful about making statements concerning *global uniqueness* based on service category and service name when we don't have a formal policy for federated registries yet.

So it sounds like we have the information for uniqueness within an ESB deployment that we covered earlier today. So now do we go back to the issue of nicknames ;-)?

[tfennelly]

However, I think we need to be careful about making statements concerning *global uniqueness* based on service category and service name when we don't have a formal policy for federated registries yet.

+1

So it sounds like we have the information for uniqueness within an ESB deployment that we covered earlier today. So now do we go back to the issue of nicknames ;-)?

Well is the only issue with the length of the "formal" name one of displaying it (and hence the need for a "nickname")? If so, then is it not just a display issue? For displaying on a UI, perhaps the name could be abbreviated to just the action name and use some funky AJAX thingy (or whatever) to popup the "formal" name on mouseover (or whatever). For printing, I don't think you could use a nickname because that would require manual translation back to the formal name.

[marklittle]

"tfennelly" wrote:
Well is the only issue with the length of the "formal" name one of displaying it (and hence the need for a "nickname")?

Possibly. I think it was Burr or TomC who mentioned it.

If so, then is it not just a display issue? For displaying on a UI, perhaps the name could be abbreviated to just the action name and use some funky AJAX thingy (or whatever) to popup the "formal" name on mouseover (or whatever). For printing, I don't think you could use a nickname because that would require manual translation back to the formal name.

Yes, I agree. We have to consider all possible ways in which this will be viewed, including hardcopy.