Re: [osgi-dev] RS/RSA for exposing JAX-RS resources

Scott Lewis Wed, 09 Nov 2016 08:15:06 -0800

On 11/8/2016 10:59 AM, Ancoron Luciferis wrote:

Hi Scott,


first let me say thank you for taking the time to address my concerns
(sorry if they turned out as something other than just my personal
concerns).

I think I have gone a little bit too far with my argumentation.

My conceptional understanding of RS/RSA currently is that it looks like
a blueprint for creating heterogeneous service meshes or service grids.
Is that assumption actually true?

I consider that a family of use cases...which I think RS/RSA in someforms could be used to address.


If it is true, then ReST would probably not be an efficient way of
communicating, although it is good for testing and troubleshooting (due
to being HTTP).

I happen to agree with you about that, although I imagine some restadvocates might argue that point.

I'd really like to see server-side OSGi going for
HPC/big-data (RDMA@IB, anyone?).

I also think that this is one of the reasons why the spec (aka. the
standard) does not mandate nor reference any specific transport or
inter-node communication mechanism or pattern.


Yes, I happen to think that was a very good choice architecturally.


So, my personal conclusion is that RS/RSA is about communicating with
services across nodes/processes. As a result, I would never imply that
any RS/RSA implementation must be able to expose my service via
JAX-RS/HTTP. As a further result, RS/RSA as a standard is not suitable
for the requirement of publishing a ReST endpoint using a JAX-RS
annotated service, although some implementations might be.

Again I think that some Jax-RS/http advocates would argue with you, butI think this is right: i.e. there are many use cases for RS/RSA thatare not best-addressed via REST, and RS/RSA's flexibility abouttransport and topology (distribution) makes it easier to address moreuse cases...and to have the flexibility to move among distributionsystems without changing the impl or consumers (precisely because of thethe separation between service contract and service impl in OSGi services).


Don't get me wrong, I really am a standards-enthusiast and wherever
possible/suitable, I favor a standard over a specific implementation.
However, the scope of RS/RSA may include JAX-RS but cannot be relied on.

I'm not quite sure what you mean by this, but if you are saying that wrtRS/RSA Jax-RS is not a 'one size fits all use cases' then I agree.

So, at least portability is questionable here as well (same for
osgi-jax-rs-connector).

I believe that transport independence of remote services is desirable[1a], although in practice I would say it's been very difficult toobtain in distributed systems. The nice thing (IMHO) is that with OSGiRS is that it can be provided naturally via the service contract/implseparation and distribution sub-system modularity (RSA).

As an example, I've taken the enroute eval service example and turned itinto a remote service (via DS components with the necessary serviceproperties on registration/export). It's then possible to switchamong several distribution providers without modifying the servicecontract, the svc impl, or consumer code...just by changing theservice.exported.config RS property value.


In essence, I just wondered why multiple people advertised RS/RSA for
the simple job of exposing a JAX-RS-annotated service via HTTP, despite
the fact that simply CXF alone would be enough (which I'm using as well,
btw.), starting with the programmatic way as described in [1]. Putting
that in a DS-managed, configurable service and with a few tens of lines
I was good to go. Turned out some hundred for production-grade, though. ;)

Anyway, I think I might have missed how "simple" RS/RSA implementations
seem to be for the task of exposing a JAX-RS service via HTTP, so I'll
give some a try on one of my services.

I do think that the combination of DS and Remote Services in particularis very useful...particularly since service dynamics is very wellhandled in DS, and remote failure (with failure detection) can be mappedto service dynamics (i.e. when the network partitions or the serviceprovider fails, the service can disappear for consumers).


Scott

[1a]http://eclipseecf.blogspot.com/2016/04/transport-independent-remote-services.html



Cheers,

        Ancoron


Refs:
[1]
http://cxf.apache.org/docs/jaxrs-services-configuration.html#JAXRSServicesConfiguration-ConfiguringJAX-RSendpointsprogrammaticallywithoutSpring


On 07/11/16 16:58, Scott Lewis wrote:

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

_______________________________________________
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

Re: [osgi-dev] RS/RSA for exposing JAX-RS resources

Reply via email to