|
| Re: Custom ECF provider development [message #625187 is a reply to message #625186] |
Wed, 24 March 2010 23:47  |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Kornel,
Kornel wrote:
> Hi Folks,
>
> We have been investigating ECF recently in order to find possibilities
> for using it as messaging provider in our existing distributed solution.
> ECF came into the picture as we are developing OSGi based services and
> the new OSGi remote services specification seems to be a very promising
> direction.
> However, we are using our own, custom JMS based messaging solution to
> access our services by its consumers.
> We do not want to completely replace the messaging layer but we want to
> customize ECF to be able to interpret our own JMS messages and convert
> them to method calls to our OSGi service.
Ok, interesting. So first, I want to tell you (in case you were not
aware), that we/ECF has a JMS provider...that uses ActiveMQ for the JMS
implementation. It's available here in source code form (see CVS server
access info at bottom of page):
http://ecf1.osuosl.org/
And now our build system does do automated builds to create binary
distributions (i.e. p2 repo). Those are available here:
https://ecf2.osuosl.org/hudson/
See under the 'C-HEAD-jms feature' project in the list.
> So what we want to achieve is to develop our own JMS distribution
> provider and give it to ECF when registering our OSGi service.
> We do not really plan to utilize all the distributed OSGi features.
> What we need is to that JMS clients can access our service using our
> existing JMS-based protocol and ECF on the server side will do the
> translation of the messages to OSGi service calls.
>
> Would it be a good starting point to try to derive an own JMS provider
> implementation based on the org.eclipse.ecf.provider.jms package with
> our custom messages but removing the messages (request, response, ping,
> etc.) declared in the original message?
Yes, that's one way you can go (develop your own provider that extends
the org.eclipse.ecf.provider.jms package and other packages from that
bundle).
One thing to realize though...the actual rpc...i.e. parameter
marshalling/serialization, sending the request message, receiving the
request message (on the remote service host), doing host computation,
sending result back + deserialization is actually done by the
RegistrySharedObject class in the
org.eclipse.ecf.provider.remoteservices bundle. So if you want to use a
custom JMS protocol (in your provider) to do these things it would
probably be necessary to change/replace the RegistrySharedObject rather
than extend/override the code in org.eclipse.ecf.provider.jms bundle.
The reason the RegistrySharedObject class was created separately from
the various providers (including the jms provider) was that this way the
*same* rpc support code (in RegistrySharedObject) can/could be used with
a variety of providers...and in fact this is what we do...as the
RegistrySharedObject class is used for the JMS provider, the ECF generic
provider, the JavaGroups provider, the XMPP provider and possibly
others. Essentially, the RegistrySharedObject is used to implement the
IRemoteServiceContainerAdapter, which is the entry point adapter for
using ECF remote services API.
Of course you can/could develop you own provider that implements the
remote service API directly (i.e.
org.eclipse.ecf.remoteservice.IRemoteServiceContainerAdapter and
others)...and provide your own impl of IRemoteService and the proxy
created from IRemoteService.getProxy(). This is what r-OSGi provider
does, for example...it directly implements both the core IContainer and
the IRemoteServiceContainerAdapter/remoteservice api. See the
org.eclipse.ecf.provider.r-osgi project for example code.
It would also be possible to use/reuse/extend some of the existing code
in org.eclipse.ecf.provider.remoteservice.RegistrySharedObject and
support classes if you like.
But one question I would ask about your use case: is it important that
your rpc implementation be used above JMS? If so...is that because of
the need for backward compatibility/integration with some existing
system? If so, I understand...but if not I would consider just reusing
the RegistrySharedObject stuff...since it's been debugged and would save
you a fair amount of work.
So does that help? If you would like to consult with me about doing
this, or contract with me to do some development work here I could
perhaps do so...since I've created several providers...including the JMS
one...then please let me know via direct email.
Creating a custom provider for JMS is more involved technically, but it
is completely doable...and I would be happy to see others do so.
The really good news is, however, that once you create your own
provider, it can/will seemlessly be used for OSGi 4.2 compliant remote
services...with no additional work from you. That is, you get standards
compliant discovery and remote services distribution for free.
Hope this helps. Please consider bringing up more on the ecf-dev
mailing list as there are more involved technical discussions there.
Here is the page to join:
https://dev.eclipse.org/mailman/listinfo/ecf-dev
Scott
|
|
|
Powered by
FUDForum. Page generated in 0.01634 seconds
] 
Search
Help
Register
Login
Home
