| From | Sent On | Attachments |
|---|---|---|
| Ladislav Urban | Feb 26, 2007 9:44 am | |
| Monica J. Martin | Feb 26, 2007 9:58 am | |
| Bryan Rasmussen | Mar 15, 2007 4:12 am | |
| James Governor | Mar 15, 2007 4:26 am | |
| Stephen Green | Mar 15, 2007 4:43 am | |
| Stephen Green | Mar 15, 2007 5:36 am | |
| David RR Webber (XML) | Mar 15, 2007 6:46 am | |
| Matt MacKenzie | Mar 15, 2007 6:48 am | |
| Stephen Green | Mar 15, 2007 7:01 am | |
| Sacha Schlegel | Mar 15, 2007 7:05 am | |
| Matt MacKenzie | Mar 15, 2007 7:05 am | |
| Sacha Schlegel | Mar 15, 2007 7:12 am | |
| David RR Webber (XML) | Mar 15, 2007 8:07 am | |
| Stephen Green | Mar 15, 2007 8:08 am | |
| David RR Webber (XML) | Mar 15, 2007 8:13 am | |
| Matt MacKenzie | Mar 15, 2007 8:14 am | |
| Matt MacKenzie | Mar 15, 2007 8:15 am | |
| David RR Webber (XML) | Mar 15, 2007 8:26 am | |
| Sacha Schlegel | Mar 15, 2007 8:33 am | |
| Stephen Green | Mar 15, 2007 8:38 am | |
| Matt MacKenzie | Mar 15, 2007 8:39 am | |
| Matt MacKenzie | Mar 15, 2007 8:42 am | |
| Arnie Shore | Mar 15, 2007 8:42 am | |
| James Governor | Mar 15, 2007 8:47 am | |
| Matt MacKenzie | Mar 15, 2007 8:48 am | |
| Stephen Green | Mar 15, 2007 8:58 am | |
| Stephen Green | Mar 15, 2007 9:30 am | |
| Bryan Rasmussen | Mar 19, 2007 2:30 am | |
| Roger Bass | Mar 19, 2007 11:20 am | |
| Stephen Green | Mar 19, 2007 12:27 pm | |
| Roger Bass | Mar 19, 2007 12:37 pm | |
| step...@systml.co.uk | Mar 19, 2007 12:44 pm | |
| Stephen Green | Mar 21, 2007 8:44 am | |
| Stephen Green | Mar 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
Stephen Green
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





