Scott,
it's great to hear that you're willing to work on an initial integration with Swordfish. If that enables ECF remote services and Swordfish to work together in a meaningful way, I don't see why ECF shouldn't be part of a future Eclipse SOA package. I think we should try and find some time on EclipseCon to talk about that in greater detail.
Cheers,
Oliver
Am 22.01.2010 um 18:25 schrieb Scott Lewis:
For everyone's info,
There was a recent discussion on the rt-pmc mailing list about the
appropriate working relationship between rt projects that can/could be
instructive for this discussion. See the thread starting with Jesse
McConnell's posting [1].
My takeaway from this discussion: it's not reasonable or appropriate to
expect us to do all desired tools integration alone as a prerequisite
for doing anything in the SOA working group. It should be done in an
open and cooperative way.
Also, FYI and in line with such collaboration, I've created an example
of using Apache Axis and a small amount of example boiler-plate code to
create soap-based clients (using the new support added to ECF remote
services). See [2]. I expect that with little effort this could
provide the means for initial integration with Swordfish-based
tooling....along with changes/improvements...which I/we are completely
willing to do.
Scott
[1] http://dev.eclipse.org/mhonarc/lists/rt-pmc/msg01128.html
[2] http://wiki.eclipse.org/SOAP-based_Providers
Scott Lewis wrote:
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
_______________________________________________
soa-iwg mailing list
soa-iwg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/soa-iwg
_______________________________________________
soa-iwg mailing list
soa-iwg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/soa-iwg
Oliver Wolf
Chief Architect
Tel.: +49 228-182 19059
Fax: +49 228-182 19193
Mobil: +49 160-98931313
oliver.wolf@xxxxxxxxx
Wussten Sie schon? SOPERA <http://www.osbf.de/de/node/1466> hat den Open Source Business Award 2009 <http://www.osbf.de/en/node/1466> verliehen bekommen!
SOPERA GmbH - Open Source SOA
Subscription Services, Support & Maintenance, Training,
Technical SOA Consulting & Customized Development
www.sopera.de <http://www.sopera.de/>
SOPERA GmbH · Geschäftsführer: Dr. Ricco Deutscher, Harald Weimer, Peter Spiegel
Sträßchensweg 10 · 53113 Bonn · Handelsregister: Bonn HRB 15336
Hohenlindnerstraße 11b · 85622 München
Vertraulichkeitshinweis: Diese Nachricht und jeder übermittelte Anhang beinhaltet vertrauliche Informationen und ist nur für die Personen oder das Unternehmen bestimmt, an welche sie tatsächlich gerichtet ist. Sollten Sie nicht der Bestimmungsempfänger sein, weisen wir Sie darauf hin, dass die Verbreitung, das (auch teilweise) Kopieren sowie der Gebrauch der empfangenen E-Mail und der darin enthaltenen Informationen gesetzlich verboten ist und gegebenenfalls Schadensersatzpflichten auslösen kann. Sollten Sie diese Nachricht aufgrund eines Übermittlungsfehlers erhalten haben, bitten wir Sie, den Sender unverzüglich hiervon in Kenntnis zu setzen.
_______________________________________________
soa-iwg mailing list
soa-iwg@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/soa-iwg
