Re: [soa-iwg] ECF remote services

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

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.

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.

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.

> and also the integration with the other components. 

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.

> 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