Hi, I've inlined some thoughts below.  Others may know more and have
different views.  Please follow-up if you have any more questions.

On 6 Aug, 02:55, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> I've been reading a bit about SDO recently and using it with PHP and
> have just started trying to put it to use. Apart from building a
> slightly more complex version of the tutorials/demos I am really
> stuck.
>
> My question really is: Does anyone know of any open source projects
> that leverage SDO? Or is anyone writing about how SDO can fit into
> your overall architecture?
>

I've heard of a couple of examples where people use SDO, but I think
the main project which uses it is actually SCA.  SCA makes heavy use
of SDO in its protocol binding implementations.

> I really see gaps in how SDO fits into business logic and how object
> selection works. Maybe this is me not searching hard enough or maybe
> it's the documentation not being complete enough.

SDO is all about the data.  It has two main goals:
1.  Help keep your business logic agnostic of the data source  - e.g.
the code you write to work with XML can be the same code that works
with JSON or relational data.
2.  Enable optimistic concurrency against relational databases (this
is done through the use of a "change summary").  In my opinion, this
second goal has fairly niche appeal, but some scenarios where locking
a database for long periods of time is problematic, do find this
useful.

In addition the these goals, the API design has focused on trying to
make it very simple to work with the various types of data.

In a loosely-couple services world, the data and business logic are
effectively separate.  The data is passed into a service and returned
from a service.  This is an important distinction from OO where the
data and business logic typically live together so you often
effectively call methods on the data.

I mentioned that SCA makes heavy use of SDO.  An example of this would
be an SCA component that has a data structure on its service interface
(e.g a Contacts service with a retrieve method).  The interface might
take an id and return a Contact data structure.  The business logic
would create and populate an SDO with the contact details and return
it form the retrieve method.  This business logic would know nothing
about the protocol used to invoke the service.  SCA bindings, such as
json-rpc or soap, would then take that SDO and serialize it out as
either JSON or XML, respectively.

I hope this makes sense.  If you have any specific suggestion for
improvements to the project capabilities/documentation, we'd love to
hear them.

Graham.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"phpsoa" group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to