[CAnet - news] AJAX, RESTful and BPEL in bed together?

For more information on this item please visit the CANARIE CA*net 4 Optical
Internet program web site at http://www.canarie.ca/canet4/library/list.html
-------------------------------------------


 [There has been increasing concern that within the W3C and OASIS web
services standards have become increasingly complex and unwieldy.
Developers are now turning to much simpler tools such as AJAX, RUBY and
RESTful to implement SOA solutions.  For those developing service oriented
architectures for eScience, eLearning or wide area networked applications
the following approaches using RESTful and AJAX may be of interest -- BSA]


http://blogs.zdnet.com/service-oriented/?p=543

http://www.infoworld.com/article/06/02/08/74979_07OPstrategic_1.html

http://www.onjava.com/pub/a/onjava/2006/02/15/jython-soap-interface-to-rest.
html

The browser as orchestrator
Modern Web browsers can be powerful tools for composing services

I'm bullish on client-side intermediaries and orchestrators. For me, at
least, this is the AJAX (Asynchronous JavaScript and XML) endgame. Service
composition in the browser can, and will, nicely complement service
composition in the cloud. AJAX and BPEL aren't in bed together yet, but mark
my words, it'll happen.

Second, I'm cautiously optimistic about the future of the kinds of advanced
Web standards that can make this stuff really sing. The latest W3C APIs all
worked well in Firefox 1.0, and they work even better in 1.5TECH WATCH 

It's tremendously difficult to argue a RESTful approach to a
service-oriented architecture (SOA), when the corporate mindshare is
SOAP--where project stakeholders tout the SOA buzzword, nod their heads
sagely when you say SOAP, nod their heads again when you say XML-RPC, and
then look blankly when you mention REST. At an official level, it seems that
for the IBMs, Suns, Microsofts, and Oracles (et al) of this world, REST
isn't even on the radar; perhaps more because they would find it difficult
to build a commercial strategy around something that is based on simplicity
and standards (like HTTP) that have been around for years, than from a true
lack of visibility at the coalface. So when the push from on high is for
SOAP web services and associated technologies, and your business partners
and colleagues have been drinking the Sun/MS/IBM/etc. Kool-Aid, you're
generally fighting a losing battle if you're promoting alternatives.


While you might usually end up stuck in a buzzword-compliance nightmare,
with packets of WSDLs, BPELs, and SOAPs flying around left, right, and
center, there are occasions where it may be possible to push through a
REST-style, resource-centric approach; where there is no official strategic
direction for SOA already in place, where there is a reasonable amount of
flexibility and imagination on the part of the project owners, and perhaps
with a bit of technical enlightening on the part of the technical lead(s).

The best method I've come up with so far to get around this issue is to
deliver both. Design the core of your system with REST resources, and
subsequently plug in some kind of interfacing or adapter to the REST
components, in order to deliver SOAP messaging for those who require it. 

A side note: there are, of course, SOAP web methods, which provide an HTTP
verb-style interface to a standard SOAP web service--which would be a more
direct mapping to a REST resource. But if you're using a form of
orchestration, pulling a number of services and processes together with
something like BPEL, you are potentially going to be constrained (at the
very least by convention, but perhaps also by technical considerations of
the orchestration and choreography tools) to using GET and (more commonly)
POST for your SOAP methods.




-------------------------------------
To SUBSCRIBE:
send a blank e-mail message to
[email protected]

To UNSUBSCRIBE:
send a blank email message to
[email protected]
-------------------------------------

These news items and comments are mine alone and do not necessarily reflect
those  of the CANARIE board or management.

-----------
[email protected]
www.canarie.ca/~bstarn
skype: pocketpro
SkypeIn: +1 614 441-9603


_______________________________________________
news mailing list
[email protected]
http://lists.canarie.ca/mailman/listinfo/news