Home » Modeling » EMF » [CDO] Tutorials that cover adapting existing projects that use ECore?
|
| Re: [CDO] Tutorials that cover adapting existing projects that use ECore? [message #633223 is a reply to message #633212] |
Fri, 15 October 2010 17:52   |
 David Wynter
Messages: 4624
Registered: July 2009 |
Senior Member |
|
|
Hi,
I found this, http://wiki.eclipse.org/CDO_Embedded for the CDO server
side of things. Still looking for an example of converting an existing
RDCP app to also be a CDO client.
I had CDO already in Helios, but still cannot resolve this package. Not
obvilus where it is
org.eclipse.emf.cdo.server.db
Thx.
David
On 15/10/10 17:32, David Wynter wrote:
> Hi,
>
> Finding it difficult to understand how I convert an existing OSGi server
> application and a RCP client application that have to share the same
> ECore models. The tutorials show how to create a standalone CDO_Server,
> but I cannot see how I can convert my existing OSGi server app to
> incorporate the CDO_Server functionality, any pointers? Not how I
> convert my RCP application (there can be >1 instances on separate
> machines) to be a CDO client,
>
> The second problem I have is that my ECore model has a couple of
> classifiers that have associated script files that I would also like to
> have replicated with the model. I figure I can extend my ECore model to
> have CLOBs that hold the script content and then 'unpack' that content
> on replication into the separate file I need, but is there a better way?
>
> Thx.
>
> David
|
|
|
| Re: [CDO] Tutorials that cover adapting existing projects that use ECore? [message #633253 is a reply to message #633223] |
Fri, 15 October 2010 21:07 |
Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
David,
comments below.
On 15.10.2010 19:52, David Wynter wrote:
> Hi,
>
> I found this, http://wiki.eclipse.org/CDO_Embedded for the CDO server
> side of things. Still looking for an example of converting an existing
> RDCP app to also be a CDO client.
The Embedded Example is maybe not really what you expect (see below).
Embedded just means that the CDO Server process runs as part of the
example program (in other words: CDO Client).
> I had CDO already in Helios, but still cannot resolve this package. Not
> obvilus where it is
>
> org.eclipse.emf.cdo.server.db
This is the DBStore (database persistence layer). Unfortunately, I am
not up to date about the CDO/Helios distro, but as far as I know, the
DBStore part should be part of the Helios distro as well.
Maybe Eike can clarify this issue.
>> Finding it difficult to understand how I convert an existing OSGi server
>> application and a RCP client application that have to share the same
>> ECore models. The tutorials show how to create a standalone CDO_Server,
>> but I cannot see how I can convert my existing OSGi server app to
>> incorporate the CDO_Server functionality, any pointers? Not how I
>> convert my RCP application (there can be >1 instances on separate
>> machines) to be a CDO client,
Mhh ... I'm not sure if there is a one-size-fits-all recipe for
achieving this. Maybe I just say a few things about CDO first.
The CDO Server is not really designed to be part of a "business logic
server" of any kind, meaning that there are only very limited
possibilities to interfere with objects server-side. Actually, the only
thing you can do is enhance commit logic, which means you need to stick
to the existing CDO protocol. Any communication between (business)
client and (business) server is difficult to realize on top of a CDO server.
Instead, think of the CDO server as a central service which persists a
master copy of the complete (distributed) model and which offers
services to support the distribution (such as transactional operations,
locking and change notifications). Whether this component runs in the
same process (= embedded) as your actual (business) server, does not
really matter.
Therefore, how you actually migrate an existing client-server
application depends on the application. I can intuitively come up with
three possibilities:
1. "Peer-to-peer"
You basically get rid of the server and implement everything in the
clients. Because of change notifications and transactional operations
offered powered by CDO, each client knows what's going on with the model
and can react directly based on these events. This is the way you can go
if you don't need a business logic "server" instance and the CDO-based
distribution is the main server-like feature you need.
2. "Transaction-Interceptor"
This is what I indicated before. There is an API on the CDO server side
which you can use to examine incoming commits and react based on them.
But as far as I know this is almost everything you can do: examine.
3. "Server-as-CDO-Client"
You could realize the server itself as a CDO client which the actual
clients (which could be implemented as CDO-clients, or not) can
communicate with. This way, a client could have a read-only view on the
model and the server could modify the model on behalf of the clients. Or
the clients can modify the model and the server listens to model changes
and reacts accordingly. Or ...
You could realize things very flexible with this last scenario. Just
think of it as n+1 clients where n clients are the same, while one
client is different and supports the n clients with special functions.
I hope, I made the CDO Client/Server layers a bit more clear. If you
have any further questions, don't hesitate to ask!
>> The second problem I have is that my ECore model has a couple of
>> classifiers that have associated script files that I would also like to
>> have replicated with the model. I figure I can extend my ECore model to
>> have CLOBs that hold the script content and then 'unpack' that content
>> on replication into the separate file I need, but is there a better way?
Depending on the file sizes, EString properties could also suffice. But
that's an implementation detail. But to answer your question, I
currently cannot think of any CDO feature which could you support in a
nicer way than what you came up with.
Cheers,
Stefan
|
|
|
| Re: [CDO] Tutorials that cover adapting existing projects that use ECore? [message #633264 is a reply to message #633253] |
Fri, 15 October 2010 21:42 |
David Wynter
Messages: 4624
Registered: July 2009 |
Senior Member |
|
|
Thanks,
That clarifies thing perfectly. I'll go for the 'everything as a client'
scenario to start with. But it seems to me that it would be a common use
case where the server component is the 'owner' of the model and thus a
natural home for the CDO server.
Although the org.eclipse.emf.cdo.server.db component does not appear to
be a part of the std Helios (Eclipse 3.6) EMF distribution. I found it
on a ftp server, but the Eclipse platfrom continues the DLL hell
syndrome and the dropins mechanism never works as expected, so have yet
to have it register as a plugin, I'll get there.
Thx.
David
On 15/10/10 22:07, Stefan Winkler wrote:
> David,
>
> comments below.
>
> On 15.10.2010 19:52, David Wynter wrote:
>> Hi,
>>
>> I found this, http://wiki.eclipse.org/CDO_Embedded for the CDO server
>> side of things. Still looking for an example of converting an existing
>> RDCP app to also be a CDO client.
> The Embedded Example is maybe not really what you expect (see below).
> Embedded just means that the CDO Server process runs as part of the
> example program (in other words: CDO Client).
>
>> I had CDO already in Helios, but still cannot resolve this package. Not
>> obvilus where it is
>>
>> org.eclipse.emf.cdo.server.db
>
> This is the DBStore (database persistence layer). Unfortunately, I am
> not up to date about the CDO/Helios distro, but as far as I know, the
> DBStore part should be part of the Helios distro as well.
>
> Maybe Eike can clarify this issue.
>
>>> Finding it difficult to understand how I convert an existing OSGi server
>>> application and a RCP client application that have to share the same
>>> ECore models. The tutorials show how to create a standalone CDO_Server,
>>> but I cannot see how I can convert my existing OSGi server app to
>>> incorporate the CDO_Server functionality, any pointers? Not how I
>>> convert my RCP application (there can be >1 instances on separate
>>> machines) to be a CDO client,
>
> Mhh ... I'm not sure if there is a one-size-fits-all recipe for
> achieving this. Maybe I just say a few things about CDO first.
>
> The CDO Server is not really designed to be part of a "business logic
> server" of any kind, meaning that there are only very limited
> possibilities to interfere with objects server-side. Actually, the only
> thing you can do is enhance commit logic, which means you need to stick
> to the existing CDO protocol. Any communication between (business)
> client and (business) server is difficult to realize on top of a CDO
> server.
>
> Instead, think of the CDO server as a central service which persists a
> master copy of the complete (distributed) model and which offers
> services to support the distribution (such as transactional operations,
> locking and change notifications). Whether this component runs in the
> same process (= embedded) as your actual (business) server, does not
> really matter.
>
> Therefore, how you actually migrate an existing client-server
> application depends on the application. I can intuitively come up with
> three possibilities:
>
> 1. "Peer-to-peer"
> You basically get rid of the server and implement everything in the
> clients. Because of change notifications and transactional operations
> offered powered by CDO, each client knows what's going on with the model
> and can react directly based on these events. This is the way you can go
> if you don't need a business logic "server" instance and the CDO-based
> distribution is the main server-like feature you need.
>
> 2. "Transaction-Interceptor"
> This is what I indicated before. There is an API on the CDO server side
> which you can use to examine incoming commits and react based on them.
> But as far as I know this is almost everything you can do: examine.
>
> 3. "Server-as-CDO-Client"
> You could realize the server itself as a CDO client which the actual
> clients (which could be implemented as CDO-clients, or not) can
> communicate with. This way, a client could have a read-only view on the
> model and the server could modify the model on behalf of the clients. Or
> the clients can modify the model and the server listens to model changes
> and reacts accordingly. Or ...
> You could realize things very flexible with this last scenario. Just
> think of it as n+1 clients where n clients are the same, while one
> client is different and supports the n clients with special functions.
>
>
> I hope, I made the CDO Client/Server layers a bit more clear. If you
> have any further questions, don't hesitate to ask!
>
>>> The second problem I have is that my ECore model has a couple of
>>> classifiers that have associated script files that I would also like to
>>> have replicated with the model. I figure I can extend my ECore model to
>>> have CLOBs that hold the script content and then 'unpack' that content
>>> on replication into the separate file I need, but is there a better way?
> Depending on the file sizes, EString properties could also suffice. But
> that's an implementation detail. But to answer your question, I
> currently cannot think of any CDO feature which could you support in a
> nicer way than what you came up with.
>
> Cheers,
> Stefan
|
|
|
| Re: [CDO] Tutorials that cover adapting existing projects that use ECore? [message #633297 is a reply to message #633264] |
Sat, 16 October 2010 05:56 |
|
Am 15.10.2010 23:42, schrieb David Wynter:
> Thanks,
>
> That clarifies thing perfectly. I'll go for the 'everything as a client' scenario to start with. But it seems to me that it would be a common use case where the server component is the 'owner' of the model and thus a natural home for the CDO server.
Yes, that is the most common deployment scenario of CDO. The only thing you'd change with respect to the embedded scenario is to use a TCPConnector/Acceptor instead of the JVMConnector/Acceptor.
>
> Although the org.eclipse.emf.cdo.server.db component does not appear to be a part of the std Helios (Eclipse 3.6) EMF distribution.
The org.eclipse.emf.cdo.server.db plugin i past of the org.eclipse.emf.cdo.server.db feature which, in turn, is part of the org.eclipse.emf.cdo.sdk feature. And that is definitely part of Helios. Note that you may want to install additional DB adapters from http://net4j.sourceforge.net/update/
> I found it on a ftp server, but the Eclipse platfrom continues the DLL hell syndrome and the dropins mechanism never works as expected, so have yet to have it register as a plugin, I'll get there.
It should really work via p2 and be very convenient. Note that we offer some more stuff that we, for IP reasons, can not contribute to Helios: http://download.eclipse.org/modeling/emf/cdo/updates/3.0-rel eases/
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> Thx.
>
> David
>
> On 15/10/10 22:07, Stefan Winkler wrote:
>> David,
>>
>> comments below.
>>
>> On 15.10.2010 19:52, David Wynter wrote:
>>> Hi,
>>>
>>> I found this, http://wiki.eclipse.org/CDO_Embedded for the CDO server
>>> side of things. Still looking for an example of converting an existing
>>> RDCP app to also be a CDO client.
>> The Embedded Example is maybe not really what you expect (see below).
>> Embedded just means that the CDO Server process runs as part of the
>> example program (in other words: CDO Client).
>>
>>> I had CDO already in Helios, but still cannot resolve this package. Not
>>> obvilus where it is
>>>
>>> org.eclipse.emf.cdo.server.db
>>
>> This is the DBStore (database persistence layer). Unfortunately, I am
>> not up to date about the CDO/Helios distro, but as far as I know, the
>> DBStore part should be part of the Helios distro as well.
>>
>> Maybe Eike can clarify this issue.
>>
>>>> Finding it difficult to understand how I convert an existing OSGi server
>>>> application and a RCP client application that have to share the same
>>>> ECore models. The tutorials show how to create a standalone CDO_Server,
>>>> but I cannot see how I can convert my existing OSGi server app to
>>>> incorporate the CDO_Server functionality, any pointers? Not how I
>>>> convert my RCP application (there can be >1 instances on separate
>>>> machines) to be a CDO client,
>>
>> Mhh ... I'm not sure if there is a one-size-fits-all recipe for
>> achieving this. Maybe I just say a few things about CDO first.
>>
>> The CDO Server is not really designed to be part of a "business logic
>> server" of any kind, meaning that there are only very limited
>> possibilities to interfere with objects server-side. Actually, the only
>> thing you can do is enhance commit logic, which means you need to stick
>> to the existing CDO protocol. Any communication between (business)
>> client and (business) server is difficult to realize on top of a CDO
>> server.
>>
>> Instead, think of the CDO server as a central service which persists a
>> master copy of the complete (distributed) model and which offers
>> services to support the distribution (such as transactional operations,
>> locking and change notifications). Whether this component runs in the
>> same process (= embedded) as your actual (business) server, does not
>> really matter.
>>
>> Therefore, how you actually migrate an existing client-server
>> application depends on the application. I can intuitively come up with
>> three possibilities:
>>
>> 1. "Peer-to-peer"
>> You basically get rid of the server and implement everything in the
>> clients. Because of change notifications and transactional operations
>> offered powered by CDO, each client knows what's going on with the model
>> and can react directly based on these events. This is the way you can go
>> if you don't need a business logic "server" instance and the CDO-based
>> distribution is the main server-like feature you need.
>>
>> 2. "Transaction-Interceptor"
>> This is what I indicated before. There is an API on the CDO server side
>> which you can use to examine incoming commits and react based on them.
>> But as far as I know this is almost everything you can do: examine.
>>
>> 3. "Server-as-CDO-Client"
>> You could realize the server itself as a CDO client which the actual
>> clients (which could be implemented as CDO-clients, or not) can
>> communicate with. This way, a client could have a read-only view on the
>> model and the server could modify the model on behalf of the clients. Or
>> the clients can modify the model and the server listens to model changes
>> and reacts accordingly. Or ...
>> You could realize things very flexible with this last scenario. Just
>> think of it as n+1 clients where n clients are the same, while one
>> client is different and supports the n clients with special functions.
>>
>>
>> I hope, I made the CDO Client/Server layers a bit more clear. If you
>> have any further questions, don't hesitate to ask!
>>
>>>> The second problem I have is that my ECore model has a couple of
>>>> classifiers that have associated script files that I would also like to
>>>> have replicated with the model. I figure I can extend my ECore model to
>>>> have CLOBs that hold the script content and then 'unpack' that content
>>>> on replication into the separate file I need, but is there a better way?
>> Depending on the file sizes, EString properties could also suffice. But
>> that's an implementation detail. But to answer your question, I
>> currently cannot think of any CDO feature which could you support in a
>> nicer way than what you came up with.
>>
>> Cheers,
>> Stefan
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Sat Apr 20 03:47:57 GMT 2024
Powered by FUDForum. Page generated in 0.03162 seconds |
] 
Search
Help
Register
Login
Home
