| 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: | 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
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





