I think we were simply talking about different things.
I agree that for the traditional case of RSA you do not need many impl
details. Aries RSA and CXF DOSGi can be used in this way but it covers
only a small part of what people do today. When doing just transparent
remoting there is also no real benefit of using JAXRS as you do not care
about the actual service endpoint anyway.
The idea of the thread about RSA and JAX-RS was that you can use the
existing providers CXF-DOSGi and ECF to just publish REST services. In
that case you can leave out the dicsovery and the full remoting. It is
not the case RSA was originally targeting but in todays environment it
is a really important case.
I am pushing for using RSA for the pure REST services case as it allows
people to achieve their current need (exposing a REST service) while
also giving them a perspective to grow into the full remoting use case.
Ideally it should be combined with the new JAXRS spec for OSGi to give
people the benefits of RSA + the standardization of how to do REST.
I also think that the combination of RSA + JAX-RS + discovery could fit
nicely into a heterogenous setup where maybe some services are exposed
using spring boot and REST and others using OSGi + RSA + JAXRS but both
can interoperate using a common discovery layer and wadl or JAX-RS
interfaces for the service description.
Christian
On 10.11.2016 12:30, Timothy Ward wrote:
Add the property service.exported.interfaces=* and some provider
specific properties to your OSGi service.
And this is where the wheels come off. This statement is *wrong*. if
you *have* to add some provider specific properties then this is no
longer RSA, but some implementation specific thing. No compliant RSA
provider requires you to add service properties other than
service.exported.interfaces. If an implementation does require some
specific properites then the RSA CT would fail, because it would need
to know about all the different implementations’ properties.
It is perfectly possible to create an example which shows RSA by
starting two frameworks, one hosting the remote service and the other
consuming it. There are numerous inter-compatible distribution,
topology and discovery layers that could be used, many of which
require no configuration or external services.
This will not really help a user to get it up and running.
Absolutely it will - it will get them up and running, and after that
they can start asking questions about types of distribution and types
of discovery, but crucially they only need to ask if it matters to
them! At that point they can ask about how to get more sophisticated
discovery, and be directed to an implementation-specific list if
necessary.
Tim
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
