Hello, Just noticed at the modconf2016 in Darmstadt (literary event next Tuesday) there is also a Workshop on this topic: https://web.liferay.com/de/web/events2016/modconf [ I will be at the conference as well, so maybe we can meet and greet? ] Modular Rest APIs using JAX-RS in OSGi (Workshop)Ort: Lounge, Time: 11:30 - 13:20Carlos Sierra AndrésCore Engineer, LiferayAbstract:Building great APIs is essential in an increasingly interconnected world. In the workshop we will show how to build REST APIs using well known Java standards while dealing with complexity in an incremental way using OSGi. We will build a REST API from scratch that will be consumed from a client application. Creating JAX-RS application in a modular way Incremental resources and providers Adaptable URL generation Deploying in a OSGi container We will also introduce the ongoing OSGi RFC-217 for standarizing JAX-RS inside OSGi containers.
Gruss Bernd -- http://bernd.eckenfels.net On Wed, Nov 9, 2016 at 6:36 PM +0100, "Christian Schneider" <ch...@die-schneider.net> wrote: 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
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev