Nobody is suggesting that OSGi is a bad choice for your scenario. It's just that there is nothing in your scenario that particularly requires OSGi -- everything is fairly easily achievable with other, perhaps more mainstream, technologies.
Therefore the case to make to your boss must focus on the general benefits of OSGi, i.e. modularity, ease of deployment and management, reuse, etc. Regards Neil On Tue, Mar 2, 2010 at 2:41 PM, Abhishek kapoor <[email protected]> wrote: > > Hi All, > > My apologies, but so far I have received responses with suggest not to use > OSGI for future development, please accept my humble request to explain why > we should not adopt OSGI for future architecture of our application. > > Thanks > San > > > On Tue, Mar 2, 2010 at 7:43 PM, Landry Stephane Zeng Eyindanga > <[email protected]> wrote: >> >> Hello, >> Actually, JOnAS is the best way to easily conciliate OSGi, and J2EE >> worlds. >> It also offers many J2EE an OSGi technical services that could help you. >> >> Le 3/2/2010 1:49 PM, Miguel a écrit : >> >> start stop processes can be a method with an id argument... threads can be >> stored in a list, hash or similar ... >> It should be better than a bundle for each process ... in my opinion it is >> a little weird what you comment .. >> Miguel >> >> >> On Tue, Mar 2, 2010 at 1:15 PM, Abhishek kapoor >> <[email protected]> wrote: >>> >>> Hi Chris, >>> >>> Thread pooling can sort some of the issues but we need the facility to >>> start and stop the process independently. >>> Also it will be great to reload the process again with some change and >>> not to mention versioning between bundles with changes etc.. >>> >>> Thanks >>> San >>> >>> Thanks >>> >>> On Tue, Mar 2, 2010 at 5:13 PM, Christopher Armstrong >>> <[email protected]> wrote: >>>> >>>> Why not move the code into the same process, and run each as a separate >>>> thread? There are plenty of thread pooling technologies about. >>>> Bundles don't run in OSGi like processes, they have a "start" and "stop" >>>> method, but if they are to run an active task, they will need to start up a >>>> thread for themselves anyway (which is effectively what happens when you >>>> create a process in the operating system - it starts your process with one >>>> thread ( the main thread) and executes your code on it until the thread >>>> exits). >>>> >>>> Cheers >>>> Chris >>>> On 02/03/2010, at 22:20 PM, Abhishek kapoor wrote: >>>> >>>> Hi Chris, >>>> >>>> Thanks for your time and comments. >>>> What I meant by single process per JVM is. At the moment we use, lets >>>> say process A which fetch data from DB and process accordingly. We initiate >>>> a JVM for the respective process [that is a instance of JVM is booted for >>>> that process]. We do similar thing for atleast 30 process, that create 30 >>>> instance for JVM, so in-order to avoid one instance of JVM per process, i >>>> thought why not incorporate in osgi framework by creating bundle per >>>> process >>>> instead new JVM instance. >>>> >>>> Application is back middle system so i don't understand the need J2EE >>>> stack for it. >>>> >>>> Hope this time I am much clear. >>>> >>>> Thanks >>>> San >>>> >>>> >>>> On Tue, Mar 2, 2010 at 4:15 PM, Christopher Armstrong >>>> <[email protected]> wrote: >>>>> >>>>> Hi >>>>> I don't know what you are looking for from this list, but you are >>>>> unlikely to find it. >>>>> At a quick glance, the requirements you mention below could be easily >>>>> fulfilled by a enterprise J2EE stack or written into a lightweight >>>>> container >>>>> framework like Spring. >>>>> Why do you need OSGi? >>>>> You are also unclear on what you mean by "a separate process per JVM". >>>>> All Java applications, including a running OSGi framework, use one process >>>>> per JVM instance. If you mean a single process per requirement, that still >>>>> is not unusual - using something like JMS for integration would fit well >>>>> with such an architecture. >>>>> Cheers >>>>> Chris >>>>> On 02/03/2010, at 20:59 PM, Abhishek kapoor wrote: >>>>> >>>>> Dear Member, >>>>> >>>>> Thanks for reading this email. I need your kind help regarding >>>>> convincing my manager to adopt OSGI in our future development. >>>>> >>>>> Below is the current application architecture >>>>> >>>>> We are telecom company and at the moment we use separate JVM per >>>>> process for our middleware for Order management system. >>>>> >>>>> Below are the general overview of the all the process >>>>> >>>>> 1) Fetch data [ JDBC]from DB do some processing insert the >>>>> processed data into DB >>>>> 2) One of the process send data outside our system through >>>>> webservice >>>>> 3) One of the process receive data from outside and pushes into DB >>>>> so that our internal process can work accordingly >>>>> 4) Each process polls the data at given specified time for it >>>>> processing >>>>> >>>>> 5) Each process also use extensive logging >>>>> >>>>> Since it is a legacy system I do understand the above mentioned process >>>>> flow is horrible. I guess in past developers decided single process per >>>>> JVM >>>>> to achieve modularity. >>>>> >>>>> >>>>> >>>>> Any Help is appreciated >>>>> >>>>> Any case history related to telecom to convince my manager will highly >>>>> beneficial >>>>> >>>>> >>>>> >>>>> Thanks >>>>> >>>>> San >>>>> >>>>> _______________________________________________ >>>>> OSGi Developer Mail List >>>>> [email protected] >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>> >>>>> -------- >>>>> Christopher Armstrong >>>>> [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> -------- >>>> Christopher Armstrong >>>> [email protected] >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> -- >> ZENG EYINDANGA Landry Stephane, >> Ingénieur Développement, >> Bull Service, Section R&D, >> équipe Java Entreprise Middleware, >> Echirolles, >> Tél:04 76 29 72 07 >> >> _______________________________________________ >> 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 > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
