[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [soa-iwg] ECF remote services
|
Hi Zsolt,
Zsolt Beothy-Elo wrote:
Scott,
I think there is a misunderstanding between you and Ricco. Obviously
ECF is integrated with Equinox. What Ricco meant is integration with
other SOA specific components that already are part of the SOA package
or plan to be, especially integration / interoperability between ECF
and Swordfish. I would envisage to offer Swordfish as a ECF protocol
provider to fullfil the following to use cases.
So first: let's be clear: the *only* SOA-specific component that are
part of the package are from the Swordfish project.
We are happy to see this happen, and will cooperatively support it's
development (and add that to our plan if you like), but cannot commit to
doing it all ourselves.
We can't commit to something like this by ourselves for these three reasons:
1) Swordfish is a totally closed project and doing this would require a
*huge* investment in understanding and working with the Swordfish
codebase. As one can see from dash [a], Swordfish's participation has
been 100% from SOpera...not 95%, not 99%, 100% (that's every line of
code). This makes it practically impossible for any other project to
contribute directly to Swordfish.
2) No resources for an additional significant technical effort beyond
what's in the plan. 'nuff said.
3) We are already engaged in adding support for SOAP-based (and
REST-based) protocols as described by this posting:
http://eclipseecf.blogspot.com/2010/01/soap-rest-and-ecf-remote-services.html.
This work will be in our Helios release. A Swordfish-based client
provider can/could very easily be constructed from this work (we are
creating examples right now using Axis and WTP...if I can stop posting
to mailing lists). This would make it very easy for someone familiar
with Swordfish to create a SOAP based provider(s)...or more accurately:
reuse Swordfish tooling to create SOAP-based providers given a specific
wsdl/protocol.
4) In general, it's impossible for us to implement providers for
everyone that would like to have them. That's why we've gone to great
trouble to define clear, abstract APIs (specifically, the ECF Remote
Service API, and the ECF discovery API...i.e. see [b]) that allow others
to create ECF providers with the protocol and serialization format of
their choice.
Further, I have previously done a skeleton provider for the Riena
project...see [b]. That provider can/could be used by someone with
knowledge of Riena internals to implement a provider. The same skeleton
could be used to do the same by someone familiar with Swordfish.
Finally, I think making inclusion of something like an OSGi standard in
a package contingent upon integration with Swordfish is both a very poor
and a closed policy...and it makes the 'project silo' problem (lack of
project diversity) at EF worse rather than better.
a) Make a web service consumable as a OSGi remote service.
b) Expose an OSGi remote service as a webservice.
I know this i a very simplified view and there are a lot of subtleties
to be considered and still there will be a lot of restrictions. But
adding ECF together with the capabilities to communicate with web
services would the user a truly integrated platform where he can use
both technologies depending on the concrete problem domain, but still
communicate with components based on the other technology. This would
really add value to the package.
Hoped that helped clarifying what the IWG is aiming for.
Again, we are happy to see this...and will cooperatively support it (we
have a very long and public history as a project of supporting our
community). I say if that's what the 'IWG' wants, then make it happen
(i.e. do it...because everything from ECF's side is already there...i.e.
public APIs, support resources, my commitment as project lead to make
necessary changes/additions to ECF, etc). But asking us to do such
integration by ourselves specifically for the Swordfish project is both
practically impossible and organizationally not appropriate.
Scott
[a] http://dash.eclipse.org/dash/commits/web-app/project-diversity.cgi
[b] http://wiki.eclipse.org/Distributed_OSGi_Services_with_ECF
[c] https://bugs.eclipse.org/bugs/show_bug.cgi?id=274839
