avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: Doesn't work Re: Using Service / Component Selector in Phoenix
Date Tue, 11 Jun 2002 23:04:43 GMT


Andrei Ivanov wrote:

>Hi Steve, thanks for answer. So far I am using solution when one have to
>modify assembly to switch between implementations. As you pointed out, I am
>using the following approach (let me quote whole picture to make things
>clear):
>
>assembly.xml
>
><block class="com.xxx.Main" name="main">
>    <provide name="block1" role="com.xxx.Service"/>
></block>
>
><block class="com.xxx.DefaultService1" name="block1">
>    ...
></block>
>
><block class="com.xxx.DefaultService2" name="block2">
>    ...
></block>
>-------------------------------------------------
>Main.xinfo
><blockinfo>
>
>  <services>
>    <service name="... contract.for.Main..." version="1.0"/>
>  </services>
>
>  <dependencies>
>    ...
>    <dependency>
>      <service name="com.xxx.Service" version="1.0"/>
>    </dependency>
>  </dependencies>
></blockinfo>
>
>-------------------------------------------------
>DefaultService1.xinfo
>
><blockinfo>
>
>  <services>
>    <service name="com.xxx.Service" version="1.0"/>
>  </services>
>
>  <dependencies>
>    ...
>  </dependencies>
></blockinfo>
>-------------------------------------------------
>DefaultService2.xinfo
><blockinfo>
>
>  <services>
>    <service name="com.xxx.Service" version="1.0"/>
>  </services>
>
>  <dependencies>
>    ...
>  </dependencies>
></blockinfo>
>-------------------------------------------------
>config.xml
><block1>...</block1>
><block2>...</block2>
>
>As you pointed, in this case to switch from "block1" to "block2" to be used
>by "main", one have to simply replace word "block1" with word  "block2" in
>provide clause of "main". So far so good.
>
>Two drawbacks:
>1. if there are many blocks which require "com.xxx.Service" to function, one
>have to replace block1 with block2 in every place in assembly. This is where
>mistakes can happen
>

Yep.

>2. someone who is implementing new block then must have some idea about how
>assembly.xml is constructed and this is bad (requires extra documentation
>and so on).
>

Yep.

>
>Therefore, it will not be bad if only changes in config will be necessary to
>add and select new block which provides com.xxx.Service. Then about second
>approach proposed in your reply:
>
>  
>
>>If you want to do this a composition time, then you would need to
>>declare "top-block" as dependent on two services (using different
>>role names) and during your initialization, your implementation
>>    
>>
>
>Let me "redraw" above, so that you may point if I am mistaken or not:
>
>top-block:
>assembly.xml
>
><block class="com.xxx.Main" name="main">
>    <provide name="top-block" role="com.xxx.TopBlock"/>
></block>
>
><block class="com.xxx.DefaultTopBlock" name="top-block">
>    <provide name="block1" role="role1"/>
>    <provide name="block2" role="role2"/>
></block>
>
>rest of assembly is the same, is it?
>

Correct.

>-------------------------------------------------
>Main.xinfo
>...
>    <dependency>
>      <service name="com.xxx.TopBlock" version="1.0"/>
>    </dependency>
>
>I think I may stop here since, as I see it already, it will not work.
>Because there is no way to fetch block1 or block2 inside Main, simply
>because it's component / service manger will not contain block1 or block2...
>

Phoenix can establish block1 and block2 and provide these to top-block. 
 The top-block implementation is basically acting as a proxy and 
directing requests to either block12 or block2 based on the 
configuration supplied policy.  As far as Phoenix is concerning, 
top-block is a perfectly valid cvandidate for supply the service to Main.

I don't see an issue (but I'm working on other things at the same time 
and my have just missing simothing important).

Cheers, Steve.

