[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] UBL payload and client-server integration tools
Fulton, Actually I'm deep into AJAX right now. Oracle have an excellent open source toolset available. However - for me the power of the RIA approach is 1) Layering the solution (which was the whole permiss to XML) so rendering, rules, form, xml all separate. 2) Being able to make things agile and dynamically context aware (XML scripted) 3) The DOM inside the browser client is way more powerful than anything we had before. So - unlike your model - I'm seeing - yes - we do those realtime RIA requests and updates - but what is happening is you are building up the information you need in the DOM at the client interactively. Once its all complete - then you hit "Send" - and the RIA then packages the UBL transaction and dispatches it to the server for delivery. That delivery could involve traditional B2B style reliable exchanges. What you've saved is having to package / validate the XML on the server. Here's a recap' of how this works (layers details exposed): 1) RIA works with user and database to collect valid content to client 2) DOM in client is updated with labelled data fields ( notice those labels match the UBL names....) 3) Javascript invoked by "Send" button - it opens up a XML template of the UBL (hint: CAM templates work great!) and simply does substitutions matching data labels to structure placeholders. This is "code free" + re-usable - if you change the template - add more fields - then the "Send" requires zero changes. 4) UBL XML transmitted to server via browser XML send command. 5) Server places XML in outbound queue for sending via secure B2B system. What is way crazy about all this is that Duane and I built a prototype for this back in 1999 for a example selling products - simple catalogue in XML, pick, buy. Javascript + DOM + XML = very slick! DW -------- Original Message -------- Subject: [ubl-dev] UBL payload and client-server integration tools From: Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com> Date: Thu, November 09, 2006 6:58 pm To: 'Stephen Green' <stephen_green@bristol-city.gov.uk>, ebxml-dev@lists.ebxml.org, ubl-dev@lists.oasis-open.org Stephan et al: I am leveraging your note regarding UBL payload, but in a somewhat different context - hence the different subject line. The parallel with your note is that there are various ways to leverage the payload IP of UBL, even though the middleware and transport would be something different. 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. Presumably, as the user adds or deletes ingredients, the client-side software updates the price and perhaps validates the feasibility of the pizza, via calls to the server. Given that client-server responses need to flow consistently with the user's thought processes and rate of data input, RIA proponents are concerned about performance and therefore prefer binary data transfer rather than text and cannot afford a lot of XML 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. 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. 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. What are the implications of fairing UBL into RIA architectures? 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. It is still early days for RIA, but perhaps not too early to consider the implications for UBL and other Oasis standards. Fulton Wilcox Colts Neck Solutions lLC -----Original Message----- From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk] Sent: Thursday, November 09, 2006 3:51 AM To: Stephen Green; ebxml-dev@lists.ebxml.org; ubl-dev@lists.oasis-open.org Subject: RE: [ubl-dev] A UBL Customisation (beta) for general use Offlist I was reminded that assimilation of the payload is the key consideration here so I guess we're talking fast infoset for the binary so as to allow the payload to be treated similarly to XML for those used to XML but for those receiving messages who already have telecoms technology then other binary formats may be appropriate. Stephen Green >>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 08/11/06 16:23:14 >>> Hi David, Is this confusing ASN.1 and AS2? I think the use of ASN.1 would be non-XML payloads using one of several binary formats which rely on a schema written not in XSD but in ASN.1 notation (though mappable to XSD). It gives the advantage of preformance and/or small size and allows greater compression than with .zip or .gz, I believe. I think it predates XML in its use in the telecoms industries but nicely complements XML now that the latter is at the fore. So we are here talking payload, but with some bearing on other layers perhaps. And I guess what I'm after is any info on whether/how ebXML layers might need adapting to cater for it (e.g. I guess the list of schema formats in the ebBP references to schema type won't include 'asn.1' so implementers might have to use 'other') - plus any general stories about successful use or otherwise of the ASN.1 provisions in UBL - either with ebXML or otherwise. Would, in fact, it be prudent/advantageous to use ASN.1 with ebXML? Or - a key question - is there already a preferred framework used with such binary payloads? I haven't come across any previous questions about this on these lists so maybe this is still virgin ground. It could be important for large files though. All the best Stephen Green >>> "David RR Webber (XML)" <david@drrw.info> 08/11/06 15:32:29 >>> Stephen, I just noticed this post. This week on the Hermes 2 dev list - some people are looking to use Hermes 2 as a bridging server. Basically Hermes 2 is pluggable - and supports both ebMS and AS2 - so it can talk on either channel. You'd have to have something in between to extract payload and then repackage it - but I suspect all the parts are there to make it so. Cheers, DW -------- Original Message -------- Subject: Re: [ubl-dev] A UBL Customisation (beta) for general use From: "Stephen Green" <stephen_green@bristol-city.gov.uk> Date: Thu, November 02, 2006 11:44 am To: <ebxml-dev@lists.ebxml.org>, <ubl-dev@lists.oasis-open.org>, <stephen.green@systml.co.uk> By the way, folk might note, following on from UBL's packages, we included a set of ASN.1 schemas for our subsets. Has anyone actually managed to implement UBL with ASN.1 and are they able to comment on their experience of this? I'd be especially interested to know what might be involved using ASN.1 with ebXML, such as ebMS. Is it feasible? I suppose it would mean transforming the binary into MIME. What would be the preferred binary format and how would MIME handle it? What values would be in the ebXML artefacts? Are there any products doing this? All help appreciated. All the best Stephen Green >>> <stephen.green@systml.co.uk> 01/11/06 15:07:10 >>> I'm happy to say, on behalf of SystML, we have finished a beta customisation of UBL versions 1.0 and 2.0 which is freely available at www.systml.co.uk/xml/ for use at your own risk. We hope you will provide feedback which could go to us at info@systml.co.uk It was produced by SystML and by HavanaWave AG (Sacha.Schlegel@HavanaWave.com). Obviously, it being at the beta stage, it is subject to possible change (though we'd bear in mind that we should consider possible users when contemplating any change) and how you use it is up to you provided you do so at your own risk. Maybe if this is all sufficiently satisfactory we will find the means to preserve it, long term, as it is (perhaps just changing the status to 'complete'). Zip packages are provided for those who prefer the possible extra security of storing it locally (much as you would with the source code of opensource, say). I'm very grateful to all who've helped us with this project to get it to this stage - to God and to colleagues : Thanks. :-) All the best Stephen Green --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]