Subject: FAQ : ebXML POC - Why, what, how and ...
Hi, As there are and will be more new members to the POC, I have tried to capture some common FAQs. This is just the starting point - please send me your thoughts, more questions and ideas. At some stage, I will make a pdf out of this as well. The e-mail version is easier to reply to, quote (or mis-quote ;-)) a few lines and other activities we need to do when we are working on it. ==================================== * What are the goals of POC ? The major POC goal is to validate the various ebXML specifications. The various ebXML specifications should reflect real-world implementations and the best way is to achieve that goal is to implement the specs are they are being developed. Towards this goal, the POC would attempt to have more than one INDEPENDENT implementations. An implementation need not and will not be an end-to-end system by one participant. It would be a group of participants implementing parts of the ebXML specifications. For example may be two vendors have TRP security implementations and some other two or three vendors will show TRP reliable messaging. Another set of vendors will have registry implementations which all the others will use. -------------------------------- * What are the POC philosophy ? All the "old-fashioned" ideals - co-operation, collaboration, base on PUBLISHED ebXML specs, no one offs, no complete solution from one participant, interoperability (should have at least 2 INDEPENDENT implementations), no vendor products, religious/animated technology discussions, partying, .... "None of us is as smart as all of us" could very well be our motto ! -------------------------------- * What have been done so far & what are the references available ? One of first things to do, for a new participant, is to understand what has been done before. The relevant documents are : [1] Tokyo POC : http://lists.ebxml.org/archives/ebxml-poc/200011/msg00014.html [2] San Jose POC : http://lists.ebxml.org/archives/ebxml-poc/200008/msg00010.html [3] Tokyo POC web site with all samples, DTDs et al : http://www.ebxml.org/project_teams/poc/private/tokyo_docs/index.htm [4] Tokyo POC slideware : http://lists.ebxml.org/archives/ebxml-poc/200011/msg00117.html [5] Some preliminary ideas on a POC Competency Center : http://lists.ebxml.org/archives/ebxml-poc/200011/msg00029.html Another idea is to work with somebody who has been there before. All POC participants will be glad to work with and help the new comers. Soon there *could* be a POC Competency Center and a conformance suit so that participants can test their implementations. (This more of a wish, rather than any specific initiative, as I know now. And I am not privileged to the inner workings of the steering committees and the powers to be ;-)) -------------------------------- * What is a POC proposal ? What should a POC proposal contain ? A POC proposal is a business scenario, usually taken from one or more industry verticals, which shows some e-business interaction. The more specialized this is to a vertical, the better. But there is room for generic business processes as well. The documents [1], [2] and [3] above should prove as some past examples. A proposal should have (at the minimum) a) Business scenario, b) The relevance in the industry, c) Use cases, d) The roles, e) A sequence diagram showing the interactions between the roles, f) The DTDs for industry specific payloads, g) A sample of all the messages. Then the POC will vote (to accept or not to accept, of course, is the question) and if accepted the various participants can play the different roles. Usually, a role matrix would be developed, showing who will do what role. Also, a topology would be required, to show the physical architecture. -------------------------------- * What about the software IP ? There are two kinds of pieces - some vendors embed the ebXML in their products - for example the hub product will add the ebXML TRP as a part of the product. In this case, we cannot expect them to forgo the IP for their product ! Some other vendors might implement the ebXML pieces as a stand-alone system - for example a registry or the TRP layer. In this case, if the vendors want, they can "donate" the code as open source. It is my hope that there would be some open source which has all the ebXML components and layers. May be we should try the apache foundation for such an initiative after the "Geneva" POC. -------------------------------- * Can we show-case our products ? Not at the POC. The max exposure one would get at a POC event (which is different from a Marketing event) is the logo and the presence of the people. -------------------------------- * What about press/marketing events ? So far, marketing events have been an abstract - a Reader's Digest (condensed) version of the POC. Marketing events are more visual and the message is a little different from POC. While POC emphasizes interoperability and technology, marketing's emphasis is on participation from a large number of vendors, showing ebXML is real and is being used in products. (Of course, I am the wrong person to talk about this ;-) - I wouldn't be able to sell a heater to an Eskimo or a generator to the power-strapped Californians ;-0.) The ebXML awareness mailer is dedicated to the marketing activities. In future marketing events, there will be opportunities for more exposure of companies and their products. One of the marketing message would be that, more vendors have ebXML in their products. -------------------------------- * Is there a life after death ? Sorry, not a POC question ;-) -------------------------------- *
Powered by
eList eXpress LLC