Hi Christian > On 10 Nov 2016, at 12:17, Christian Schneider <ch...@die-schneider.net> wrote: > > I think we were simply talking about different things.
I’m not sure that we are - I’m talking about when RSA is an appropriate choice, and how to provide advice in a relatively vendor-neutral way on this list. In this case one of the things being highlighted is the inappropriate recommendation of the RSA standard when what is actually being proposed is a proprietary JAX-RS whiteboard mechanism. > > 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. This is where your argument has problems, RSA simply does not equal REST. RESTful services follow API design principles which are heavily connected to HTTP, and to the incoming and outgoing wire formats. If I have a REST API used by my “one page web app” then I simply cannot migrate away from REST to some other transport. Similarly, REST offers poor remoting characteristics for many RSA service interface types. HTTP’s request/response flow adds overhead to each call, caching is not appropriate for most remote service responses… I would certainly not want to couple the RSA specification to REST. The upcoming JAX-RS whiteboard standard is all about supporting people who want to provide a REST API. Where people want to provide remote access to an OSGi service then I will wholeheartedly recommend that they use RSA in as vendor neutral way as I can. When people explicitly ask for better ways to provide a REST API then I will point them to the upcoming standard which offers a whiteboard model for providing that REST API. > > 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. Again, I don’t see why RSA is mentioned here. If the system needs to be REST then it needs to be REST. You can pick a standard that provides REST, or you can pick a proprietary implementation which offers REST. The implementation may also offer other things but that doesn’t make those things relevant to the solution. Tim > > 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 _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
