-
1. Re: Uniquely identifying services and actions
marklittle Jul 9, 2007 12:47 PM (in response to tcunning)Unique within what context? Node, ESB Server, globally etc?
-
2. Re: Uniquely identifying services and actions
tcunning Jul 9, 2007 3:05 PM (in response to tcunning)I'm interested in per-ESB Server/AS, we may be interested in globally later.
-
3. Re: Uniquely identifying services and actions
marklittle Jul 9, 2007 3:47 PM (in response to tcunning)A service can be uniquely identified by its EPR. Trouble is that multiple EPRs can point to the same service. Ignoring that for a sec, could you use the EPR?
-
4. Re: Uniquely identifying services and actions
kurtstam Jul 9, 2007 5:00 PM (in response to tcunning)I'm not sure EPR is the way to go as a Service can have multple EPRs, and you can have multiple Service instances listen to the same EPR.
In my opinion we need to pick unique names for our actions within a deployment, as you'd like to do reporting on which specific instance is troublesome, not which (potentially distributed) service. Action names are required in the jbossesb-1.0.1 xsd. -
5. Re: Uniquely identifying services and actions
tfennelly Jul 10, 2007 4:24 AM (in response to tcunning)Couldn't the .esb name also be used as part of the local/global name e.g. "shopping-service.esb". We'd probably need to get the deployer to make it available somewhere, but that wouldn't be a big job.
-
6. Re: Uniquely identifying services and actions
marklittle Jul 10, 2007 4:36 AM (in response to tcunning)"kurt.stam@jboss.com" wrote:
I'm not sure EPR is the way to go as a Service can have multple EPRs, and you can have multiple Service instances listen to the same EPR.
Yeah, I said that ;-)
In my opinion we need to pick unique names for our actions within a deployment, as you'd like to do reporting on which specific instance is troublesome, not which (potentially distributed) service. Action names are required in the jbossesb-1.0.1 xsd.
Yes, that's true. So why not extend the Action interface so they have to report a unique name? Could be class specific or even instance specific, in case you ever want to deploy multiple instances of the same Action within the same chain. -
7. Re: Uniquely identifying services and actions
marklittle Jul 10, 2007 4:37 AM (in response to tcunning)"tfennelly" wrote:
Couldn't the .esb name also be used as part of the local/global name e.g. "shopping-service.esb". We'd probably need to get the deployer to make it available somewhere, but that wouldn't be a big job.
If we're looking to report on individual actions, then I'm not sure this will help. However, Tom did start out asking:
"Do we have a good way of uniquely identifying a service or action?"
so maybe the first thing to agree on is what we want to identify: service, action or both. -
8. Re: Uniquely identifying services and actions
tfennelly Jul 10, 2007 5:03 AM (in response to tcunning)"mark.little@jboss.com" wrote:
"tfennelly" wrote:
Couldn't the .esb name also be used as part of the local/global name e.g. "shopping-service.esb". We'd probably need to get the deployer to make it available somewhere, but that wouldn't be a big job.
If we're looking to report on individual actions, then I'm not sure this will help.
It would help because it's unique on a per AS/esb-service instance. It would help because it helps a reader of any report/log to narrow down to the .esb instance. Before you the service/listener/action name can mean anything, you surely need to know this (context).
Then on a per .esb instance, the service/listener/action needs to be uniquely identified. -
9. Re: Uniquely identifying services and actions
marklittle Jul 10, 2007 5:22 AM (in response to tcunning)"tfennelly" wrote:
"mark.little@jboss.com" wrote:
"tfennelly" wrote:
Couldn't the .esb name also be used as part of the local/global name e.g. "shopping-service.esb". We'd probably need to get the deployer to make it available somewhere, but that wouldn't be a big job.
If we're looking to report on individual actions, then I'm not sure this will help.
It would help because it's unique on a per AS/esb-service instance. It would help because it helps a reader of any report/log to narrow down to the .esb instance. Before you the service/listener/action name can mean anything, you surely need to know this (context).
Then on a per .esb instance, the service/listener/action needs to be uniquely identified.
OK, but this comes back to my question: what are we trying to identify? If it's *just* the Actions then we don't need this. If it's *just* the services then this helps. However, I think it should be *both* Actions and services (either together or individually). I'd have thought an Action should be identified within the scope of the service in some hierarchical manner. For example:
:
or
<ESB instance>::<action type>:<action instance>
The latter just in case we want to differentiate between multiple instances of the same Action within a service.
If that's the case then what you mention would be the <ESB instance>, right? -
10. Re: Uniquely identifying services and actions
marklittle Jul 10, 2007 5:23 AM (in response to tcunning)OK, once again and this time trying to get the formatting right ;-)
<service>:<action> or <ESB instance>:<service>:<action type>:<action instance>
-
11. Re: Uniquely identifying services and actions
tfennelly Jul 10, 2007 6:00 AM (in response to tcunning)hehehe, I think we're playing word games again ;-)
For sure, the names would be hierarchical and the .esb name would be beside the service name and not the action name. For what I was suggesting, yes "ESB Instance" would simply to represented by the name of the .esb. It's already unique so there's no need to invent another name - and anyway, another name (e.g. defined in the .esb jboss-esb.xml config) wouldn't help someone trying to track back from a report to the actual service/action definition. -
12. Re: Uniquely identifying services and actions
tfennelly Jul 10, 2007 6:03 AM (in response to tcunning)Of course in a clustered env, that hierarchical name would need to be qualified further e.g. with a cluster node name e.g. something like:
"node1:shopping-service.esb:order-acceptance-service:route-to-xxx-action" -
13. Re: Uniquely identifying services and actions
marklittle Jul 10, 2007 6:06 AM (in response to tcunning)"tfennelly" wrote:
hehehe, I think we're playing word games again ;-)
You'll have to explain that to me one day ;-)
For sure, the names would be hierarchical and the .esb name would be beside the service name and not the action name. For what I was suggesting, yes "ESB Instance" would simply to represented by the name of the .esb. It's already unique so there's no need to invent another name - and anyway, another name (e.g. defined in the .esb jboss-esb.xml config) wouldn't help someone trying to track back from a report to the actual service/action definition.
Agreed. I hadn't thought of the instance name until your posting. If it's there already we should use it. -
14. Re: Uniquely identifying services and actions
marklittle Jul 10, 2007 6:08 AM (in response to tcunning)"tfennelly" wrote:
Of course in a clustered env, that hierarchical name would need to be qualified further e.g. with a cluster node name e.g. something like:
"node1:shopping-service.esb:order-acceptance-service:route-to-xxx-action"
Yes, good point. So some of this information we can get automagically (as long as we make sure the user can do the mapping of what we use back to the "physical" process/instance) and some of it will require the developer's input, e.g., Action class name, action instance name/id.