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 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@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
-~--~~~~--~~--~--~---
