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:step...@systml.co.uk (step@systml.co.uk)
Date:Mar 19, 2007 12:44:30 pm
List:org.ebxml.lists.ebxml-dev

Afterthought - wouldn't it help to establish a default protocol profile - effectively a profile profile :-) if one uses a CPP say to express it? I.e. a default, generic CPP and maybe give it a name. Hopefully NOT 'Small Business Profile' :-) unless one was happy with calling the original UBL subset the 'Small Business Subset' which was needed by businesses not calling themselves small businesses and therefore an unpopular name. In Bryan's case maybe 'Northern European Profile' NEP is a suitable name to go with NES 'Northern European Subset' but in Traxian's case maybe SystML would publish some CPP like the UBL subsets SystML1 and SystML2 :-) We got close with Sacha's and mine's UBP 'Universal Business Process' and maybe the need is for a 'Universal Business Profile' (unfortunately can't be UBP unless we call both together UBPP - Universal Business Process and Profile). Maybe this is a job for the ebCPPA TC instead or as well - but is this software or a standard (open either way)?

All the best

Stephen Green SystML Bristol, UK

Quoting Stephen Green <step@gmail.com>:

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