You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Andrew Beechey <a....@sky.com> on 2014/09/17 18:38:28 UTC
iPojo : is it right for me?
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
Re: iPojo : is it right for me?
Posted by Dawid Loubser <da...@travellinck.com>.
I would like to second the suggestion to look at Amdatu, as well as the
'warning' that a lot of tutorials are unquestionably Eclipse-biased.
We don't use eclipse at all, and happily build / test all our (complex,
multi-module) OSGi systems with Maven, and the Bundle and Pax plugins,
and code using the IntelliJ IDE. Don't get locked into any particular IDE...
One final suggestion: I'm not sure how serious you are about the
"distributed Java" statement, but if you really are looking into
Distributed computing, OSGi is not the best framework for you. Look at:
* The Rio Project <http://rio-project.org/>, which is built on top of
* Apache River <http://river.apache.org/concepts.html> (formerly
called Jini)
These allow you to build true services-oriented architectures in pure
Java, where the physical location of services don't matter, and the
fallacies of distributed computing are addressed head-on. We're using it
quite successfully, and alongside OSGi (still waiting for the mythical,
magical technology to merge the best of both technologies).
If you are happy to be relegated to e.g. RESTful web services, however,
OSGi is a treat - it's just a beautiful, lean, productive infrastructure
which has given us such good results over the years.
OSGi is all about choice. iPojo is effectively a service publishing /
injection framework, and there are a couple of options to you:
Declarative services, Felix dependency manager, iPojo, Blueprint
container. None of these have anything to do with publishing a service
as an HTTP resource.
A service published with any mechanism (like the above) can be exposed
as a REST resource using Amdatu (or similar). OSGi is like Arch Linux /
Gentoo Linux - you effectively create your own environment with many
available building blocks.
I would also urge you to look at Java EE. It is like Mac OS X - you get
EVERYTHING in the box, making it rather easy to use, but less flexible.
I mention this, because Java EE has very strong qualities like
transaction management, asynchronous communication, security,
persistence, general resource management, object- and thread pooling
(for performance/scalability) etc built-in, where you have to assemble
each of these capabilities yourself using OSGi. There are many
open-source containers that implement the Java EE spec, like Glassfish,
Wildfly, etc.
Good luck with your search!
kind regards,
Dawid
On 17/09/2014 19:21, Ivanhoe Abrahams wrote:
> Hi andrew
>
> Have a look at the amdatu website
> They use felix dependency manager in their examples not ipojo but their
> examples are complete and u can use ipojo or any other osgi capable
> dependency injection framework.
>
> You should be up and running in about an hour if you follow and read the
> getting started pages... warning ... it is heavily slanted towards
> eclipse... hope you are ok with that.
>
> Regards
> Ivanhoe
> On 17 Sep 2014 7:14 PM, "Andrew Beechey" <a....@sky.com> 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
Re: iPojo : is it right for me?
Posted by Ivanhoe Abrahams <iv...@gmail.com>.
Hi andrew
Have a look at the amdatu website
They use felix dependency manager in their examples not ipojo but their
examples are complete and u can use ipojo or any other osgi capable
dependency injection framework.
You should be up and running in about an hour if you follow and read the
getting started pages... warning ... it is heavily slanted towards
eclipse... hope you are ok with that.
Regards
Ivanhoe
On 17 Sep 2014 7:14 PM, "Andrew Beechey" <a....@sky.com> 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
Re: iPojo : is it right for me?
Posted by Ivanhoe Abrahams <iv...@gmail.com>.
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" <da...@travellinck.com> 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: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: iPojo : is it right for me?
Posted by Dawid Loubser <da...@travellinck.com>.
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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: iPojo : is it right for me?
Posted by Scott Lewis <sl...@composent.com>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org