Re: [soa-iwg] ECF remote services

[Zsolt Beothy-Elo <zsolt.beothy-elo@xxxxxxxxx>]

Am 08.01.2010 um 01:08 schrieb Scott Lewis:

> Zsolt Beothy-Elo wrote:
>> Hi Scott,
>> congratulations to you and the ECF team for the promptly implemantion
>> and release of the spec.  What I am still missing is the tooling
>> aspect
>
> WRT tooling, four points:
>
> 1) A large part of the whole *point* of the OSGi remote services
> standardization is to allow the use/reuse of *local* OSGi services
> tooling for remote services.  In the case of Eclipse, such tooling is
> already well established and heavily used via PDE, declarative  
> services,
> extension registry tooling, etc.  All of this tooling is immediately
> usable with ECF's remote services implementation...precisely because  
> the
> OSGi standardization supports such a model.

I agree with you that probably a lot of the necessary tooling is  
already available.

>
> 2) ECF has UI/tooling for the most difficult (and
> communications-specific) part of the use/debugging of remote
> services...and that's the dynamic network service discovery.  Right  
> now,
> we provide an extensible discovered services browser, so that the  
> use of
> discovery protocols can be verified to be working when debugging/ 
> testing.
>
> 3) ECF is a runtime project, and in keeping with that and the fact  
> that
> we have plenty that we've committed to do, we don't intend to focus on
> tooling.  Having said this, however, I (Scott) am also in the  
> process of
> implementing a SOAP-based remote services provider, which can/will/ 
> could
> use tooling produced in other project (e.g. WTP-tooling, possibly
> Swordfish tooling, etc).  Further, we are always open to community
> contributions.
>
> In general, since we are a runtime project, and there are a lot of
> excellent tools projects at EF, we will (intentionally) concentrate on
> implementing the OSGi runtime standards, and work collaboratively with
> other projects and the broader community to deliver tooling.

That's fine. You should just make sure that there is tooling project  
willing to deliver the missing features.

>
> 4) Finally, I think it's inappropriate to expect a runtime project to
> necessarily also produce tooling...especially when there are so many
> tools projects at EF.  For example, consider Equinox...yes they do  
> work
> with the platform and PDE teams on tooling (as we do), but Equinox
> itself is not (and I would argue shouldn't be), expected to implement
> tooling themselves.

I do not care who is doing this. I am interested in having a clear  
picture  what the

>
>> and also the integration with the other components.

The components that according to our roadmap we intend to integrate in  
the SOA package.

>
> What integration are you talking about?  We have the following
> integration already
>
> 1) Integration with OSGi mechanisms (service registry) as dictated by
> the OSGi spec
> 2) Integration with Equinox (implementation of the OSGi framework)
> 3) Integration with Eclipse PDE, declarative services tooling...and
> other Eclipse-based tooling for constructing, using, debugging OSGi
> services.
>
> For an implementation of an OSGi standard like remote services...on  
> EF's
> implementation of that standard (Equinox), what other integrations are
> you suggesting is appropriate/necessary?
>
>> I do not
>> expect them to be available today, but we should have a roadmap which
>> addresses these topics and commitments to implement the roadmap.
>
> As for tooling...like I said...we are leaving the tooling primarily to
> the relevant *tools projects*.  For the areas of tooling that are  
> unique
> (like discovery) we have (and will continue) to do some further things
> there...and in general work collaboratively with the other projects
> focusing on tooling (e.g. EMF, PDE, etc).
>
> If you want our roadmap, please see the ECF plan:
> http://www.eclipse.org/projects/project-plan.php?projectid=rt.ecf  
> and/or
> the discussion on the ecf-dev mailing list.  And if you want to add to
> the roadmap, then you are encouraged to contribute the resources to
> implement the desired additions.

If you want to have ECF and remote services included in the SOA  
package then you have to be the owner of the roadmap not only for the  
runtime but also for the tooling. You really have to start to show  
your involvement with the SOA IWG. I like what you and the rest of the  
ECF team is doing, but I and more important SOPERA do not have a stake  
in it and I am afraid that is true for the rest of the IWG members. So  
if you want to have ECF included in the SOA package start working in  
the IWG.

Zsolt


>
>> In a
>> second step we should then discuss what has to be in a first
>> contribution for the EPP package to make it useful.
>>
>
> My assertion is that it should include:
>
> The OSGi remote services implementation bundles
>
> org.eclipse.ecf.osgi.services.discovery
> org.eclipse.ecf.osgi.services.distribution
>
> and dependencies...which are:
>
> org.eclipse.ecf.remoteservice (ECF remote services API)
> org.eclipse.ecf.discovery (ECF discovery API)
>
> and their dependencies (the ECF core bundles....which are already
> distributed with Eclipse since they are part of p2...but would have to
> be included in a non-eclipse/runtime).
>
> Further, it should probably include at least 2 provider  
> implementations,
> so that things can/could be used immediately and 'out of the  
> box'...e.g.
> the r-OSGi provider, and the ECF generic provider (along with their
> dependencies).
>
> That makes a total of about 10 bundles, and < 1M of jars.
>
> Scott
>
> _______________________________________________
> soa-iwg mailing list
> soa-iwg@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/soa-iwg