[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Re: [ebxml-dev] P2P for e-business - applications?
Steve, Actually I think we need LESS of test suites and more of software that just works EASIER! Notice I've been saying for years - what happened to simple XML and the vision Jon and Tim gave us? 10 years ago when we started the XML/edi Group - the whole promise was agile information exchanges - the Fusion of Five. Using simple re-usable XML components to move away from static rigid EDI-style B2B. Also the critical piece overlooked is the 5th one - Agents. This was drawn from my experience with Prolog and being able to build smart interfaces that are fault tolerant and self-aligning given a wide range of inputs - instead of being dumb and brittle. But who are the drivers here - the end users or the big consulting and vendor implementers? Ask yourself - why we have gone from simple XML concepts to wildly complex programmer controlled systems - driven by the W3C extensions to basic XML, XSD, namespaces, complex typing, object models, and the list marches on. B2B is not a main W3C focus - just an afterthought - and mainly what has happened is that EDI has been morphed into XML syntax - that's like a veneer of complex markup overlaid on top of the raw data - that has really not fulfilled the whole promise of making self-aligning interfaces possible. We have a work in progress. And instead of going for more simplicity - we're told to bet on Web2 stuff now - and even more PhD complexity like OWL and RDF - which makes great research projects for the academics that help run the W3C - but is it useful in the real world? If all I'm doing is selling "tins of baked beans on eBay" - I don't need all that right? I want stuff that makes my life very simple - like the UPS advert on TV - there's 8 things in running your business - and you want to focus on the two that make money - services and marketing - and the other 6 should just "be there" - print a label for UPS - let them take care of that - its all in the label encoding. Which brings us back to CAM templates - and being able to create simple means to allow agent software to act on the exchanges - align them - and make them work with minimal user intervention. That's the promise of CAM - making the software able to be smarter by providing a common simple representation of the essential alignment concepts needed. I do agree that the core of ebXML provides mechanisms that expose the facilitators and glue for this. What we've been grappling with is exposing those in simple and re-usable ways - and finally we're getting there. Take for example CPA. The original TPXML was relatively simple - then CPA xml was derived by programmers and added scary levels of complex syntax overhead to that - that was tough to challenge without appearing to be a Luddite - and obfuscation and false turns - and finally - after years of head scratching - we're now able to profile and hide that machine level complexity using XML techniques - that allow the user to treat a CPA in a simple and obvious way. It's not been trivial getting there, but now CPA v4 beckons that can eventually take that to the next level of easy (maybe just part of the UPS 3D barcode next?) That's the core of the "P2P" model - not the fact that it uses P2P or whatever - but that's it simple to setup and use effectively - while enabling the users to do powerful collaborative tasks in a secure and reliable way - that's what I believe people mean when they say "P2P". I believe we have turned a corner here - driven by advances that have helped and empowered us that are nothing to do with XML. The maturity of java tools now compared to 1997 - makes it vastly easier to do exciting, sophisticated and interesting things (I can even do Prolog in Java!) more easily for single developers. The CAM engine is a living example. Also the OSS model has empowered communities to displace large vendor lock-in coupled with the internet that provides the mature collaborative medium today. And then business has realized that they can use this all to create real solutions based on open community standards and paid people to do it and companies like RedHat emerged. Those three things are powering ebXML forward today - and I view it as merely a matter of time here before the B2B applicance emerges - and the next generation of integration kicks-in as people learn collaboratively what can be enabled easily. Putting these peices together and making it easy takes time - and five years into the ebXML work - things are looking very promising. We still have much to do - but the tools are so much better and more empowering - and that is the key here - to create that global adoption we have long sought and know we need ultimately. It's not just one thing by itself - but the Fusion of Five that we're still seeking to make happen here. Cheers, DW "The way to be is to do" - Confucius (551-472 B.C.) -------- Original Message -------- Subject: RE: [ubl-dev] Re: [ebxml-dev] P2P for e-business - applications? From: "Stephen Green" <stephen.green@bristol.gov.uk> Date: Wed, April 04, 2007 5:22 am To: <ubl-dev@lists.oasis-open.org> Hi Roger What you suggest in terms of an analogy to credit card products and services is of course still reliant on a third party - the banking agency. Maybe this aludes a bit to a banking agency providing the subset/customisation and process profiles and maybe too a default CPA template. We tried doing this from a community/public body stance but it looks like it may well be taken over by organisations close to the banking industry. Whichever organisation or person provides the technology standards and profiles it looks to me like product developers need a way to just drop the output of the trading party agreements (in your analogy that would be merely the credit card product type selection but in B2B that might be a CPA, a subset profile - say a CAM template - and a process profile - say an ebBP definition instance) into the respective product and convert that into the necessary set of configurations and maybe registry entries. I guess it's worth thinking about developing tools to better support all this and maybe piloting some proof-of-concept implementations and interoperability evaluations. Of course ebXML has something well matured in this area with regard to use of ebMS. Maybe now that the ebXML IIC nearly has completed profiles and there are also profiles coming out for UBL like UBP, SystML1 and SystML2, NES and UBL-like TWIST (? need more info on this), maybe now the time is right for someone (as Drummond did for ebXML) to devise some interoperability testbeds. I just hope things don't stall before this can happen. Maybe it needs some government and/or bank backing. It would be nice though to get as many countries and regions invloved as possible, perhaps industries too. All the best Stephen Green >>> "Roger Bass" <Roger@Traxian.com> 04/04/07 07:50:57 >>> Stephen, Well, ok, so collaboration's potentially interesting - still not convinced that P2P or any other one specific underlying technology is required to make that happen. But there's a bigger problem - the scenario you describe contains two things each of which is hard on its own, and extremely hard to the point of implausibility when you put them together. First, you describe the exchange of standardized messages to configure the end-point systems for B2B. The big problem (especially with SMBs) is that virtually none of the real business systems SMBs use have any notion whatsoever of sending/accepting any such standardized messages to configure an exchange. Even the more basic need of just getting a PO or invoice document in or out is a challenge. And even where it's possible, it's going to be in whatever legacy format they happen to support, not any "preferred standard" document. So given this environment today, the exchange of standardized B2B messages from peer-to-peer adds relatively little value, to the extent it ignores the more important job of actually integrating those messages with the existing systems. Secondly, you talk about "clerks" customizing the setup of business processes between the two businesses, with the notion that those customizations will flow through and be understood and supported by the business systems. This may not be far-fetched in the context of ebXML CPAs, but it's fairly far-fetched given real-world SMBs, their systems, and their people. In reality, what I see with our customers is each SMB having its own internal process - and yes, wanting some degree of customization to fit with that. But this is first about them, and second about partners, who they ideally want to all look the same as far as possible. In other words, it's more of a one-time setup as to what they want and support. It's certainly not end-users negotiating case-by-case with partners. The better analogy would be a merchant posting on their storefront that they accept Visa, Mastercard and American Express. A shopper with Discover and Amex then decides which card to present, but it's the same payment process for the merchant. That's more the negotiation. In our context, I expect mostly that this negotiation would be automated based on the capabilities and preferences that each party has expressed to set up the electronic relationship accordingly. So here, even the experience of each party is some way from the "collaborative" process you envisioned. (And even that more collaborative process you describe fits P2P less well than you suppose, given the first point about the constraints of dealing with the internal business systems). BTW not sure where your last comment came from. I'm not saying there's not value here. There's huge value... in actually solving the problems that SMB users care about, and applying appropriate technologies to do so. As technologists, it's very easy for us to fall into "man with hammer seeing all problems as nails" way of thinking... especially in a group like this that's defined by technologies. The only value in P2P (or standards, or any other technology) is enabling solution providers to incrementally reduce costs. As to expense... well yes, it does take effort to make this work, but there are consulting business models, and mass market product models. Despite our similarities, David and I have different business approaches that affect what customers do and don't end up paying for. Best regards, Roger -----Original Message----- From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk] Sent: Tuesday, April 03, 2007 10:25 PM To: ubl-dev@lists.oasis-open.org Subject: RE: [ubl-dev] Re: [ebxml-dev] P2P for e-business - applications? Hi Guys So it looks like it is still on the horizon, albeit with some vendor reluctance, then. I could imagine it being very useful for situations where there is collaboration needed: you mention the problem there is in parties agreeing business processes and I'd add to it agreement of the constituent parts of a document (customisation as UBL calls it). Maybe products will one day use IM or the like to provide collaboration; like chat but more structured and controlled, point-to-point, clerk-to-clerk as it were. This could result in configuration of both systems for the subsequent B2B. It's not so far fetched when you look at the negotiation of CPAs in ebXML. So what's the point of point-to-point? :-) Not much more than allowing collaboration in real time. In B2B I'd regard that as imperative for trading agreements but not necessarily for the business itself. But if it is provided for agreement resolution then why not allow it to be used subsequently for the business itself. But all this talk of expensive development just makes me think there must be more value in doing it than you guys say or you wouldn't be talking about it still :-) All the best Stephen Green Quoting david.lyon@preisshare.net: > Quoting Roger Bass <Roger@Traxian.com>: > >> Stephen, David et al, >> >> I'm jumping into this thread a little late... > > no - unfortunately it is still an ongoing thing... > >> This technology discussion all misses the point. From a pragmatic SMB's >> perspective, all they care about in this context is interconnecting >> their business processes with one or more of their trading partners - >> and having that be easy and inexpensive enough to be worthwhile, in the >> context of the overall business relationship. (The paper you link is >> quite flawed in its most basic premises and approach, IMHO). > > Pretty much. I'd second that. > >> Don't get me wrong - I'd love to have a technology that could do at >> least some connections P2P, and would do it for free. > > I think that there's a lot of talk and promises about this in the > marketplace. But it usually comes down to it needing some (quite) > expensive programming being done in an outsourced setting. It starts > off with the promise of cheap... but ends up being more costly than the > clients could have ever imagined because you end up having to provide > on the job training for the programmers even though you are being > charged full market rates. > > It's interesting to pick up the pieces anyhow. > >> In fact, I expect we will end up doing P2P in future - but only >> once we have a big enough group of SMBs connected to have a stable set >> of end-to-end process requirements. Then and only then will we (or >> anyone else trying to do this) be able to deliver a P2P product that >> actually works. >> >> There are no short cuts here. > > I think that's what a lot of us are trying to do. Sounds like a > familiar soapbox anyway. > > Regards > > David > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org ______________________________________________________________________ Please note the new simpler name for our website: http://www.bristol.gov.uk Our email addresses have also changed - visit http://www.bristol.gov.uk/bigchange for further details. Sign-up for our email bulletin giving news, have-your-say and event information at: http://www.bristol.gov.uk/newsdirect ______________________________________________________________________ Please note the new simpler name for our website: http://www.bristol.gov.uk Our email addresses have also changed - visit http://www.bristol.gov.uk/bigchange for further details. Sign-up for our email bulletin giving news, have-your-say and event information at: http://www.bristol.gov.uk/newsdirect --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]