RE: [ebxml-dev] ebxml virtual appliance

["Roger Bass" <Roger@Traxian.com>]

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:stephengreenubl@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 <Roger@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
>
>