[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [soa-iwg] ECF remote services
|
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.
