<snip/> ><dependencies> > <dependency key="first-key" source="../comp"/> > <dependency key="second-key"> > <select feature="color" value="red" match="equals"/> > <select feature="publisher" value="ASF" match="exists" optional="true"/> > </dependency> ></dependencies>
<snip/> > This covers two approaches (a) delection by named source component, and > (b) selection by filtering againt a criteria. The first option is based > on your suggestion with a small change to the attribute name (I chose to > use "source" instead of "provider" simply because at this point in the > process the provider is resolved relative to a source address - the term > provider is more applicable to the comoosition/model package where we > are dealiong with actual solutions). If a source address is not > declared, selection constraints kick-in. If there are not selection > constraints, then life containes as per normal auto-assembly semantics. > > This should cover both of our requirements. Looks GREAT! Thanks! > > Let me know if you see any problems (or suggestions for improvement, etc.). Selecting a service provider based upon attributed features is perhaps better expressed through some form of scripting rather than pure XML, maybe consider Jelly script, Velocity or something. This would give Avalon service selection equivelent cabapilities as EJB-QL. Provide javadoc tag where the query could be expressed and then pass through to the xinfo after doing some syntactical verification on the query? I have a some fundamental questions about the role/responsibility ServiceSelector will play in the larger scope of things. As I see it, ServiceManager/ServiceSelector is equivalent to CORBA NamingService/TradingService or Java's JNDI/JXTA. ServiceSelector is a much more complex system component than ServiceManager in that compile-time attributes, deployment attributes, context attributes, runtime attributes, etc. may all contribute to how a service is chosen. CORBA's TradingService, SOAP's UDDI, and JXTA's PeerGroup each have unique ways of advertising services as well as searching for services based on criteria. How will ServiceSelector and Avalon MetaData fit into this larger scope? I think it would be possible for a container implementation to integrate different ServiceSelector implementions to provide the greatest flexibility in service-to-service communication. Thoughts? > > Cheers, Steve. > > p.s. The composition package is not part of the Merlin runtime just yet. When might we expect this to be added to the runtime? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
