FAQ : ebXML POC - Why, what, how and ...

[Krishna Sankar <ksankar@cisco.com>]

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 ;-)
--------------------------------
*