Hi andrew Really good advice you are getting here. I would advise giving yourself time to look and play with the various options described here. It can be daunting to navigate through the various options. Also take into account your developers who are going to have work with these technologies. Maybe just using something like spring framework which isnt natively directed at osgi environment will be easier for all of your developers to understand and accept. That said osgi excels at modularity and enabling service lookup/(discovery when using remote services) and the life cycle states needed to create a very robust system or even platform of services... but it comes with a willingness to at least try and understand which dependencies you really need and that kind of discipline isnt always what exists in all teams of developers.
I think you are on the right track when looking at osgi and i welcome you as an osgi enthusiast ... sure you will bump your head along the way. Choose what is right for your situation but also what will fit your developer culture. Enjoy the ride Regards Ivanhoe On 17 Sep 2014 9:20 PM, "Dawid Loubser" <[email protected]> wrote: > I didn't know that RS was already in a usable state - thanks for the > comprehensive information Scott! > Lots of new toys to play with :-) > > warm regards, > Dawid > > > On 17/09/2014 21:00, Scott Lewis wrote: > > Hi Andrew, > > > > I suggest you consider a relatively new OSGi enterprise specification > > called Remote Services (RS) [1]. > > > > Short story for Remote Services (why it appears relevant to what you > > are doing): the RS specification provides a way to extend the OSGi > > service registry (i.e. and any of your services) for out-of-process > > access to OSGi services. The specification does this in a completely > > transport-independent way, meaning that implementations can/do use > > existing JAX RS web services, REST+json, binary protocols, JMS, MQTT, > > or any other (e.g. custom) remoting transport, and get all of the > > advantages of using OSGi services without requiring the service host > > or consumer to be permanently bound to any one transport/wire > > protocol/serialization format. > > > > There are two R6 spec-compliant implementations of RS/RSA that I know of: > > > > ECF [2] > > Amdatu [3] > > > > Full disclosure: I'm the ECF project lead and participate in the OSGi > > Enterprise Experts Group (EEG). > > > > My main point above is that you should consider using these emerging > > standards (RS/RSA), as they simplify the use of remoting with OSGi > > services and deal with some fundamental issues: > > > > discovery > > dynamics in remoting/failure-prone environments > > versioning of service APIs > > standardized endpoint description format > > all the other good things that come with using OSGi services (e.g. > > loose coupling of components, multiple mature injection frameworks, > > security, lots of support/experience with OSGi services, etc) > > a standardized management agent (RSA) > > > > These advantages come for 'free' when RS/RSA is used, no matter which > > implementation is used (ECF, Amdatu, or some other). > > > > ECF as RS/RSA implementation > > > > One possible misunderstanding: ECF does not require nor is bound in > > any way to the use of Eclipse, the use of Equinox as OSGi Framework, > > HttpService implementation, or even the use of a particular dependency > > manager like DS or the Apache dependency manager. That is, any/all > > of these and/or others may be used alongside ECF's RS/RSA impl for > > development, testing, and deployment. Further, we now specifically > > support install/usage as Karaf features [4]. > > > > Here is the wiki-based documentation about ECF [5]. One technical > > point of potential value to you is that ECF has an open, modular, and > > documented provider architecture, allowing users to substitute their > > own implementations of the distribution/transport/wire protocol if the > > existing providers (which currently does include JAX RS web services > > in addition to ~6 others created by the ECF team) do not meet your > > security and/or integration needs. > > > > Scott > > > > [1] http://www.osgi.org/Specifications/Drafts > > [2] https://www.eclipse.org/ecf/ > > [3] http://www.amdatu.org > > [4] https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf > > [5] https://wiki.eclipse.org/ECF#OSGi_Remote_Services > > > > On 9/17/2014 9:38 AM, Andrew Beechey wrote: > >> Dear, users Felix Apache, I work for a large financial institution > >> that is looking to move is development from mainframe Cobol cics > >> db2, into distributed Java. The types of applications we need to > >> develop are JAX RS web services accessing a mainframe hosted db2 > >> database. These web services need to perform the classic CRUD > >> actions. I have been investigating OSGi and feel it has much to > >> offer, my problem is I have no idea where to start, then I came > >> across ipojo, what I can't seem to find is any mention of ipojo > >> creating JAX RS web services. Is it possible to expose JAX RS web > >> services with ipojo? Where can I find examples and/or tutorials to > >> learn how to develop these types of services with ipojo? > >> > >> Warm regards > >> > >> Andrew Beechey > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
