Home » Archived » Eclipse Communications Framework (ECF) » Custom ECF provider development
| Custom ECF provider development [message #522879] |
Wed, 24 March 2010 10:24  |
 Kornel
Messages: 4
Registered: July 2009 |
Junior Member |
|
|
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.
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 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 package?
Any thoughts are welcome!
Thank you!
Best regards,
Kornel
[Updated on: Wed, 24 March 2010 10:39] Report message to a moderator |
|
|
| Re: Custom ECF provider development [message #523074 is a reply to message #522879] |
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
|
|
|
| Re: Custom ECF provider development [message #523198 is a reply to message #523074] |
Thu, 25 March 2010 13:46 |
Kornel
Messages: 4
Registered: July 2009 |
Junior Member |
|
|
Hi Scott,
thank you for your helpful reply!
> 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.
For us the highest priority is backward compatibility with our existing JMS-based, non-OSGi system. We use a simple request/reply type JMS based protocol on Sonic MQ. We want to avoid modifications on the client side.
> 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.
Can you please point to some documentation that can serve as a starting point in this work?
What is your opinion about the efforts of developing such a provider? Are we talking about days or months?
> 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.
Having a fully OSGi 4.2 compliant remote services implementation is of lower priority. First we want to develop a solution that is backward compatible with our existing (non-OSGi) system.
Best regards,
Kornel
[Updated on: Thu, 25 March 2010 13:47] Report message to a moderator |
|
|
| Re: Custom ECF provider development [message #523586 is a reply to message #523198] |
Fri, 26 March 2010 19:28 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Kornel,
Kornel wrote:
> Hi Scott,
>
> thank you for your helpful reply!
>
>> 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.
>
> For us the highest priority is backward compatibility with our existing
> JMS-based, non-OSGi system. We use a simple request/reply type JMS based
> protocol. We want to avoid modifications on the client side.
>
>> 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.
>
> Can you please point to some documentation that can serve as a starting
> point in this work?
There is a trivial example provider implementation that exists here:
dev.eclipse.org
/cvsroot/rt
org.eclipse.ecf/examples/bundles/org.eclipse.ecf.examples.pr ovider.trivial
also there are existing providers, including the r-osgi provider that
implements the remote service api and this can/would be used as
functioning example. As well, in some cases the code/classes can also
be reused for a completely new provider.
Unfortunately, we don't have any separate documentation for creating
remote services providers. This would be a great thing to have, but our
resources are limited and so we haven't been able to create it to this
point.
> What is your opinion about the efforts of developing such a provider?
> Are we talking about days or months?
Well, it does depend quite a lot on the a) number of developers; b)
their backgrounds (e.g. how experienced with java, osgi, and jms); and
c) their knowledge of/experience with ECF specifically...both the
overall architecture/approach, as well as the existing codebase.
For me it would likely be days...since I've developed most of the
existing providers including the jms provider, and am responsible for
most of the ECF APIs as well. For others, it will be longer.
Scott
|
|
|
| Re: Custom ECF provider development [message #625188 is a reply to message #523074] |
Thu, 25 March 2010 13:46 |
Kornel
Messages: 4
Registered: July 2009 |
Junior Member |
|
|
Hi Scott,
thank you for your helpful reply!
> 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.
For us the highest priority is backward compatibility with our existing JMS-based, non-OSGi system. We use a simple request/reply type JMS based protocol. We want to avoid modifications on the client side.
> 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.
Can you please point to some documentation that can serve as a starting point in this work?
What is your opinion about the efforts of developing such a provider? Are we talking about days or months?
> 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.
Having a fully OSGi 4.2 compliant remote services implementation is of lower priority. First we want to develop a solution that is backward compatible with our existing (non-OSGi) system.
Best regards,
Kornel
|
|
|
| Re: Custom ECF provider development [message #625189 is a reply to message #523198] |
Sat, 27 March 2010 00:20 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Kornel,
Kornel wrote:
> Hi Scott,
>
> thank you for your helpful reply!
>
>> 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.
>
> For us the highest priority is backward compatibility with our existing
> JMS-based, non-OSGi system. We use a simple request/reply type JMS based
> protocol. We want to avoid modifications on the client side.
>
>> 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.
>
> Can you please point to some documentation that can serve as a starting
> point in this work?
There is a trivial example provider implementation that exists here:
dev.eclipse.org
/cvsroot/rt
org.eclipse.ecf/examples/bundles/org.eclipse.ecf.examples.pr ovider.trivial
also there are existing providers, including the r-osgi provider that
implements the remote service api and this can/would be used as
functioning example. As well, in some cases the code/classes can also
be reused for a completely new provider.
Unfortunately, we don't have any separate documentation for creating
remote services providers. This would be a great thing to have, but our
resources are limited and so we haven't been able to create it to this
point.
> What is your opinion about the efforts of developing such a provider?
> Are we talking about days or months?
Well, it does depend quite a lot on the a) number of developers; b)
their backgrounds (e.g. how experienced with java, osgi, and jms); and
c) their knowledge of/experience with ECF specifically...both the
overall architecture/approach, as well as the existing codebase.
For me it would likely be days...since I've developed most of the
existing providers including the jms provider, and am responsible for
most of the ECF APIs as well. For others, it will be longer.
Scott
|
|
|
| |
  |
Goto Forum:
Current Time: Fri Apr 19 17:07:12 GMT 2024
Powered by FUDForum. Page generated in 0.23696 seconds |
] 
Search
Help
Register
Login
Home
