On 6 Aug, 02:55, "kbc... gmail.com"
<kbc...gmail.com> 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 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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---
|
