On 11/6/2016 6:05 AM, Ancoron Luciferis wrote:
<stuff deleted>
I assert that a full understanding of the RS/RSA architecture is largely
irrelevant to using RS/RSA for your and many other use cases. As an
alternative approach to understanding what's necessary, consider the
tutorial at [1].
From an operational perspective that's simply not true. As a developer
you might simply take the tutorial and you might be good to go -
functionality-wise.
But:
How do you ensure that what you have developed will also work in all
stages/production?
I would say you (and others) learn more about the *necessary* parts.
How do you ensure that you can guarantee that the ReST endpoint will be
available?
Again, if your use case dictates it, then you look further in those
directions. I don't think it's reasonable to expect that all aspects
of non-functional requirements (e.g. service availability) can be dealt
with via a single distribution system. For example, none of the
JAX-RS implementations (nor the spec afaik) have any notion of failure
detection. This is not an issue with RS/RSA or the implementations,
but if one's requirements include such a thing, then JAX-RS by itself
won't help...whether or not RS/RSA is used. OTOH, since RS allows
pluggable distribution providers, it's quite possible move among
multiple distribution providers (with different availability approaches)
without changing the service api, impl, or consumers. This is a
powerful concept for dealing with the concerns like availability,
security, reliability.
How do you ensure that troubleshooting doesn't reveal that you don't
know much about the technology you're using?
I think part of the point of frameworks and in fact modularity is to
make it unnecessary to know everything about the technology you are
using. Of course there is more to learn about any framework than what
a tutorial can provide, but I would say progressive disclosure is
generally an easier way.
Without (at least) knowing about the full concept (specs) and at least
some of the internals of the actual implementation you cannot be serious
about the service you're about to develop/publish.
I disagree. Yes, some of us must know the specs (e.g. in order to
produce compliant implementations). But the spec is not the only way
to learn about a framework usage, and frankly since most frameworks
don't have any specs associated with them, I don't think it's strictly
necessary. For example, I know several RS/RSA consumer that have never
read the spec and probably never will.
If that's the way you prefer to learn, however, then I'm not arguing
with your choice to read the spec. But IMHO it's not necessary (or
even desirable) to read specs in order to learn about frameworks
sufficient for their usage.
At least I wouldn't.
One of the key concerns in a software life cycle is risk management.
Each library/tool that is used at runtime which I don't know much about
is a risk factor and represents a point of failure.
Of course. But there are multiple phases, multiple approaches, and
typically multiple roles in dealing with risk management across an
entire sw lifecycle.
I think that the approach taken by RS/RSA provides the necessary balance
between having a general and flexible architecture able to handle more
than a few use cases, but also providing a simple, well-integrated
api...(i.e. a Remote Service is just an OSGi service with some standard
service properties, and so can be used seemlessly with DS, any/all code
written for local services, etc).
That's completely true.
However, the word you've used describes it pretty well: 'balance'. What
this essentially means is: trade-offs.
In the end, what I have seen so far (only having used CXF DOSGi and
Karaf Cellar DOSGi) was not enough for my use-cases:
* (de-)serialization (JSON/XML/... - MBR/MBW)
* performance
* integration with standard JAX-RS aspects (interceptors/filters/...)
I don't know enough about CXF to judge if what you are saying is
accurate. But I would say that CXF isn't the only option here, so what
you say about CXF doesn't apply to ECF and the other impls.
If you already have picked an implementation (Jersey) and the use-case
doesn't demand a node-restricted service within a cluster (which for me
would be the only use case to consider the overhead for RS/RSA), I'd
look for a tool that was build for that purpose.
Or you could continue to use Jersey, and use an RS/RSA implementation
(ECF) that has a Jersey-based distribution provider (see tutorial
referenced earlier).
That's how I found about the osgi-jax-rs-connector, which doesn't
require my services to include any specific stuff (e.g. service
properties) but still allows me to go as implementation-specific as I
want/need (tuning, integration, monitoring, security, ...). And best is
it doesn't introduce new infrastructure pieces (for RS/RSA: Topology
Manager, Service Discovery, ...) which I have to learn about, operate
and troubleshoot.
The Jax RS connector is doing the same thing as the RS/RSA impls, only
it's limited to a single distribution provider, and doesn't follow the
standards. So once you start using it and building it into your app,
you are committed to it. That seems like a potential risk to me.
I have learned that myself the hard way:
Simple is better than complex.
Complex is better than complicated.
And RS/RSA is not simple as it's major concern is about addressing some
problems (or claiming to) in the domain of distributed computing.
I think this is just incorrect. Distributed computing is indeed
complex. But OSGi/RS/RSA has much to help with some of the hard issues
of distributed computing...e.g. the ability to associate service
dynamics with network failure via failure detection, or the clear
separation between (remote) contract and implementation via a
distributed service registry.
As a
result, implementations must take that complexity to enable a simple
user-/developer-experience.
I just disagree that this means that one can't simplify by using useful
abstractions (service registry, modules). Definitely some
implementations have to take account of some of the complexity.
This complexity must either be understood
and actively managed by all parties
(administrators/dev-ops/tester/developers) or represents a risk for the
software component as a whole otherwise.
I don't think you are arguing that someone developing a distributed app
must have a Ph.D in distributed systems, but it sure seems like it.
Indeed there is much complexity in many distributed applications, and
that can indeed introduce risk to be managed. But that doesn't remove
the need to make frameworks that are both flexible (modules,
pluggability of distribution/discovery providers, etc), and as simple as
possible for as many use cases as possible.
So, if your use-case does not make use or require the distributed
computing feature of RS/RSA, then what's the reason for taking the risks?
Thing is, if you are doing OSGi whiteboard pattern services, where those
services are represented underneath by remote services, then you are
taking many risks whether you use RS/RSA or not and you are probably
re-building much of what is specified and implemented multiple times in
a non-standard way (jax-rs-connector).
Even if it is possible to simply not use the remoting/clustering
features of an RS/RSA implementation but only use the JAX-RS integration
feature (remember that RS/RSA is not about ReST - just about remoting),
then what's the reason for taking the additional footprint? You'd still
need the basic infrastructure services up and running - even locally in
a single JVM which is just waste and (from my perspective) goes against
the principles of OSGi.
The reason would be to get the benefits of OSGi and OSGi services:
dynamics, flexibility with ds/injection, standardized meta-data, all
without much of an additional footprint (I'm speaking for ECF, I don't
know what the footprint of other impls are).
Scott
Cheers,
Ancoron
Scott
[1]
http://wiki.eclipse.org/Tutorial:_Exposing_a_Jax_REST_service_as_an_OSGi_Remote_Service
For the real distributed services case, it is a completely different
question. But that's worth a separate topic. ;)
Cheers,
Ancoron
Refs:
[1] http://cxf.apache.org/dosgi-architecture.html
Christian
2016-11-04 12:20 GMT+01:00 Ancoron Luciferis
<ancoron.lucife...@googlemail.com
<mailto:ancoron.lucife...@googlemail.com>>:
Hi,
I just went the DS-route myself with JAX-RS inside Karaf.
If you just want to publish a ReST endpoint going the remote
services
route seems way too complex.
What I found very useful and reliable to work especially for the
dynamic
resource service case is the following:
https://github.com/hstaudacher/osgi-jax-rs-connector
<https://github.com/hstaudacher/osgi-jax-rs-connector>
As a result, my JAX-RS resources are dynamically
activated/deactivated
declarative service components including references to other
services
(e.g. internal data services, validators, ...). DS takes care
about the
life-cycle and the osgi-jax-rs-connector just
creates/updates/deletes
the wiring to Jersey and the exposure via the HTTP service
(still Jetty
in case of Karaf).
From a bundle-perspective, no direct wiring to the
osgi-jax-rs-connector
is required as it detects the resources via annotation scanning
(@Path).
Cheers,
Ancoron
On 04/11/16 09:38, Bram Pouwelse wrote:
> In case you're looking for a JAX-RS whiteboard implementation
you could
> have a look at https://amdatu.org/application/web/
<https://amdatu.org/application/web/>. It doesn't implement
> the complete JAX-RS whiteboard draft spec. It does not have a
> JaxRSServiceRuntime implementation yet and it's currently
using Apache
> Wink internally (which is a JAX-RS 1.0 implementation). But the
> whiteboard works as described in the JAX-RS whiteboard
specification draft.
>
> Next step for us will be replacing Wink by another JAX-RS
implementation
> that does implement the JAX-RS 2.0 spec
>
> Regards,
> Bram
>
> On Fri, Nov 4, 2016 at 9:26 AM Tim Ward <tim.w...@paremus.com
<mailto:tim.w...@paremus.com>
> <mailto:tim.w...@paremus.com <mailto:tim.w...@paremus.com>>>
wrote:
>
> I note that both of the Remote Services options provided have
> examples using JAX-RS annotated service interfaces, which
doesn't
> actually match the code provided in the example below.
>
> Using Remote Services also doesn't give you a standard way
to handle
> request scoped resources (i.e. prototype services) or a
defined way
> to add JAX-RS filters, MessageBodyReaders etc. This is one
of the
> reasons why a JAX-RS whiteboard specification is being
created.
>
> A JAX-RS whiteboard also allows you to do things like
returning a
> JAX-RS Response for streaming results, asynchronous
returns, or just
> to give a response other than 200 without having to use an
Exception
> in a main-line code path.
>
> Whilst it is therefore true that a subset of JAX-RS
resources can be
> exposed using Remote Services, it's not necessarily a good
option if
> you're looking to put together a full REST API.
>
> Regards,
>
> Tim
>
> Sent from my iPhone
>
> > On 4 Nov 2016, at 02:23, Scott Lewis
<sle...@composent.com <mailto:sle...@composent.com>
> <mailto:sle...@composent.com <mailto:sle...@composent.com>>>
wrote:
> >
> >> On 11/3/2016 2:17 AM, Christian Schneider wrote:
> >> You can use CXF-DOSGi to register your rest resource.
You just
> need to add some properties to your example component to make
it work.
> >
> > Another option is to use ECF's impl of OSGI Remote
Services [1]
> with the Jax-RS distribution provider [2,3]...which supports
either
> Jersey or CXF impls of Jax-RS.
> >
> > Scott
> >
> > [1]
>
http://wiki.eclipse.org/Eclipse_Communication_Framework_Project#OSGi_Remote_Services
<http://wiki.eclipse.org/Eclipse_Communication_Framework_Project#OSGi_Remote_Services>
> > [2]
>
http://wiki.eclipse.org/Distribution_Providers#Jax-RS_REST_Providers
<http://wiki.eclipse.org/Distribution_Providers#Jax-RS_REST_Providers>
> > [3] https://github.com/ECF/JaxRSProviders
<https://github.com/ECF/JaxRSProviders>
> >
> >
> >>
> >> See
> >> https://github.com/apache/cxf-dosgi/tree/master/samples
<https://github.com/apache/cxf-dosgi/tree/master/samples>
> >>
> >> There is a also a bndrun file to easily run and package
CXF-DOSGi
> for bndtools.
> >>
https://github.com/apache/cxf-dosgi/tree/master/samples/soap
<https://github.com/apache/cxf-dosgi/tree/master/samples/soap>
> >>
> >> Christian
> >>
> >>> On 03.11.2016 03:05, Tanvir wrote:
> >>> I have a REST resource class, say Employees, and I
need access
> to another service using DS. Hence I have to make this
call a
> component. Now objects instantiated by @component and JAX-RS
> Servlet are not same.
> >>>
> >>> I do not want to use static reference to the service
as shown
> below. How this can be handled?
> >>>
> >>> -----------------------------------------------
> >>> @Component
> >>> @Path("employees")
> >>> public class EmployeeResource {
> >>> static MyService service;
> >>> @Reference
> >>> void setMyService(MyService s) {
> >>> service = s;
> >>> }
> >>>
> >>> @GET
> >>> @Produces("text/plain")
> >>> public String getEmployees() {
> >>> return service.get();
> >>> }
> >>> }
> >>>
> >>
> >>
> >
> > _______________________________________________
> > OSGi Developer Mail List
> > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
<mailto:osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>>
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://mail.osgi.org/mailman/listinfo/osgi-dev>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
<mailto:osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://mail.osgi.org/mailman/listinfo/osgi-dev>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
