Is it possible for a service to change its SERVICE_RANKING after a  
service request is received by changing its ServiceRegistration  
object and changing this back again after the request has been  
fulfilled? To have some poor mans load balancing?
as per OSGi core: 5.2.7 Locating Services
client: Service = getServiceReferences("heavy.used.service");
Service.doWork();
as per OSGi core: *5.2.3 Registering Services*
server:
doWork(){
myServiceRegistration.setProperty(SERVICE_RANKING, LOW);
workworkwork
myServiceRegistration.setProperty(SERVICE_RANKING, HIGH);
http://www.osgi.org/javadoc/r2/org/osgi/framework/Constants.html#SERVICE_RANKING
Regards,
Wim
On Mon, Apr 26, 2010 at 5:08 PM, Scott Lewis <slewis@xxxxxxxxxxxxx <mailto:slewis@xxxxxxxxxxxxx 
>> wrote:
   Hi Greg,
   Greg House wrote:
       Hello,
       I am moving the discussion
       (http://www.eclipse.org/forums/index.php?t=rview&goto=528121&th=166590#msg_528121
       <http://www.eclipse.org/forums/index.php?t=rview&goto=528121&th=166590#msg_528121 
>
       <http://www.eclipse.org/forums/index.php?t=rview&goto=528121&th=166590#msg_528121
       <http://www.eclipse.org/forums/index.php?t=rview&goto=528121&th=166590#msg_528121 
>>)
       to the mailing list as requested by Scott.
       Sorry if this e-mail is too long. I will explain the use-case
       I am trying to implement.
       Consider two or more OSGi platforms. Each platform exports
       (remote) services that the other platforms can use.
       At any time a new platform can appear (or disappear) and the
       other platforms should be able to see and use the new services
       without any additional
       configuration or restart.
       Because some of the services are expensive and time-consuming
       operations I want to be able to deploy them on
       several machines and the requests to these services to be
       load-balanced. In addition, I want to be transparent for a
       consumer
       if a local or a remote service is used. I don't want in my
       code to import any OSGi packages.
       For the platform and remote services implementations I am
       using Equinox and ECF.
       Now I know that if we remove the load-balancing requirement
       all this can be implemented with (remote) declarative  
services.
       Moreover, the distribution and discovery providers can be
       independently selected.
       However, the OSGI specification does not say anything about
       load-balancing, so one has to use some “nonstandard”  
approach and
       stick to specific distribution and discovery providers (and
       external components) – is my understanding correct?
   Yes.
       The ECF has a solution to load-balance remote-services with
       JMS/ActiveMQ.
       For my use-cases it is OK to use ECF ActiveMQ provider and
       maintain separate ActiveMQ installations. However, is it
       possible the
       usage of services to be transparent for the consumers? The
       service providers define the properties (local, remote,
       load-balanced)
       of their implementation and the consumers just use the  
services?
   Yes, this is correct.  The load-balanced service usage can be
   transparent for the consumers.
       I tried to convert the
       org.eclipse.ecf.examples.loadbalancing.* examples to
       declarative services and to remove all ECF references from the
       code
       but with no success.
   What went wrong?   I don't immediately see a reason why this
   wouldn't work...for the loadbalancing consumer/client.
       The conversion of
       org.eclipse.ecf.examples.loadbalancing.server to declarative
       services is straightforward.
       About org.eclipse.ecf.examples.loadbalancing.servicehost I
       created the following OSFI-INF/component.xml:
       <?xml version="1.0" encoding="UTF-8"?>
         <implementation class="null" />
         <property name="service.exported.interfaces" type="String"
       value="*"/>
         <property name="service.exported.configs" type="String"
       value="ecf.jms.activemq.tcp.manager.lb.svchost"/>
         <property name="org.eclipse.ecf.containerFactoryArgs">
             tcp://192.168.1.1:61616/exampleQueue
       <http://192.168.1.1:61616/exampleQueue>
             tcp://192.168.1.1:61616/exampleTopic
       <http://192.168.1.1:61616/exampleTopic>
         </property>
         <property name="ecf.rsvc.proxy" type="String" value="true"/>
          <service>
            <provide
        
interface="org.eclipse.ecf.examples.loadbalancing.IDataProcessor"/>
         </service>
         <reference cardinality="1..1"
       interface="org.eclipse.ecf.core.IContainerFactory"
       name="IContainerFactory" policy="static"/>
       </scr:component>
       Should I use the service.exported.interfaces property? Is
       <implementation class="null" /> correct?
   I would have to check the ds spec, but no, I don't think that
   'null' is allowable for the implementation class.
       The main problem I have is with
       org.eclipse.ecf.examples.loadbalancing.consumer.
       I created the following OSGI-INF/component.xml file:
       <?xml version="1.0" encoding="UTF-8"?>
         <implementation
        
class= 
"org.eclipse.ecf.internal.examples.loadbalancing.consumer.DataProcessorConsumerApplicationDS" 
/>
         <reference bind="doTests" cardinality="0..n"
        
interface="org.eclipse.ecf.examples.loadbalancing.IDataProcessor"
       name="IDataProcessor" policy="dynamic"/>
       </scr:component>
       Is this somehow related to DefaultProxyContainerFinder and
       should I specify “ecf.jms.activemq.tcp.client” in the  
config file?
   I first have to ask whether you  are using the latest from HEAD or
   ECF 3.2.  The reason I have to ask is that *since* 3.2 release the
   policy for handling automatic creation of containers in
   DefaultProxyContainerFinder has changed as per this bug:
   https://bugs.eclipse.org/bugs/show_bug.cgi?id=303979
   Now (in HEAD/3.3/Helios), the default is to automatically create a
   container instance when discovered.
   *BUT*...even if you are using HEAD....I think that there could be
   a bug in the ActiveMQ/JMS provider.  Specifically, when containers
   are discovered, and the DefaultProxyContainerFinder is consulted
   to find a suitable container, part of what the
   DefaultProxyContainerFinder does (using the auto create option
   that was changed in 303979) is that it gets the meta-data from the
   discovery and looks for a *compatible* container type.  By
   'looks', I mean that it calls this method on container  
instantiatiors:
    
org.eclipse.ecf.core.provider.IRemoteServiceContainerInstantiator.getImportedConfigs( 
ContainerTypeDescription,
   String[])
   And if the provider on the consumer responds with a non-null
   String array, then it has a match.
   But it is quite possible that the JMS/ActiveMQ provider
   implementation of the getImportedConfigs method does not match
   with the load balancing container types (as these are 'special'),
   returns null, and the client container is never created/found by
   the DefaultProxyContainerFinder on the consumer.   Does this fit
   with what you are seeing?   BTW...what discovery mechanism are you
   using?  And do you have evidence that it is working properly on
   your net?
   I will be happy to look into this later today/Monday and fix it if
   necessary, but would it be possible to get your declarative
   services versions of the load balancing example so that I can
   test?  Would you possibly be willing to contribute these projects
   as ECF examples?
       How is "cardinality" handled in the case of load-balanced  
service?
   The cardinality is handled as with a 'normal' declarative
   service...i.e. the cardinality will determine whether the
   component is activated if the given reference is present (1...n)
   or not (0...n).
       I would appreciate any help or directions how to proceed.
   I think the bug with the JMS/ActiveMQ provider I described above
   *may* be the issue.  If you can help me diagnose and test we
   should get it going in short order.
       More important, is my use-case achievable with Equinox and  
ECF?
   Yes, it is.
   Scott
   _______________________________________________
   ecf-dev mailing list
   ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
   https://dev.eclipse.org/mailman/listinfo/ecf-dev
--- 
---------------------------------------------------------------------
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev