Real world SDO/SOA examples

[k***@public.gmane.org]

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 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.


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

[Graham Charters]

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

Post by k***@public.gmane.org
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.

Post by k***@public.gmane.org
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-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[simonslaws-gM/Ye1E23mwN+]

Post by k***@public.gmane.org
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 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.

Hi

To get straight to your specific question about projects using SDO.
There are a few people on this list who have been using SDO on its
own. However I think the real advantage of SDO isn't clear until you
start programming with services. By services I mean any program or
script that has a well defined interface/function and that you might
want to access remotely or that you might want to provide for others
to access (I'm sure that's not the best description of what services
are all about but it works for this conversation).

If I write a PHP service that talks SOAP then I might fire up the SOAP
extension, read in some WSDL and, with simple type parameters I'm good
to go. With complex type parameters, e.g. objects and arrays, it's a
little harder but not too hard to get it going. Now if I want to do
the same thing with, say JSONRPC or XMLRPC, for example, I have to
fire up a different set of APIs and work out how to shuffle my data in
and out of the the remote method calls. Again not hard but different.

We have used SDO in the SCA implementation to abstract this away so
that service methods deal in SDOs and service clients call remote
methods using SDOs. As we have a common format for data (SDO) a
programmer can switch bindings will with very little, if any, change
to the actual business logic. The SDOs are converted to the correct
format for the protocol in use, e.g. XML for SOAP and JSON for
JSONRPC. Both ends of the client/service connection are not forced to
both use SDOs but they could.

SDO allows us to do this as the concept of the Data Access Service
allows the data in memory in an SDO to be converted into the correct
format.

Now SDO isn't the only way of doing this kind of thing, for example,
in the Tuscany Java implementation of SCA users can use several
different approaches to representing data depending on what they are
most familiar with, for example, SDO, JAXB, XML Beans. I'd like to see
a similar flexibility in PHP SCA, for example, by allowing PHP Objects
to be used alongside SDO but we haven't had the bandwidth to support
that.

As SDO is a fairly widely recognized way of representing data another
advantage is that implementations are available in various languages,
e.g. PHP, Java, C++. This gives some consistency to the way you treat
data if you have people who have to work in these different
environments.

I'd be interested to understand the gaps you talk about and maybe we
can fill in some of them. All help is gratefully received of course.

Hope that helps

Simon





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