>
>Andrei
>
>----- Original Message -----
>From: "Stephen McConnell" <mcconnell@osm.net>
>To: "Avalon-Phoenix Developers List" <avalon-phoenix-dev@jakarta.apache.org>
>Sent: Wednesday, June 12, 2002 12:59 AM
>Subject: Re: Doesn't work Re: Using Service / Component Selector in Phoenix
>
>
>  
>
>>Andrei Ivanov wrote:
>>
>>    
>>
>>>Hm, after closer look I see that this solution doesn't work.
>>>It just shows how to use other role names (that class name) but it
>>>      
>>>
>doesn't
>  
>
>>>tell how to select implementations :-(
>>>
>>>      
>>>
>>If I understand you correctly, you want to be able to select which block
>>implementation is going to provide a service to a dependent block.  The
>>routing of the provider to the dependent is declared in the assembly.xml
>>file.
>>
>>  <block class="myDependentBlockClassName" name="top-block" >
>>    <provide name="block-b" role="the-role-for-service-A"/>
>>  </block>
>>
>>This is telling Phoenix to use a block you have named as "blockB"
>>as the component provider of service A.  To switch between "block-a"
>>and "block-c" is basically a matter of updating the mapping in your
>>assembly.xml.
>>
>>If you want to do this a composition time, then you would need to
>>declare "top-block" as dependent on two services (using different
>>role names) and during your initialization, your implementation
>>selects which service it is going to use based on the information
>>contained in the configuration.
>>
>>Hope the helps.
>>
>>Cheers, Steve.
>>
>>
>>    
>>
>>>Andrei
>>>
>>>----- Original Message -----
>>>From: "Stephen McConnell" <mcconnell@osm.net>
>>>To: "Avalon-Phoenix Developers List"
>>>      
>>>
><avalon-phoenix-dev@jakarta.apache.org>
>  
>
>>>Sent: Tuesday, June 11, 2002 4:03 PM
>>>Subject: Re: Using Service / Component Selector in Phoenix
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>The document
>>>>        
>>>>
>>>http://jakarta.apache.org/avalon/phoenix/guide-example-configuration.html
>>>      
>>>
>>>>contains a description of how to handle this inside Phoinix.
>>>>
>>>>Cheers, Steve.
>>>>
>>>>
>>>>Andrei Ivanov wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Hi,
>>>>>I came across with simple problem (I think it is simple for experienced
>>>>>Avalon developers) with my Phoenix-based application.
>>>>>
>>>>>The problem is as follows:
>>>>>I have phoenix service which contract is defined in interface
>>>>>
>>>>>A. ServiceInterface
>>>>>
>>>>>I have two different block which offer service A (in other words
>>>>>
>>>>>
>>>>>          
>>>>>
>>>different
>>>
>>>
>>>      
>>>
>>>>>implementation for the same service):
>>>>>
>>>>>Blocks
>>>>>B. offers A
>>>>>C. offers A
>>>>>
>>>>>B and C should be configured and initialized differently as well as
>>>>>          
>>>>>
>they
>  
>
>>>>>will depend on different services.
>>>>>
>>>>>I would like to be able to specify which block will be used (B or C) to
>>>>>provide service A changing only configuration (config.xml) file.
>>>>>Can anyone give me example how to achieve that and what is the standard
>>>>>practice for Phoenix-based application for this?
>>>>>
>>>>>Regards,
>>>>>Andrei
>>>>>
>>>>>
>>>>>
>>>>>----- Original Message -----
>>>>>From: "Peter Royal" <proyal@apache.org>
>>>>>To: "Avalon-Phoenix Developers List"
>>>>>
>>>>>
>>>>>          
>>>>>
>>><avalon-phoenix-dev@jakarta.apache.org>
>>>
>>>
>>>      
>>>
>>>>>Sent: Monday, June 10, 2002 5:44 PM
>>>>>Subject: Re: Constraints on dependencies
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>On Thursday 06 June 2002 07:43 pm, Peter Donald wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>1. Are constraints container specific or not?
>>>>>>>2. Is there a subset of constraints that are container agnostic?
>>>>>>>3. How do we represent constraints in the system? An opaque string?
A
>>>>>>>Configuration tree? An XPath expression?
>>>>>>>4. Do the providers or the Kernel validate the constraints?
>>>>>>>5. Do the providers get informed that they must conform to certain
>>>>>>>constraints?
>>>>>>>6. Does validation occur at initialization time or assembly time?
>>>>>>>
>>>>>>>My answers would be;
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>1. Sometimes. I haven't seen any container-specific examples yet
>>>>>>            
>>>>>>
>though
>  
>
>>>>>>            
>>>>>>
>>>;)
>>>
>>>
>>>      
>>>
>>>>>>2. Yes. Mainly anything that involves lookup( ROLE ), ie. component
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>assembly
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>3. XPath or other evaluated expression :)
>>>>>>4. Kernel
>>>>>>5. No, but there may be cases where they need to be queried by the
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>kernel
>>>
>>>
>>>      
>>>
>>>>>>            
>>>>>>
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>constraint resolution (like the ORB example. the kernel will most
>>>>>>            
>>>>>>
>likely
>  
>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>be
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>unaware that its ORB component hosts others)
>>>>>>6. Both. As much as possible should be done at assembly, but I'm sure
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>some
>>>
>>>
>>>      
>>>
>>>>>>must be defered to init time.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>The problem is basically that in some cases it is going to be
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>practically
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>>impossible for kernel to validate the constraint unless the provider
>>>>>>>conforms to very specific contracts or is self validating.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>I agree. I'd opt more for the "specific contracts" option, which could
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>be
>>>
>>>
>>>      
>>>
>>>>>>            
>>>>>>
>>>>>as
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>easy as exposing MetaInfo classes.
>>>>>>-pete
>>>>>>
>>>>>>--
>>>>>>peter royal -> proyal@apache.org
>>>>>>
>>>>>>--
>>>>>>To unsubscribe, e-mail:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>><mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>For additional commands, e-mail:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>><mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>--
>>>>>To unsubscribe, e-mail:
>>>>>
>>>>>
>>>>>          
>>>>>
>>><mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>>>
>>>
>>>      
>>>
>>>>>For additional commands, e-mail:
>>>>>
>>>>>
>>>>>          
>>>>>
>>><mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>>>
>>>
>>>      
>>>
>>>>>
>>>>>          
>>>>>
>>>>--
>>>>
>>>>Stephen J. McConnell
>>>>
>>>>OSM SARL
>>>>digital products for a global economy
>>>>mailto:mcconnell@osm.net
>>>>http://www.osm.net
>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>To unsubscribe, e-mail:
>>>>
>>>>
>>>>        
>>>>
>>><mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>>>
>>>
>>>      
>>>
>>>>For additional commands, e-mail:
>>>>
>>>>
>>>>        
>>>>
>>><mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>>>
>>>
>>>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>>      
>>>
><mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>  
>
>>>For additional commands, e-mail:
>>>      
>>>
><mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>  
>
>>>
>>>      
>>>
>>--
>>
>>Stephen J. McConnell
>>
>>OSM SARL
>>digital products for a global economy
>>mailto:mcconnell@osm.net
>>http://www.osm.net
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>>    
>>
><mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>  
>
>>For additional commands, e-mail:
>>    
>>
><mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>  
>
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message