On 05/11/16 16:49, Scott Lewis wrote:
> On 11/4/2016 9:38 AM, Ancoron Luciferis wrote:
>> <stuff deleted>
>> Simply looking at the DOSGi architecture [1] (which just follows what
>> the specs demand) is an absolute overkill for the use case of simply
>> having a DS-annotated JAX-RS resource being exposed via HTTP service.
>
> 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?
How do you ensure that you can guarantee that the ReST endpoint will be
available?
How do you ensure that troubleshooting doesn't reveal that you don't
know much about the technology you're using?
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. 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.
>
> 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/...)
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.
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.
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. As a
result, implementations must take that complexity to enable a simple
user-/developer-experience. 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.
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?
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.
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
