CXF-DOSGi + Aries RSA is not really more complicated than any other alternative. For example the JAXRS connector from Holger Staudacher works in a very similar way and is similarly complex.
If you only use DOSGi on the server side then it simply listens for OSGi services with the magic properties and calls CXF to instantiate the endpoint. There is not much more to what Aries RSA does if you do not use discovery and the client side and you do not have to. The two additional properties will not really make it more complex. In both cases DS does the full lifecycle management of the service. The main difference is that with the JAX-RS connector you are stuck with an implementation created by someone and no real community and commercial support. Remote Services is a standard and Aries RSA, CXF-DOSGi as well as ECF have good communities behind them. About the complexity of CXF-DOSGi... Look into that code and tell me it is complicated: https://github.com/apache/cxf-dosgi/blob/master/provider-rs/src/main/java/org/apache/cxf/dosgi/dsw/handlers/rest/RsProvider.java https://github.com/apache/cxf-dosgi/blob/master/common/src/main/java/org/apache/cxf/dosgi/common/intent/impl/IntentManagerImpl.java These 400 lines are almost the complete code of CXF-DOSGi on the JAXRS side. The Aries RSA code of course is also involved but it is also not complex and very well tested. CXF-DOSGi is able to support almost all advanced features you need like exception handlers, message body writers and readers, ssl, ... The performance of CXF is amond the best in any JAXRS implementations. So I think for beginners the jaxrs connector might provide a little faster start but you soon hit a dead end while RSA allows you to start with REST but then grow with your needs. In the end it is your own choice but I could not leave all these assumptions and conclusions you did uncommented as I think many are not true (anymore). CXF-DOSGi has come a long way in the recent years and I think it is worth another look. If you want to try it I will try to do my best to help. Christian 2016-11-06 15:05 GMT+01:00 Ancoron Luciferis < ancoron.lucife...@googlemail.com>: > On 05/11/16 16:49, Scott Lewis wrote: > > On 11/4/2016 9:38 AM, Ancoron Luciferis wrote: > >> <stuff deleted> > >> Simply looking at the DOSGi architecture [1] (which just follows what > >> the specs demand) is an absolute overkill for the use case of simply > >> having a DS-annotated JAX-RS resource being exposed via HTTP service. > > > > I assert that a full understanding of the RS/RSA architecture is largely > > irrelevant to using RS/RSA for your and many other use cases. As an > > alternative approach to understanding what's necessary, consider the > > tutorial at [1]. > > From an operational perspective that's simply not true. As a developer > you might simply take the tutorial and you might be good to go - > functionality-wise. > > But: > > How do you ensure that what you have developed will also work in all > stages/production? > > How do you ensure that you can guarantee that the ReST endpoint will be > available? > > How do you ensure that troubleshooting doesn't reveal that you don't > know much about the technology you're using? > > > Without (at least) knowing about the full concept (specs) and at least > some of the internals of the actual implementation you cannot be serious > about the service you're about to develop/publish. At least I wouldn't. > One of the key concerns in a software life cycle is risk management. > Each library/tool that is used at runtime which I don't know much about > is a risk factor and represents a point of failure. > > > > > > I think that the approach taken by RS/RSA provides the necessary balance > > between having a general and flexible architecture able to handle more > > than a few use cases, but also providing a simple, well-integrated > > api...(i.e. a Remote Service is just an OSGi service with some standard > > service properties, and so can be used seemlessly with DS, any/all code > > written for local services, etc). > > That's completely true. > > However, the word you've used describes it pretty well: 'balance'. What > this essentially means is: trade-offs. > > In the end, what I have seen so far (only having used CXF DOSGi and > Karaf Cellar DOSGi) was not enough for my use-cases: > * (de-)serialization (JSON/XML/... - MBR/MBW) > * performance > * integration with standard JAX-RS aspects (interceptors/filters/...) > > > If you already have picked an implementation (Jersey) and the use-case > doesn't demand a node-restricted service within a cluster (which for me > would be the only use case to consider the overhead for RS/RSA), I'd > look for a tool that was build for that purpose. > > That's how I found about the osgi-jax-rs-connector, which doesn't > require my services to include any specific stuff (e.g. service > properties) but still allows me to go as implementation-specific as I > want/need (tuning, integration, monitoring, security, ...). And best is > it doesn't introduce new infrastructure pieces (for RS/RSA: Topology > Manager, Service Discovery, ...) which I have to learn about, operate > and troubleshoot. > > I have learned that myself the hard way: > > Simple is better than complex. > Complex is better than complicated. > > And RS/RSA is not simple as it's major concern is about addressing some > problems (or claiming to) in the domain of distributed computing. As a > result, implementations must take that complexity to enable a simple > user-/developer-experience. This complexity must either be understood > and actively managed by all parties > (administrators/dev-ops/tester/developers) or represents a risk for the > software component as a whole otherwise. > > So, if your use-case does not make use or require the distributed > computing feature of RS/RSA, then what's the reason for taking the risks? > > Even if it is possible to simply not use the remoting/clustering > features of an RS/RSA implementation but only use the JAX-RS integration > feature (remember that RS/RSA is not about ReST - just about remoting), > then what's the reason for taking the additional footprint? You'd still > need the basic infrastructure services up and running - even locally in > a single JVM which is just waste and (from my perspective) goes against > the principles of OSGi. > > > Cheers, > > Ancoron > > > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
