Re: [ebxml-bp] Episodical memory requirement

["David RR Webber" <david@drrw.info>]

Kenji,

Good point!  ; -)

The real answer I believe is somewhere we tried to get to
with the original ebXML work - and is now enshrined
in the Registry SCM - Use Case #2 requirement.

 http://www.oasis-open.org/committees/download.php/5579/ebDictionary.html

If we implement this - I believe we will finally be able
to raise the flag to the mast and sail in this ship.

The keel is laid and I see much of the superstructure, and the masts.
Final fitting an kitting-out is in-progress!

Cheers, DW.

----- Original Message ----- 
From: "Kenji Nagahashi" <nagahashi@fla.fujitsu.com>
Cc: "ebxml bp tc" <ebxml-bp@lists.oasis-open.org>
Sent: Monday, July 19, 2004 10:50 AM
Subject: Re: [ebxml-bp] Episodical memory requirement


> Hi,
>
> Did SME successfully implemented EDI? There would be much BPSS could do.
>
> There are relationships that cannot be easily tracked by just reference
> # in the envelope.
> When you look into the business message, you will find many identifiers
> which references other business document, or I'd call it, process
> instance. I believe they are business level relationships and important
> part of BP description.
> Also relationship between order and invoice is not usually specified by
> reference # in the envelope. It is in the message.
>
> Just think of purchase order management process consisting of create,
> change, update notify, cancel. It is non-trivial to implement management
> process using reference # in the envelope. Do you expect SME to
> implement that in full, or BPSS to help automate the implementation?
> Conversation-Id in ebMS header also won't work much, because it is only
> valid between two parties. If we try to extend business process
> description into multi-party collaboration, we certainly need a way to
> describe what is the key to identify multi-party collaboration instance.
>
> Kenji
>
> David RR Webber wrote:
> > Anders,
> >
> > I find all these questions somewhat strange.  EDI a millenium ago
already
> > solved these.  On the ebMS front - as with EDI - there is a reference #
> > in the envelope that tells you what thread the transactions belong to.
> > End of story IMHO.
> >
> > And yes - when you buy a ebMS package as an SME you expect all
> > this stuff to just work - that is the job of the vendor / implementer.
> >
> > We have to be careful to not cross over and write product
> > implementation specifications for vendors.  That is not our job.
> >
> > I think ebXML dev is a better place to discuss implementation
> > details with vendors and developers and ask them how they
> > are solving such matters for their customers.
> >
> > Thanks, DW
> >
> > ----- Original Message ----- 
> > From: "Anders W. Tell" <anderst@toolsmiths.se>
> > To: "ebxml bp tc" <ebxml-bp@lists.oasis-open.org>
> > Sent: Monday, July 19, 2004 5:45 AM
> > Subject: Re: [ebxml-bp] Episodical memory requirement
> >
> >
> >
> >>HI Sacha,
> >>
> >>Sacha Schlegel wrote:
> >>
> >>
> >>>It should be obvious, that in a ebBP if you send a purchase order
> >>>confirmation, that is based on the purchase order which happens in the
> >>>same ebBP. I think ebXML messages (assuming that the ebXML messages
have
> >>>the same name as the payload documents) include references to the
> >>>previous message ... so you should be able to trace the purchase order
> >>>back from a purchase order confirmation (by the persistent/archiving
> >>>ebXML BSI, ebXML Messaging Service Handler).
> >>>
> >>>
> >>
> >>The questions that concerns me are....
> >>What is the value of buying, from SME point of view, a very expensive
> >>ebBP compliant system when it can't do more for you,  What is the value
> >>from a business automation POV when you can't relate documents exchanges
> >>to each other?
> >>Whats the value of a ebBP system if you still have to code neccessary
> >>and obvious business rules yourself and when at the same time its simple
> >>to do all the coding by hand?
> >>What is the time to market and lifetime cost for a small SME software
> >>provider supporting traditional and relativly simple message exchange
> >>scenarions? Should they buy a ebBP system+code neccessary business rules
> >>OR implement, test, support a ebBP system+code neccessary business rules
> >>OR implement the scenarios directly ? Most likelly the third option is
> >>costeffective for a great number of software or business system
> >>providers with requirement to support few scenarions.
> >>
> >>thanks
> >>/anders
> >>
> >>-- 
> >>/////////////////////////////////////
> >>/ Business Collaboration Toolsmiths /
> >>/ website: <www.toolsmiths.se>      /
> >>/ email: <anderst@toolsmiths.se>    /
> >>/ phone:  +46 8 562 262 30          /
> >>/ mobile: +46 70 546 66 03          /
> >>/////////////////////////////////////
> >>
> >>
> >>
> >>
> >
> >
>
>