[ajug-members] webservice development

[Laura Moore]

http://www.odata.org/faq

Curt,  thanks for the postmortem on SOAP,  from what I read you are
not alone.  Maybe Gunner can persuade your team to give a demo on
HazelCast for the group?   I'd buy a round of Margaritas to learn
about a SOAP alternative...

On Friday, March 18, 2011, Curt Smith <csmith at javadepot.com> wrote:
>
>
>
>
>
>
>     Laura,  what is odata?
>
>       I'll offer a postmortem on a company's experience with a 3rd party
>       interface and internal app to app interfaces.   The transport is
>       soap over http and soap over http call back for push events.
>       Soap turned out to be very expensive in the maintenance phase that
>       lasted over the years.  Versioning, various inter-op problems due
>       to the soap spec's changing and stacks not playing well with each
>       other, schema versions etc etc, the real world was not as nice and
>       low cost as the hello-world service the container vendors show can
>       be done in 45 seconds.  I would never choose soap for any project
>       at this point.   So what else?  For true bidirectional eventing
>       I'm frustrated with only having synchronous request and call back
>       as the paradigm at least for the public side, for internal to the
>       NOC there is another choice (at least).   We've built a rest
>       service and when state needs to be serialized we're using JSON, a
>       blazing fast and simple encoding.    For in the same shop we're
>       moving to HazelCast as an object replication wrapper and side
>       stepping the service and client paradigm all together.  IE
>       replicate state at the domain model core and git rid of several
>       layers and thousands of lines of service/client code.  HazelCast
>       is functionally similar to coherance/terracotta but much simpler
>       to program and deploy.  It's just a few simple wrappers to lists /
>       maps etc and a few jars and open source.
>
>       Summary:  SOA especially service buss is a vendors dream in my
>       opinion and ends up snow balling into huge costs for the owning
>       company.  If you do a development budget postmortem I bet you'll
>       have spent around half (for this project anyway) of your effort on
>       just the serialization and transport of the data and events and a
>       small portion on your actual purpose the business logic.  That's
>       crazy, right?  There needs to be new and simplier tools for
>       applications to interact than soap and xml.  For me and one
>       company that's json over naked http and some rest.   Within the
>       clustered app we're having success with tools like HazelCast.  The
>       three main object replication API projects (above) also offer all
>       in memory queue and remote execution metaphors besides object
>       replication functionality.
>
>       Good luck,  Curt
>
>     On 3/18/2011 6:15 AM, Laura Moore wrote:
>
>       A talk from the architects at Turner a few months back had good advice
> on designing your data services using odata to be flexible for
> clients,  and reducing overall maintenance work where the business
> value is really in the data itself.   They differentiated data
> services from business services where the value is in the processing
> and orchestration done to the data.  Data services give clients the
> power to drive what information they receive in a query,  so you don't
> have constantly version and revise your contract for each new
> requirement.  Business services stay high level and coarse grained,
> process driven.
>
>
>
>     --
>
> Curt Smith
> csmith at javadepot.com
>
>
>
>