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?
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'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.
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.
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.
So, at least portability is questionable here as well (same for
osgi-jax-rs-connector).
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.
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
