Home » Archived » Eclipse Communications Framework (ECF) » Requesting RCP-Configuration from Server - A scenario for ECF?
|
| Re: Requesting RCP-Configuration from Server - A scenario for ECF? [message #620823 is a reply to message #620819] |
Fri, 25 January 2008 20:52   |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Tom,
Tom Seidel wrote:
> Hi,
>
> I'm very interested in using ECF in my RCPs, but I don't know if my
> requirements are matching the capabilites, or better, intensions of ECF.
> We deliver RCP Clients that manage data that is either installed locally
> or online available.
> On startup the Client requests different data from the server that is
> responded via WebServices or simple XML and the result is distributed to
> subscribers that can listen for the result (they are registered via
> Extension-Points). We have implemented something like a connection
> layer, that handles all the connection-stuff and stores the result on
> harddisc (if the server is not reachable, the local data is proceeded).
> As the requirements for that handling will be extended, I don't want to
> extend a proprietary solution if there is a framework that is (probably)
> able to handle these things. I know ECF is very powerful, but my
> question is: Is ECF also suitable for such a simple scenario?
I think so. We've tried to build ECF so that it is decomposable into
components to use in different scenarios. So, for example, we have a
number of plugins that have little/no user interface code, and as
few-as-possible other dependencies...and this makes them very
appropriate for use in building server-based and/or RCP applications.
Here is a description of the various communications APIs that ECF exposes:
http://wiki.eclipse.org/ECF_API_Docs
Note that the various API pages have links to the appropriate javadocs
for the runtime APIs. Here is a top-level link to all the ECF APIs:
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/
For your specific scenario, it seems likely to me that you would want
something like the ECF datashare API:
http://wiki.eclipse.org/ECF_API_Docs#Datashare_API
This API is intended to provide access to basic pub-sub messaging
channels, that provide some basic reliability/failure detection, and a
minimal ordering guarantee (sender ordering). We have the following
providers that support this: ECF 'generic', XMPP, JMS-ActiveMQ,
JMS-weblogic, JavaGroups, etc.
Another API that you might prefer is the 'shared object' API, which is
also described here:
http://wiki.eclipse.org/ECF_API_Docs
This is a 'lower-level' API (i.e. below the datashare API), that allows
the dynamic replication of java objects within a pub-sub group.
If you would like example and/or test code that uses either/both of
these please let me know and we'll point to specific examples. The
following location is the top of the ECF CVS repository area (see under
tests for test code):
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/?ro ot=Technology_Project
And here is the project wiki page:
http://wiki.eclipse.org/Eclipse_Communication_Framework_Proj ect
Honestly we don't have much yet in the way of support for persistence
(except that we do have a couple of providers that use JMS
underneath...the ActiveMQ and the Weblogic impls...and these *do* have
support for message persistence). The reason for this is essentially
that we have been trying to keep the dependencies in our own APIs down
to a minimum so that they can be run in as many environments as possible
(i.e. even those that have no underlying support for persistence).
So please let us know if this helps (or hurts). If you would like
more/other pointers please do also let us know.
Thanks,
Scott
|
|
|
| Re: Requesting RCP-Configuration from Server - A scenario for ECF? [message #620825 is a reply to message #620823] |
Sat, 26 January 2008 23:21 |
Tom Seidel
Messages: 91
Registered: July 2009 |
Member |
|
|
Scott,
thank you for your detailled answer. I'll try the things you mentioned.
Thanks again,
Tom
Scott Lewis schrieb:
> Hi Tom,
>
> Tom Seidel wrote:
>> Hi,
>>
>> I'm very interested in using ECF in my RCPs, but I don't know if my
>> requirements are matching the capabilites, or better, intensions of
>> ECF. We deliver RCP Clients that manage data that is either installed
>> locally or online available.
>> On startup the Client requests different data from the server that is
>> responded via WebServices or simple XML and the result is distributed
>> to subscribers that can listen for the result (they are registered via
>> Extension-Points). We have implemented something like a connection
>> layer, that handles all the connection-stuff and stores the result on
>> harddisc (if the server is not reachable, the local data is
>> proceeded). As the requirements for that handling will be extended, I
>> don't want to extend a proprietary solution if there is a framework
>> that is (probably) able to handle these things. I know ECF is very
>> powerful, but my question is: Is ECF also suitable for such a simple
>> scenario?
>
>
> I think so. We've tried to build ECF so that it is decomposable into
> components to use in different scenarios. So, for example, we have a
> number of plugins that have little/no user interface code, and as
> few-as-possible other dependencies...and this makes them very
> appropriate for use in building server-based and/or RCP applications.
>
> Here is a description of the various communications APIs that ECF exposes:
>
> http://wiki.eclipse.org/ECF_API_Docs
>
> Note that the various API pages have links to the appropriate javadocs
> for the runtime APIs. Here is a top-level link to all the ECF APIs:
>
> http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/
>
> For your specific scenario, it seems likely to me that you would want
> something like the ECF datashare API:
>
> http://wiki.eclipse.org/ECF_API_Docs#Datashare_API
>
> This API is intended to provide access to basic pub-sub messaging
> channels, that provide some basic reliability/failure detection, and a
> minimal ordering guarantee (sender ordering). We have the following
> providers that support this: ECF 'generic', XMPP, JMS-ActiveMQ,
> JMS-weblogic, JavaGroups, etc.
>
> Another API that you might prefer is the 'shared object' API, which is
> also described here:
>
> http://wiki.eclipse.org/ECF_API_Docs
>
> This is a 'lower-level' API (i.e. below the datashare API), that allows
> the dynamic replication of java objects within a pub-sub group.
>
> If you would like example and/or test code that uses either/both of
> these please let me know and we'll point to specific examples. The
> following location is the top of the ECF CVS repository area (see under
> tests for test code):
>
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/?ro ot=Technology_Project
>
>
> And here is the project wiki page:
>
> http://wiki.eclipse.org/Eclipse_Communication_Framework_Proj ect
>
> Honestly we don't have much yet in the way of support for persistence
> (except that we do have a couple of providers that use JMS
> underneath...the ActiveMQ and the Weblogic impls...and these *do* have
> support for message persistence). The reason for this is essentially
> that we have been trying to keep the dependencies in our own APIs down
> to a minimum so that they can be run in as many environments as possible
> (i.e. even those that have no underlying support for persistence).
>
> So please let us know if this helps (or hurts). If you would like
> more/other pointers please do also let us know.
>
> Thanks,
>
> Scott
|
|
|
| Re: Requesting RCP-Configuration from Server - A scenario for ECF? [message #620832 is a reply to message #620823] |
Sun, 10 February 2008 21:16 |
Tom Seidel
Messages: 91
Registered: July 2009 |
Member |
|
|
Scott,
after reading all the documentation and browsing through the examples, I
still have some questions.
I tried communication with ECF via setting up a ECF Server where clients
can connect and can send/receive shared objects. What I didn't
understand is the role of protocolls. When there is a need for an own
protocoll? If I would write a RCP where the clients would talk to each
other, I probably would prefer a generic ecf-server. Another point is
the role of the server. I still didn't get an overview, what the server
has implemented and what the clients need to connect. I've taken a look
at the example project org.eclipse.ecf.examples.provider.trivial, where
a provider is implemented, but where is the provider-specific code? I
would like to implement some logic where the server executes some logic,
based on the communication of the connected clients. Is this supported?
The RemoteService is a typical client-server thing and seems to be not
so complicated (what I've seen ;), probably you could point me to a
document where I can find some informations about the properties that
are displayed in the Service-Discovery-View. The service-lookup is
really cool, but what is the scope for such a lookup? - Is the search
scope of remote-services customizable?
Thanks for your help
Tom
Scott Lewis schrieb:
> Hi Tom,
>
> Tom Seidel wrote:
>> Hi,
>>
>> I'm very interested in using ECF in my RCPs, but I don't know if my
>> requirements are matching the capabilites, or better, intensions of
>> ECF. We deliver RCP Clients that manage data that is either installed
>> locally or online available.
>> On startup the Client requests different data from the server that is
>> responded via WebServices or simple XML and the result is distributed
>> to subscribers that can listen for the result (they are registered via
>> Extension-Points). We have implemented something like a connection
>> layer, that handles all the connection-stuff and stores the result on
>> harddisc (if the server is not reachable, the local data is
>> proceeded). As the requirements for that handling will be extended, I
>> don't want to extend a proprietary solution if there is a framework
>> that is (probably) able to handle these things. I know ECF is very
>> powerful, but my question is: Is ECF also suitable for such a simple
>> scenario?
>
>
> I think so. We've tried to build ECF so that it is decomposable into
> components to use in different scenarios. So, for example, we have a
> number of plugins that have little/no user interface code, and as
> few-as-possible other dependencies...and this makes them very
> appropriate for use in building server-based and/or RCP applications.
>
> Here is a description of the various communications APIs that ECF exposes:
>
> http://wiki.eclipse.org/ECF_API_Docs
>
> Note that the various API pages have links to the appropriate javadocs
> for the runtime APIs. Here is a top-level link to all the ECF APIs:
>
> http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/
>
> For your specific scenario, it seems likely to me that you would want
> something like the ECF datashare API:
>
> http://wiki.eclipse.org/ECF_API_Docs#Datashare_API
>
> This API is intended to provide access to basic pub-sub messaging
> channels, that provide some basic reliability/failure detection, and a
> minimal ordering guarantee (sender ordering). We have the following
> providers that support this: ECF 'generic', XMPP, JMS-ActiveMQ,
> JMS-weblogic, JavaGroups, etc.
>
> Another API that you might prefer is the 'shared object' API, which is
> also described here:
>
> http://wiki.eclipse.org/ECF_API_Docs
>
> This is a 'lower-level' API (i.e. below the datashare API), that allows
> the dynamic replication of java objects within a pub-sub group.
>
> If you would like example and/or test code that uses either/both of
> these please let me know and we'll point to specific examples. The
> following location is the top of the ECF CVS repository area (see under
> tests for test code):
>
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/?ro ot=Technology_Project
>
>
> And here is the project wiki page:
>
> http://wiki.eclipse.org/Eclipse_Communication_Framework_Proj ect
>
> Honestly we don't have much yet in the way of support for persistence
> (except that we do have a couple of providers that use JMS
> underneath...the ActiveMQ and the Weblogic impls...and these *do* have
> support for message persistence). The reason for this is essentially
> that we have been trying to keep the dependencies in our own APIs down
> to a minimum so that they can be run in as many environments as possible
> (i.e. even those that have no underlying support for persistence).
>
> So please let us know if this helps (or hurts). If you would like
> more/other pointers please do also let us know.
>
> Thanks,
>
> Scott
|
|
|
| Re: Requesting RCP-Configuration from Server - A scenario for ECF? [message #620834 is a reply to message #620832] |
Mon, 11 February 2008 17:25 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Tom,
Tom Seidel wrote:
> Scott,
>
> after reading all the documentation and browsing through the examples, I
> still have some questions.
>
> I tried communication with ECF via setting up a ECF Server where clients
> can connect and can send/receive shared objects. What I didn't
> understand is the role of protocolls. When there is a need for an own
> protocoll? If I would write a RCP where the clients would talk to each
> other, I probably would prefer a generic ecf-server.
OK. ECF APIs can be implemented by multiple protocols...e.g. xmpp, jms,
etc. So *if* one has to use some other protocol...because of need for
system interoperability, for example, the supported APIs (e.g.
datashare, remote services, shared object) may still be used.
An example of this xmpp...which also implements the shared object
API...so any applications that use the shared object API can run on xmpp
as well as ECF generic.
It sounds like in your case you would be/are comfortable with ECF
generic...and want to implement your own server, so I wouldn't expect it
to be necessary for you to use this facility.
Another point is
> the role of the server. I still didn't get an overview, what the server
> has implemented and what the clients need to connect. I've taken a look
> at the example project org.eclipse.ecf.examples.provider.trivial, where
> a provider is implemented, but where is the provider-specific code? I
> would like to implement some logic where the server executes some logic,
> based on the communication of the connected clients. Is this supported?
Yes. Here is some test code for the shared object API
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/tes ts/org.eclipse.ecf.tests.sharedobject/src/org/eclipse/ecf/te sts/sharedobject/?root=Technology_Project
In this class (TestSharedObject)
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/tes ts/org.eclipse.ecf.tests.sharedobject/src/org/eclipse/ecf/te sts/sharedobject/TestSharedObject.java?root=Technology_Proje ct&view=log
Is code that replicates the given object to all connected containers
(clients).
Once replicated, any/all of the replicas can send messages to any others
(including server), by using
getContext().sendMessage(ID,Object)
And on the receiver:
protected boolean handleSharedObjectMsgEvent(ISharedObjectMessageEvent
event)
is called when received.
Note that BaseSharedObject provides some additional utilities:
sendSharedObjectMsgTo
sendSharedObjectMsgToPrimary
sendSharedObjectMsgToSelf
These send instances of SharedObjectMsg, which can be used to represent
remote methods to invoke when received.
If you would like other pointers to example and/or test code please let
me know and I'll provide them.
Also, some other ECF contributors are working on some wiki page
additions on the use of the shared object API...please speak up here
about the availability of that documentation if you can.
>
> The RemoteService is a typical client-server thing and seems to be not
> so complicated (what I've seen ;), probably you could point me to a
> document where I can find some informations about the properties that
> are displayed in the Service-Discovery-View.
Yes, for client/server remote access to OSGI services, the remote
services API is useful.
Incidently...for some of the providers, the shared object API is used to
*implement* the remote services API...using the methods/messages shown
above.
As for the service discovery view...here's the code that gets called to
actually invoke a service:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/exa mples/plugins/org.eclipse.ecf.examples.remoteservices.client /src/org/eclipse/ecf/internal/examples/remoteservices/client /RemoteEnvironmentInfoServiceAccessHandler.java?root=Technol ogy_Project&view=log
See the method: createContributionItem
Also, if you want to get this code and browse it directly see at the
bottom of: http://wiki.eclipse.org/Discovery_of_Remote_Services
In createContributionItem is code like this
remoteService.callSynch(remoteCall)
remoteService.callAsynch(remoteCall, remoteCallListener);
etc.
These actually make the remoteCall. The properties in the serviceInfo
are queried to create/get the remoteService and the remoteCall.
The service-lookup is
> really cool, but what is the scope for such a lookup? - Is the search
> scope of remote-services customizable?
In general, yes. The providers differ in their capabilities here, but
the zeroconf and the SLP providers both allow scoping via the service
type id. So, for example, the default for both providers is lan-based
discovery...i.e. services published are exposed to clients on the same
lan, but not beyond. Both of them can, however, be set to have wider
scopes, but this typically requires some DNS additions (at least for
zeroconf).
Please let me know if this helps/hurts. I'm trying to work on some more
overview documentation in preparation for EclipseCon but it's slow going.
Scott
>
> Thanks for your help
> Tom
>
> Scott Lewis schrieb:
>> Hi Tom,
>>
>> Tom Seidel wrote:
>>> Hi,
>>>
>>> I'm very interested in using ECF in my RCPs, but I don't know if my
>>> requirements are matching the capabilites, or better, intensions of
>>> ECF. We deliver RCP Clients that manage data that is either installed
>>> locally or online available.
>>> On startup the Client requests different data from the server that is
>>> responded via WebServices or simple XML and the result is distributed
>>> to subscribers that can listen for the result (they are registered
>>> via Extension-Points). We have implemented something like a
>>> connection layer, that handles all the connection-stuff and stores
>>> the result on harddisc (if the server is not reachable, the local
>>> data is proceeded). As the requirements for that handling will be
>>> extended, I don't want to extend a proprietary solution if there is a
>>> framework that is (probably) able to handle these things. I know ECF
>>> is very powerful, but my question is: Is ECF also suitable for such a
>>> simple scenario?
>>
>>
>> I think so. We've tried to build ECF so that it is decomposable into
>> components to use in different scenarios. So, for example, we have a
>> number of plugins that have little/no user interface code, and as
>> few-as-possible other dependencies...and this makes them very
>> appropriate for use in building server-based and/or RCP applications.
>>
>> Here is a description of the various communications APIs that ECF
>> exposes:
>>
>> http://wiki.eclipse.org/ECF_API_Docs
>>
>> Note that the various API pages have links to the appropriate javadocs
>> for the runtime APIs. Here is a top-level link to all the ECF APIs:
>>
>> http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/
>>
>> For your specific scenario, it seems likely to me that you would want
>> something like the ECF datashare API:
>>
>> http://wiki.eclipse.org/ECF_API_Docs#Datashare_API
>>
>> This API is intended to provide access to basic pub-sub messaging
>> channels, that provide some basic reliability/failure detection, and a
>> minimal ordering guarantee (sender ordering). We have the following
>> providers that support this: ECF 'generic', XMPP, JMS-ActiveMQ,
>> JMS-weblogic, JavaGroups, etc.
>>
>> Another API that you might prefer is the 'shared object' API, which is
>> also described here:
>>
>> http://wiki.eclipse.org/ECF_API_Docs
>>
>> This is a 'lower-level' API (i.e. below the datashare API), that
>> allows the dynamic replication of java objects within a pub-sub group.
>>
>> If you would like example and/or test code that uses either/both of
>> these please let me know and we'll point to specific examples. The
>> following location is the top of the ECF CVS repository area (see
>> under tests for test code):
>>
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/?ro ot=Technology_Project
>>
>>
>> And here is the project wiki page:
>>
>> http://wiki.eclipse.org/Eclipse_Communication_Framework_Proj ect
>>
>> Honestly we don't have much yet in the way of support for persistence
>> (except that we do have a couple of providers that use JMS
>> underneath...the ActiveMQ and the Weblogic impls...and these *do* have
>> support for message persistence). The reason for this is essentially
>> that we have been trying to keep the dependencies in our own APIs down
>> to a minimum so that they can be run in as many environments as
>> possible (i.e. even those that have no underlying support for
>> persistence).
>>
>> So please let us know if this helps (or hurts). If you would like
>> more/other pointers please do also let us know.
>>
>> Thanks,
>>
>> Scott
|
|
|
| |
  |
Goto Forum:
Current Time: Wed Apr 24 17:02:06 GMT 2024
Powered by FUDForum. Page generated in 0.03386 seconds |
] 
Search
Help
Register
Login
Home
