[Laszlo-dev] Data services, OpenLaszlo, AMF, SOAP

[Sean C. Sullivan]

Eric,

What are your thoughts about AMF as the wire protocol for data/RPC services?

-Sean


Eric Bloch wrote:

> Hi Sean,
>
> Some comments interspersed below.
>
>
> Sean C. Sullivan wrote:
>
>>
>> I think I found the answer:
>>
>> http://www.laszlosystems.com/lps-2.2/docs/guide/rpc.html
>>
>> http://www.laszlosystems.com/lps-2.2/docs/guide/rpc-javarpc.html
>
>
> You did.  The Laszlo RPC APIs in 2.2 are new and they are still a bit 
> raw in a few places.  Comments, suggestions, improvements would be 
> great.  We already know there are some issues we're hoping to fix... 
> (as soon as we open up our bug database, you can see 'em if you 
> haven't yet run into 'em).
>
>>
>>
>> Sean C. Sullivan wrote:
>>
>>>
>>> Link:  http://www.richinternetapps.com/archives/000074.html
>>>
>>> <quote>
>>>
>>> I don't want to do a feature by feature comparison here; but a key 
>>> area where I think we have to draw comparison, is in the data 
>>> services layer. I think an underestimated power-point of Flex, is 
>>> the data services tier, which exposes itself to the end user as 3 
>>> MXML tags - RemoteObject, WebService and HTTPService. Using these 
>>> tags, Flex gives us a powerful means of integrating a rich-client 
>>> front-tier with an enterprise middle-tier, which is clearly 
>>> essential for enterprise RIA development. Flex offers us the ability 
>>> to transfer XML over HTTPS, to exchange data using SOAP 
>>> web-services, and finally, a tight binary RPC means of directly 
>>> invoking Java objects, with a great deal of intelligence in the 
>>> mapping of data types, the serialisation of objects, the naming and 
>>> whitelisting of Java services, etc. For enterprise RIA, the 
>>> RemoteObject (RPC) integration is critical, for security, for 
>>> performance and for best-practice enterprise architecture. LPS on 
>>> the other hand, only offers the exchange of XML over HTTP(S), 
>>> requiring server- side architectures to accomodate XML data 
>>> transfer, imposing the parsing of XML (Laszlo supports a limited 
>>> subset of XPath functionality) on the client (something we know to 
>>> be a CPU sucker), and requiring that data passed over the wire is in 
>>> it's most bloated form. 
>>
>
> Bloat isn't actually a requirement for this style of data transfer :-)
>
> Ultimately, it's always up to the developer to decide what XML is sent 
> over the wire in an RIA.
>
> ----
>
> FYI, the quote is a little misleading, too.  XML data proxied by LPS 
> today is parsed on the server (read: no client cpu for parsing)), 
> encoded as actionscript bytecode, string pooled, and optionally 
> gzipped.  XPath processing and databinding is done in the client and 
> that is indeed CPU heavy still, though.  (You can see 
> http://www.davidtemkin.com/mtarchive/000007.html for some comments on 
> how Laszlo support for Flash5 *required* some of this and how future 
> Laszlo releases won't.)
>
>
>
> A best-practice in our RIA development is to avoid
>
>>> passing data over the wire using XML over HTTP for all but the 
>>> smallest packet of data - Laszlo offers no compelling alternatives.
>>>
>
>
> I think you'll find some reasonable difference of opinion in developer 
> communities over what the best (as well as most common) practice is 
> here today.  XML over HTTP is still the most efficient, has the lowest 
> barrier to entry, and requires "less software" (which means it's prone 
> to fewer bugs).  In the future, this may change and we've been trying 
> to track it.  See for example http://www.oreillynet.com/pub/wlg/3005 
> or simply google "soap vs. rest".
>
>
> Best,
> Eric
>
>