atom feed34 messages in org.ebxml.lists.ebxml-devRE: [ebxml-dev] ebxml virtual appliance
FromSent OnAttachments
Ladislav UrbanFeb 26, 2007 9:44 am 
Monica J. MartinFeb 26, 2007 9:58 am 
Bryan RasmussenMar 15, 2007 4:12 am 
James GovernorMar 15, 2007 4:26 am 
Stephen GreenMar 15, 2007 4:43 am 
Stephen GreenMar 15, 2007 5:36 am 
David RR Webber (XML)Mar 15, 2007 6:46 am 
Matt MacKenzieMar 15, 2007 6:48 am 
Stephen GreenMar 15, 2007 7:01 am 
Sacha SchlegelMar 15, 2007 7:05 am 
Matt MacKenzieMar 15, 2007 7:05 am 
Sacha SchlegelMar 15, 2007 7:12 am 
David RR Webber (XML)Mar 15, 2007 8:07 am 
Stephen GreenMar 15, 2007 8:08 am 
David RR Webber (XML)Mar 15, 2007 8:13 am 
Matt MacKenzieMar 15, 2007 8:14 am 
Matt MacKenzieMar 15, 2007 8:15 am 
David RR Webber (XML)Mar 15, 2007 8:26 am 
Sacha SchlegelMar 15, 2007 8:33 am 
Stephen GreenMar 15, 2007 8:38 am 
Matt MacKenzieMar 15, 2007 8:39 am 
Matt MacKenzieMar 15, 2007 8:42 am 
Arnie ShoreMar 15, 2007 8:42 am 
James GovernorMar 15, 2007 8:47 am 
Matt MacKenzieMar 15, 2007 8:48 am 
Stephen GreenMar 15, 2007 8:58 am 
Stephen GreenMar 15, 2007 9:30 am 
Bryan RasmussenMar 19, 2007 2:30 am 
Roger BassMar 19, 2007 11:20 am 
Stephen GreenMar 19, 2007 12:27 pm 
Roger BassMar 19, 2007 12:37 pm 
step...@systml.co.ukMar 19, 2007 12:44 pm 
Stephen GreenMar 21, 2007 8:44 am 
Stephen GreenMar 21, 2007 8:46 am 
Subject:RE: [ebxml-dev] ebxml virtual appliance
From:Roger Bass (Rog@Traxian.com)
Date:Mar 19, 2007 12:37:10 pm
List:org.ebxml.lists.ebxml-dev

Stephen,

Not using IM currently. I'm intrigued by adding that at some point... but only once we identify processes/components that are stable enough to move down to a pure P2P mode. I'm aware of some possible use cases, we're just not there yet. For now, everything works better going through our server.

Nonetheless, yes, some variety of transport is required - but on the server not the client. For now, we're doing mostly https and FTP. I expect more reliable protocols to be needed at some point, but not yet, despite having some customers with many thousands of transactions a month. (Ad hoc retry rules are working fine for now).

Re "serendipity factor" - any of the stack of parameters that define the connection to a given trading partner absolutely need to be there out-of-the box (and are - completely transparently to the user). The tweaking/ parametrization that's expected (whether server, client or both) should then be only stuff specific to that end-user's process... which can vary by more than you'd think, even across users of the same application.

Roger

-----Original Message----- From: Stephen Green [mailto:step@gmail.com] Sent: Monday, March 19, 2007 12:28 PM To: Roger Bass Cc: Ebxml-dev Subject: Re: [ebxml-dev] ebxml virtual appliance

Just curious Roger: Does it use IM at all and do you think it important to major on a small variety of transport options (IM and/or FTP for example) to increase likelihood of matching capabilities between applications? Might this correspond to a need for maximum defaulting (initially with possibilities for customisation as secondary) to get a happy 'out-of-the-box' 'serendipity factor' (acknowledgments to GKH for the latter phrase for it)? These factors seem important for Bryan's topic (unless I've * completely * missed the point of it perhaps).

Thanks

On 19/03/07, Roger Bass <Rog@traxian.com> wrote:

Bryan, Matt, David et al,

I heartily agree with Matt's comments about ease of use being essential. David and I are both involved offline in a project around Traxian's offering, which I'd described to him as "Skype for B2B" (not that we'll be trademarking that, obviously <g>). Traxian is a lightweight, uniform client for integrating B2B seamlessly with popular applications like QuickBooks - and which leverages hosted services to handle the variability in different partner connections (i.e. format/protocol translation, data aligment etc).

As some real-world background... our first product was a (fairly) pure client-to-client model. Worked well in the lab... but in practice the amount of tweaking and updating required on the client for each end-to-end use case led to poor customer experiences and poor supportability. Pure P2P implementations here can work fine "out-of-the-box" where requirements and interfaces are well-defined and stable - but we're a long way from that in the real world, especially when SMB application integration (vs just file delivery) is a requirement. Approaches that start with message delivery, and see app integration as a "plug-in" will not work, in my view.

To your original question Bryan: the key requirement, I'd suggest, is seamless end-to-end integration. Any technologies or standards that relate to internal/B2B connections are fairly irrelevant from a user's perspective, though they may matter for other reasons.

Regards, Roger