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]
