Request the authorities to pls remove me from the list. OSGI is of no more use to me..
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Peter Kriens Sent: Friday, March 02, 2012 3:45 PM To: [email protected]; OSGi Developer Mail List Subject: Re: [osgi-dev] Design Question I think you're on the right way. The key problem you're facing is instantiation. DS components can made in such a way that the require a configuration (configurationPolicy=require). By using managed service factory Configurations you can configure each instance. This allows you to use Configuration Admin to control instances of DS components, including specifying the filters of the references. So I would translate your processes to DS component that register services and depend on services. You have to choose if a service is an input or an output. This is the eternal sink/source problem. In a push model the DS component registers a service that is accepting input (i.e. void methods with parameters). In the pull model the service is a source and is called (i.e. no parameter methods with a return value). public Push { void out(Object o); } public Pull { Object in(); } With the push model you need a source that can generate initial values and with the pull model you need to ask for a result that then ripples back. You can then put your nets in a bundle in a standard location like OSGI-INF/nets/*.xml An extender bundle then detects a net bundle and reads the XML. It then translates the XML to Configuration Admin Configurations, making sure the components are wired up as defined in the XML. You probably need a unique identifier for the net and then make sure each service that is registered uses that unique id and make sure any references are also link to other services of this unique id. If the bundle is uninstalled, the extender removes the Configurations. Hope this helps. Kind regards, Peter Kriens > a) How can these processes be instantiated from a XML file as DS components? You could translate > b) Is is feasible to model typed ports as services? How would then the > "channel" over which the communication happens look like? > c) The whole net of processes as one bundle? > d) Perhaps you would model this in a totally different way? On 2 mrt. 2012, at 06:26, Michael Köndling wrote: > Hello, > > since I'm new to OSGi I would like to ask the experts a few questions on a > design question. > > We have a Java-based data-flow system which consists of processes > (technically threads) which have typed input and output ports. There are > various types of these processses, like read-, write-, compound-, and > filter-processes. The type of the input port determins which data structure > the process can handle. > There is a XML file which describes a configuration - a net - of these > processes. Some "Configurator" reads the XML file, instantiates and starts > these processes. > > Except some reader which is reading from a data-source immediately, the other > threads are blocked until they receive data through a channel (connection of > input and output port). Processes block if the channel is empty while reading > or the channel is full while writing. Since a process could receive from any > other process on its input-port this adds nondeterminism to the whole system. > > The runtime environment should be able to handle many nets of these processes. > Now, we have the task to "port this to osgi". > > Using DS I would map in this way: > > Net -> Bundle > Process -> DS Service Component > Port of Process -> Service provided/required by DS Service Component > > The questions for me then are > a) How can these processes be instantiated from a XML file as DS components? > b) Is is feasible to model typed ports as services? How would then the > "channel" over which the communication happens look like? > c) The whole net of processes as one bundle? > d) Perhaps you would model this in a totally different way? > > Would appreciate any help on this. > Thank you in advance! > Michael > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
