https://bitbucket.org/amdatu/amdatu-remoteservices
On Thu, Nov 10, 2016 at 12:50 PM David Daniel <david.daniel.1...@gmail.com> wrote: > Is there a link to the code where the refernce implementation is being > kept. I would love to take a look at it. > > Thanks David > > On Thu, Nov 10, 2016 at 3:08 AM, Tim Ward <tim.w...@paremus.com> wrote: > > I'll be there, and am happy to talk with you about it. These talks will > likely both be about the upcoming JAX-RS whiteboard specification from OSGi > Enterprise R7 - Liferay are building the reference implementation for it. > > Tim > > Sent from my iPhone > > On 10 Nov 2016, at 08:01, Bernd Eckenfels <e...@zusammenkunft.net> wrote: > > 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:20 > Carlos Sierra Andrés > Core Engineer, Liferay > Abstract: > 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 Schneiderhttp://www.liquid-reality.de > > Open Source Architecthttp://www.talend.com > > _______________________________________________ > OSGi Developer Mail > listosgi-...@mail.osgi.orghttps://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
