For a bit of a broad view of OSGi, what it is, where its from, why it is interesting, check out Chapter 1 [1] of the OSGi and Equinox book [2]. The latter part talks about NASA's adoption of OSGi in both client and server settings. You might also look at the Foreword by Adrian Colyer. It talks about why SpringSource adopted OSGi
Jeff [1] http://equinoxosgi.org/OSGi%20and%20Equinox%20-%20Ch01.pdf [2] http://equinoxosgi.org On 2010-03-02, at 9:41 AM, Abhishek kapoor 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
