Hello again.
Picking up again on last week's "service naming convention" thread [1], I still have a couple questions:
I understand that using the ServiceSelector can cause issues when a component isn't expecting a selector to be returned. Therefore, we have the following method:
MyService service = (MyService) m_manager.lookup(MyService.ROLE+"/id");
which lets us lookup a specific implementation. Personally I rather like the idea of using MyService.ROLE since it has a feeling of permanence, ie- the service name is part of the "API" and not just some random string. However, I can see that this method doesn't handle some more complex situations which in fact turn up regularly. So properly devised service naming (and the use of meta-info tags) can bring regularity and structure and still handle multiple service implementations. Given this:
1. Which containers support ServiceSelector's? (ECM and Fortress, right?)
Right. Also note that Fortress supports both the selector and the "/id" approach as well.
WIth ECM you had to choose one way or the other. Fortress will allow you to use components that were designed around the Selector approach as well as components that expect a default implementation all in the same application. It tries to give you the best of all worlds to provide a smoother way to migrate.
2. For the above containers, one can guarantee the actual lookup of a service object (as opposed to a selector) only if all service names are unique, correct?
In ECM it is decided by the app designer what values return a selector and which ones return the actual service.
In Fortress, there are some rules for interpreting the role.
1) the role itself always returns the default service. (MyService.ROLE)
2) appending "Selector" always returns a ServiceSelector. (MyService.ROLE + "Selector")
3) appending "/" and the service id always returns the specified service. (MyService.ROLE + "/id")
3. When using String names for services, are there any particular advantages to: - [class-name]/[descriptive-name] "org.proj.MyService/store" - [descriptive-name] "store" - url / url "urn:services:store"
In Merlin there is no specific advantage in any one approach. They are all treated equally. In Pheonix as well, these will all work similarly. Fortress only supports the first option, so for FULL compatibility, you should stick to that option.
Reason for asking is that I want to introduce best practices early to new Avalon develops (in my own developer team and via my Avalon tutorial) and also to write container-agnostic components as much as possible. The ServiceManager behavior is a rather important and basic concept in Avalon and it'd be nice to know what "always" works regardless of container environment.
Until Fortress gets the assembly features of Phoenix and Merlin, you will have to use the [class-name]/[descriptive-name] approach. I would of course appreciate any updates to the Avalon Developer's Guide....
Thanks!
Welcome.
J. Aaron Farr SONY ELECTRONICS
Cool. What are you working on specifically? Or would you have to shoot me if you told me ;P
DDP-CIM
(724) 696-7653
[1] http://marc.theaimsgroup.com/?l=avalon-users&m=105431696332706&w=2
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- "You know the world is going crazy when the best rapper is a white guy, the best golfer is a black guy, The Swiss hold the America's Cup, France is accusing the US of arrogance, and Germany doesn't want to go to war. And the 3 most powerful men in America are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
