| [CDO] Business logic in restfull applications [message #496806] |
Wed, 11 November 2009 12:33  |
 Mario Winterer
Messages: 136
Registered: July 2009 |
Senior Member |
|
|
Hi!
I'm wondering how to best realize a multi-tiered application with more
or less complex business logic (on server side) using EMF+CDO and a
restful approach.
I'd like to tell you some of my ideas, maybe you've got time to tell me
yours (I know, my posting is somewhat bulky, so I've tried to split it
up in four sections...):
(1) RESTful in general
Because the server api should only offer CRUD operations in restful
applications, every business operation has to be designed as data
manipulation. Because every (non-NOP) operation in fact is nothing else
than manipulating data, this seems sensible to me.
(see also:
http://www.slideshare.net/kenn.hussey/building-restful-java- applications-with-emf)
(2) RESTful cars (an example)
So if we realized a restful car application, we'd have no car-API
offering a method start() (because that's no CRUD operation). Instead
we'd maybe access the "Ignition"-resource (=read), set its state
attribut to "ON" and save it back to the (car) server (=update).
Somehow strange. Should it really be done this way?
If we now take EMF+CDO into account, the code might look like this:
// cdoTransaction is a CDO Transaction to our car-repository:
ResourceSet resourceSet = cdoTransaction.getResourceSet();
URI uri = URI.createURI("car://localhost#ignition);
Ignition ignition = (Ignition)resourceSet.getObject(uri, true);
ignition.setState(State.ON);
cdoTransaction.commit();
In the example above, obviously at server side there is a custom
implementation that adapts the physical car to a CDO IStore. So the
custom IStore implements our business logic (Maybe it is necessary to
switch on the light if the ignition's state is set to 'ON' and it is
dark outside - the IStore-implementation could do this).
(4) Custom vs. generic IStore / responsibilities
But what is the best approach if one of the existing (more general)
IStore implementations should/could be used? How do we implement
business operations there? In fact, is it in general a good solution to
(miss)use the IStore for business operations? I don't think so.
Maybe the business logic server could be a client to our repostory
server (maybe using JVM embedded transport) that reacts to model changes
and performs the necessary operations. But this may be problematic if
business logic should be performed transactionally.
E.g. a banking application server must validate every financial
transaction and do other things before the model change can be committed
to the database. And if something gets wrong, it is absolutely required
to safely roll back the entire transaction. That means there must be
something between the repository and the database or at least between
the client and the repository. How can that be done with CDO?
Thanks,
Mario
|
|
|
| Re: [CDO] Business logic in restfull applications [message #496810 is a reply to message #496806] |
Wed, 11 November 2009 13:06  |
|
Hi Mario,
Recently I helped a customer of mine to develop a similar mechanism that
is based on a session that is embedded into the server and listens to a
job queue. The jobs are committed from a client session together with
other model changes. Job results are committed back and received by the
client. With appropriate synchronization the whole process looks like a
logical thread over the network.
But you're right, in this scenario CDO does not ensure end-to-end ACID
properties. You either have to come up with your own transaction
protocol (possibly on top of Net4j or the new CDO remote session
messaging) or you follow a different path: You could hook a custom
WriteAccessHandler into the repository and intercept the client commits
before they enter the repository layer. The trade-off is that you'll not
be able to code your business logic against the generated interfaces.
Instead you'd have to code against CDORevisions and CDORevisionDeltas.
There is an old feature request:
273562: Make EObjects available at the server-side
https://bugs.eclipse.org/bugs/show_bug.cgi?id=273562
But it's unlikely that it will be addressed anytime soon without
substantial help from your side ;-)
Does that help?
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Mario Winterer schrieb:
> Hi!
>
> I'm wondering how to best realize a multi-tiered application with more
> or less complex business logic (on server side) using EMF+CDO and a
> restful approach.
> I'd like to tell you some of my ideas, maybe you've got time to tell
> me yours (I know, my posting is somewhat bulky, so I've tried to split
> it up in four sections...):
>
> (1) RESTful in general
>
> Because the server api should only offer CRUD operations in restful
> applications, every business operation has to be designed as data
> manipulation. Because every (non-NOP) operation in fact is nothing
> else than manipulating data, this seems sensible to me.
>
> (see also:
> http://www.slideshare.net/kenn.hussey/building-restful-java- applications-with-emf)
>
>
>
> (2) RESTful cars (an example)
>
> So if we realized a restful car application, we'd have no car-API
> offering a method start() (because that's no CRUD operation). Instead
> we'd maybe access the "Ignition"-resource (=read), set its state
> attribut to "ON" and save it back to the (car) server (=update).
> Somehow strange. Should it really be done this way?
>
> If we now take EMF+CDO into account, the code might look like this:
>
> // cdoTransaction is a CDO Transaction to our car-repository:
> ResourceSet resourceSet = cdoTransaction.getResourceSet();
> URI uri = URI.createURI("car://localhost#ignition);
> Ignition ignition = (Ignition)resourceSet.getObject(uri, true);
> ignition.setState(State.ON);
> cdoTransaction.commit();
>
> In the example above, obviously at server side there is a custom
> implementation that adapts the physical car to a CDO IStore. So the
> custom IStore implements our business logic (Maybe it is necessary to
> switch on the light if the ignition's state is set to 'ON' and it is
> dark outside - the IStore-implementation could do this).
>
>
> (4) Custom vs. generic IStore / responsibilities
>
> But what is the best approach if one of the existing (more general)
> IStore implementations should/could be used? How do we implement
> business operations there? In fact, is it in general a good solution
> to (miss)use the IStore for business operations? I don't think so.
>
> Maybe the business logic server could be a client to our repostory
> server (maybe using JVM embedded transport) that reacts to model
> changes and performs the necessary operations. But this may be
> problematic if business logic should be performed transactionally.
>
> E.g. a banking application server must validate every financial
> transaction and do other things before the model change can be
> committed to the database. And if something gets wrong, it is
> absolutely required to safely roll back the entire transaction. That
> means there must be something between the repository and the database
> or at least between the client and the repository. How can that be
> done with CDO?
>
>
> Thanks,
> Mario
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.02863 seconds
] 
Search
Help
Register
Login
Home
