Re: [ubl-dev] UBL payload and client-server integration tools

[david.lyon@preisshare.net]

Quoting Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>:

> Stephan et al:
>
> I am leveraging your note regarding UBL payload, but in a somewhat different
> context -

Ok.

> As is widely known, there are various tools and techniques used to recreate
> client-server selective updates, under the rubric "rich internet
> applications" (RIA). For example Adobe's Flash brings back 1990's style
> field-at-a time-update/validation with "Flash Remoting." Flash is certainly
> not the only RIA option, but it holds some high ground because of the
> ubiquity of Flash agents.
>
> For reference, see http://www.amfphp.org, which is the home page of an open
> source Flash Remoting gateway. As it happens, the example shown on that page
> is a configuration-style order transaction for pizza.

It's an interesting idea.

> RIA proponents are concerned about
> performance and therefore prefer binary data transfer rather than text and
> cannot afford a lot of XML overheads.

I'm sure the issue is not about the bandwidth or processing overheads.

> As RIA tools become more commonplace and accepted, thousands of programmers
> will use RIA calls to create or to consume what are or should be UBL
> transactions.

Maybe.

> Unfortunately, designers in the RIA world tend to be unaware
> of any of the relevant payload standards or are dismissive of those
> standards because they do not see a way to achieve high performance with
> text.

Maybe they should do more in promoting this.

My own experience is that "performance" criteria is often set by the  
businesses that the technical people work for. And often the middle  
managers don't want the computers to work to fast.

Often I've heard people in big companies being afraid to ask too much  
of their SAP and other systems. I even get the impression they are  
scared of their computers :-)

> There is also the issue that for RIA there may be a marked preference
> for dealing with a UBL transaction in pieces rather than as an entire
> document - e.g., call for the deliver-to address first to see if the vendor
> even wants to consider this order.

Maybe

> What are the implications of fairing UBL into RIA architectures?

Finding people to do it...

> One proposition would be to repackage UBL for RIA client-server use. Doing
> so is particularly helpful in avoiding a downstream need to translate some
> ideosynchratic ad hoc transaction design into something useful to the other
> party to the transaction.
>
> The second is to consider use of RIA techniques within the more typical
> eBusiness server-to-server exchange of transactions. RIA calls are built for
> speed and light touch on bandwidth, so the fit would be to highly repetitive
> transactions - e.g., price checks, inventory availability checks,
> transportation scheduling, etc.

True.

> It is still early days for RIA, but perhaps not too early to consider the
> implications for UBL and other Oasis standards.

Of course

David