RE: [ebxml-bp] [Fwd: On Page 18 of the ebXML Business ProcessSpecification Schema it gives an example of a notification transaction]

["J. Dean E. P. Hemopo" <jdeanh@ihug.co.nz>]

thanks for the message.

yes i have commercial aspirations for ebXML, my country has only 4 million
people, and noone, and i mean noone is doing ebXML.  so i thought i would do
it.

i like the idea that has not been done before in new zealand, i like the
fact that it is bleeding edge technology and i am in it.  i also have a bit
of a teacher in me, so i dont mind sharing concepts, but hug the code close
to me.  sorry about that if it upsets you.

i am building the lot, yep, and i believe i can do it.  have not had any
problems for 3 months, specs make sense.

since you gave me some goodies to chew on, here are some of mine:

how i see CPP to CPA:

i have lined up all the elements and attributes on paper, copied it, drawn
lines between specific memebrs, and asked myself "what do i do when there is
a conflict of entries".  that part was easy, but the negotiation stage you
were talking about is difficult.

how i see the registry:

i have bought two database products, one native XML database (Quilogic
IMDB-in memory database) and db4o (database 4 objects).  i store the core
registry as depicted in the RIM V2 spec, i do the same for the BPSS.  the
business process editor factors into the registry, and XML.  ALL XML
documents i receive, get stored in the XML Native database (both databases
have a small footprint).

keynote, the registry is really only a search engine for stored stuff and a
repository in which we store stuff, any real processing is done at the
Client, thats where i build in BPE (business process editor).  IMPORTANT:
the registry databases are fine for ebXML Clients, and a Registry with say
100 concurrent requests at a time (thats an educated guess).  i would use
Matisse object database and Tamino XML database for the registry in a
fullblown commercial Registry.  my project, all products are commercial, but
the registry is merely a prototype:  with a view to moving to the
commercial, scalable systems mentioned.  in fact i am negotiating with a
amjor company building a commercial ebXML suite as we speak.

how i see the message service handler (MSH):

pretty well got this sorted out, the easiest of the suite to build.

and the ebXML client:

well this is where all the work gets done, including bridging into an ERP
system, or MYOB.  depaends on your scale.

well, i think its important to keep things simple.  i am still in the
logical design phase, will be so for 3 months.  this is not a "open-source"
vs commercial issue, but it is about delivering cost saving, value-adding
improvements and the facilitation of business.  thats why i am going for
"shrink wrap off-the-shelf" product.  to put solutions in the hands of
SME's, who could not particpate in EDI, not some moralistic crusade.

nice talking.

dean hemopo
auckland, new zeland



-----Original Message-----
From: Sacha Schlegel [mailto:schlegel@cs.curtin.edu.au]
Sent: Saturday, 19 June 2004 9:34 a.m.
To: J. Dean E. P. Hemopo
Cc: Monica J. Martin
Subject: Re: [ebxml-bp] [Fwd: On Page 18 of the ebXML Business
ProcessSpecification Schema it gives an example of a notification
transaction]


Hi J. Dean E. P. Hemopo

What a long name :) and what an ambitious project.

I have looked at your website and see that you have commercial and
business interest in your mind. No problem with that ;) just a little ;)

What is your academic goal? What do you want to achieve? Just
to implement these tools or do you want to find something, or do
something no one has done before?

My first thought was, wow cool, you could use the open source ebXML
registry/repository and the open source Hermes Messaging System, look at
my open source ebXML Business Service Interface (is incomplete), my open
source CPA composition tool (incomplete) and open source CPA negotiation
system (incomplete) and make all these tools better! for the next
reasearcher or ebXML supporter.

Actually I belief that if we would have a free and open source ebXML
suite implementation today, that would drive adoption much much faster.
Then all those small business application providers (open source or not)
can take and use the open source ebXML suite and realise ebXML from A to
Z today.

Anyway back to the topic of ebXML

ebXML Registry/Repository: Can not help you much here
ebXML Messaging System: Can not help you much here either

CPP to CPA negotiator: Yep that was my project.

I have written a thesis about "the ebXML Collaboration Protocol
Agreement Formation Process" and its currently edited and checked by my
supervisor before it will go to the examiner.

The CPA formation process has 2 sub processes:

1) CPA composition
2) CPA negotiation

The CPA composition takes 2 CPP's and starts to check them, basically
building pairs of elements and attributes and checking them. If the
check suceeds it goes into the CPA template (intermediary/temporary)
CPA. All mismatches or problems go into the gap list (I called it
conflict list). The CPA composition is currently described in Appendix E
of the CPPA specification V.2.0

The "Automated Negotiation of CPA" Specification, currently 0.10
enhances the CPA composition and introduces the CPA negotiation.
Basically allowing parties to negotiate over issues of a CPA template
and allow them to potentially get a final CPA.

I built a prototype for the CPA composition and a prototype of the CPA
negotiation. I must stress, that both are not complete but guide you
well. Both prototypes are implemented with Ruby (very nice OO scipting
language) and are licenced under the GNU Public Licence (GPL).

Actually the CPA negotiation is an ebXML application. Its core is a
collaborative negotiation business process, a negotiation CPA, the
negotiation messages and negotiation rules. For the prototype
implementation I did implement a incomplete ebXML business process
execution engine which more executes than monitors the negotiation
business process and guides the negotiation actors through the
negotiation. In my case the negotiation actors are humans, which can
negotate via a web interface. It would be very cool to investigate
further how intelligent software agents could be the negotiation actors.

Hope this gave you a first idea about my research activites.

You find most on www.schlegel.li/ebXML

I intend to publish a draft of my thesis for interested people.

Kind regards

Sacha

PS: Another tip before I send this email off is consider to become an
OASIS member and become active in the various ebXML Technical
Committees. For me personally, this was a good way to get even more into
ebXML.


Yes I did (not yet examined) a masters by research in computer science.
On Fri, 2004-06-18 at 16:21, Monica J. Martin wrote:
> >ah yes i am monica,
> >
> >i am building a suite of ebXML Services as my Masters degree.  you might
> >want to look at my website:  www.archmage.org.nz  atypically sparse in
> >content, as per usual for an academic, but it sets the point.  i am still
> >evaluating some tools, studying VC++, as a matter of fact i am chewing a
big
> >chunk of "managed C++ extensions", the .NET thing, as i have only used VB
in
> >the past.
> >
> >why do you ask?
> >
> mm1: We track ebXML adoption. You might wish to work with another
> masters student who is also doing an end-to-end ebXML implementation,
> Sacha Schlegel.  I've cc: him here. I am sure this will help us test out
> some of our assumptions on v2.0 changes. Thanks.
>
>
>
>
> !DSPAM:40d2fa7e69964420376918!
--
------------------------------------------------
Sacha                                   Schlegel
------------------------------------------------
public key:            www.schlegel.li/sacha.gpg
------------------------------------------------