| On 6/24/2011 4:55 PM, Scott Lewis wrote: 
      
      Markus,
 On 6/24/2011 4:20 AM, Marcus Engelhardt wrote:
 
        
        
        Hi guys,
 many thanks for all those helpful replies on my request.
 I already thought about running CXF/DOSGi and ECF in one OSGi
        environment. Since this is the Apache Felix container on the
        "server side" in my case, I could try to run ECF in Felix (I
        heard about this project to achive this: https://github.com/ECF/ECF4Felix)
        and try to publish the service in parallel on Apache Zookeeper
        via the ECF discovery implementation. Then the ECF based
        consumer running in Eclipse Equinox should have no problems
        discovering and using the service that resides in Apache Felix.
        Maybe this is the easiest way to reach my goal.
 
 Just to bring the other idea to an end: Ahmed wrote:
 
 "You don't need to. If you
          still want only to bridge with ECF Discovery allowing service
          published by CXF/DOSGi to get discovered by ECF, then I think
          you should publish all (to expose) services by explicitly
          registering them via ECF Discovery (in this case, have a look
          in page linked by  [1] on how to do it) . "
 
 The best solution for me would be one without the need to modify
        or add/install anything on the "server side" (Apache Felix,
        existing service exported by CXF/DOSGI over SOAP/HTTP). If l
        would be able to modify the ECF discovery to find a CXF/DOSGI
        exported service, do I have to expect any other issues
        concerning the communication between the service exported by
        CXF/DOSGI over SOAP/HTTP and the ECF consumer using r-osgi?
 
 Yes, I would expect so...as I think it's very unlikely that the
      wire protocol for CXF and r-osgi are exactly the same.
 
 But with ECF's provider architecture, I expect it would be
      straightforward to create a client-side remote services provider
      that talked the CXF protocol...as I imagine the CXF code could
      easily be reused to create such an ECF provider.    I say
      'imagine' only because I don't know enough about CXF's
      implementation to say how easily it could be reused.  It's not
      particularly challenging to create an ECF provider, however.
 
 For everyone's information...I've done some initial technical
    investigation with CXF, and I now believe that it would indeed be
    straightforward to create a client (and host)-side ECF remote
    services provider that used CXF underneath.  This would have some
    interesting and useful benefits for both the ECF and the CXF
    communities, I believe.
 
 If there is interest from the ECF community for this...and/or some
    measure of support or contribution to make it happen...then we can
    consider it for the ECF 3.6 plan.  My initial estimate is that such
    a provider would take less than 1 month's worth of technical effort
    (integration impl, testing, etc)...for someone familiar with ECF.
 
 Please let your desires be known via this list.  We need to do
    planning and prioritization for ECF 3.6 and beyond, so it's a great
    time to have a discussion about what new directions will be useful
    for people.
 
 Thanks,
 
 Scott
 
 
 
 |