[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] ECF 3.5

Hi Pavel,

Sorry about the slow response.Â

First, thank you for this contribution. I believe I speak for the ECF community when I say that your efforts here will be used and appreciated by many.

The xml-rpc remote services provider will be a wonderful addition to ECF 3.5...lets jointly work through any remaining releng, IP clearance, and review issues to get this done.ÂÂ I will try to review the new code myself as soon as possible, but if there are other committers who could dedicate some effort to reviewing the new xml-rpc code by Pavel that would be a very good idea...as I am rather severely bandwidth-limited right now.

As an aside about the relationship between my recent work (RSA) and Pavel's:

One very good thing(tm) to make clear to everyone...in case I haven't done so previously...is that when new remote services providers are introduced (like this one by Pavel), they are now *automatically* available for use by those using the new OSGi Remote Service Admin (RSA) impl just completed.ÂÂÂ The point being that the creation of new remote service providers like Pavel's work will make the OSGi remote services admin standards work all the more valuable for consumers...because consumers will be able to develop, control, monitor, secure, manage remote services and have more choices of transport and/or serialization format to use...without having to change anything at the level of the remote service itself.

Further, discovery providers can be 'mixed and matched' with remote service providers...meaning, for example, that for those interested in using xml-rpc for remote services distribution, they could use Zookeeper discovery, and/or zeroconf discovery, and/or dnssd discovery, and/or the standardized xml file discovery (standardized in the RSA spec...called 'endpoint description extender format' in the RSA chap 122 spec). All the while using the RSA-standardized discovery APIs (EndpointListener).

This modularity is indeed a very good thing...for consumers...as it means that ECF's impl of the RSA specification is deeply extensible...allowing the easy substitution of whole subsystems (discovery and distribution) using open and mature APIs (ECF discovery and remote services APIs)...and maximally leveraging OSGi's modularity.Â

In remoting/remote service systems, it's frequently the case that changing use cases, and/or changing/new system requirements (e.g. interoperability, deployment, security) dictate the move from one transport/serialization system to another...and with ECF's work this becomes very easy to do. You might call it "SOA lockin-avoidance".

BTW, I've also started some blogging about the RSA work in anticipation of ECF 3.5 release:Â http://eclipseecf.blogspot.com/2011/01/ecf-35-supports-osgi-42-remote-services.html

I'll hopefully be doing some more blogging/posting on xml-rpc and the value prop I articulated above...if I can find the time.


On 1/25/2011 11:01 AM, Pavel Samolisov wrote:
Hi Scott,

I was created an ECF XML-RPC provider implementation [0]. This is a
simple provider, but it allows ECF users to make connections for XML-RPC
based web services (i.e. Jira or Bugzilla XML-RPC APIs). The
implementation based on the Apache XML-RPC library [1] from Eclipse
Orbit [2].

Currently the provider supports followed things:
- RemoteServicesClient API (Sync and Async invokes via Callable/Call);
- Remote Service invokation via Proxy [3] (if a server is based on the
Apache XML-RPC library);
- Custom input parameters serializers (i.e. java objects into
RPC-friendly types serializers).

Currently the provider does not support:
- HTTP headers relation authentification (see [4]);
- custom datatypes (see [3]), but I'm planning to finish this work on
early Feb 2011.

Also I want to add some examples, i.e. a subset of Jira XML-RPC API
(Jira does not need a Http-Authentification).

[0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=325813
[1] http://ws.apache.org/xmlrpc/
[2] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=4549
[3] http://ws.apache.org/xmlrpc/advanced.html
[4] http://ws.apache.org/xmlrpc/server.html

24.01.2011 22:22, Scott Lewis ÐÐÑÐÑ:
Hi Folks,

It's time to do some community planning for ECF 3.5 and beyond. In
this email, I'm going to focus on ECF 3.5 specifically...and in a
second planning email I will discuss what we're going to do for the
Indigo simultaneous release.

When: ECF 3.5 has been previously planned for 'late Feb 2011'. The
desire here is to have the ECF 3.5 release prior to EclipseCon 2011
(in early March).

What: This is the main question for this email. We have to (soon)
decide what will go into ECF 3.5.

Other than bug fixes (of which there have been a good amount since
3.4), the only thing that I know for sure that is going into ECF 3.5
is the OSGi 4.2 Remote Service Admin spec implementation that I've
been doing since ECF 3.4. This implementation is now very close to
complete, and you can get technical details and/or participate in the
remaining finishing/testing work via this enhancement [1]. See below
for some initial words describing the RSA implementation.

I'm sure there are other ECF committers and/or contributors that have
work that they've been doing that could potentially be in ECF 3.5 as
well. So I make the following request of *all ECF committers,
contributors, and community members*:

Action request: If you have something that you have been working on,
that can/could be in ECF 3.5, please take a few moments to create a
posting to this mailing list (in response to this email) describing
that work, and detailing what/where it is in development and what (to
your own understanding) needs to take place in order for it to be
included in/added to ECF 3.5.

Note that the contribution does *not* have to be a code contribution,
as contributions to the ECF documentation project [3] can/would also
be great and very welcome additions/contributions to ECF. Such
contributions are *very important*. So if you have/could make a
documentation, and/or examples contribution (whether you are a
committer or not), please respond to this email with that information,
so that I and the rest of the community can plan for that.

Thanksinadvance for your usage, participation, and continued support
of ECF,


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=324215
[2] http://wiki.eclipse.org/ECF/Asynchronous_Remote_Services
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=329124

Short description of ECF's OSGi 4.2 RSA Standard Implementation

I think RSA will be a very nice addition for ECF consumers...not only
because it's been explicitly requested by some in the community, but
also because ECF's modularity (i.e. separation of discovery and remote
service APIs...allowing multiple, transport specific providers to be
mixed and matched for remote service discovery (e.g. zookeeper,
zeroconf, slp, xml-file-based, custom), and the distribution (rosgi,
ecf generic, jms, xmpp, javagroups, as well as our support of
asynchronous/non-blocking messaging for remote procedure call (see
[2]), makes ECF's implementation of this OSGi standard the most open.
extensible and interoperable implementation available...bug also makes
it the most functional that I know of for creating scalable enterprise
remote services using industry standards.

I'll be making a number of postings over the coming months clarifying
what RSA is, and how ECF's implementation provides added value above
and beyond existing commercial and/or other implementations.

If people have questions about the RSA spec, and/or ECF's
implementation, please ask them on either the rsa enhancement request
[1], and/or via this mailing list.

ecf-dev mailing list

_______________________________________________ ecf-dev mailing list ecf-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/ecf-dev