On 08.11.2016 19:59, 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?
RSA can be used to create service meshes and grids but it is not limited
to that quite big use case.
You can also scale very small and simply use it to export or import
services. Exporting a service just means putting some properties on it.
I just did an improvement for CXF DOSGi that allows to export services
by just adding one property:
https://issues.apache.org/jira/browse/DOSGI-251
The code also shows how to use ExportPolicy in practice. I think it
could be very handy for applying company wide policies to services. For
example you could add a logging intent to all services without touching
any user bundles.
On the import side you can use the Aries RSA config discovery together
with CXF-DOSGi to simply import a REST or SOAP service from the outside
world. The exporter of the service does not even have to use java. You
just need a correct java interface with the JAXRS annotations.
https://github.com/apache/aries-rsa/tree/master/discovery/config
So I think RSA is also a very nice model to export and import services
with any supported protocol.
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).
This is correct. As the standard does not cover the specifics of JAX-RS
these specifics are not portable.
On the other hand JAX-RS is standardized so the portability is quite
good in practice. Even switching
from the JAX-RS connector to CXF-DOSGi and back is a very small step.
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. ;)
Using CXF programmatically is a good approach. It ties you to CXF but
that is not that problematic.
The programmatic way is easier to understand as it is more direct. It
allows to learn a lot about how CXF works.
For a bigger system I prefer RSA/CXF-DOSGi as it easily allows to apply
central policies and the decoupling from CXF in your user code is also
beneficial in this case.
Basically the idea is that a business programmer can focus on the
business code and keep the business code as clean from technological
artifacts as possible.
This is not completely possible with JAX-RS but at least you can often
avoid to have a CXF dependency. For SOAP, tcp and fastbin transports the
abstraction from the transport works very well as these are more RPC like.
Ideally I try to only use specs and small APIs in business code. This
makes the code much easier to test and maintain and also more portable.
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.
Yes that is something we have to advertise better. People have the
impression that RSA is complicated but for small use cases it is really
simple.
If you also try the more advanced features I would be really happy about
feedback of the current approach using intents and ideas for improvement.
Christian
--
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
