OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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          /
>>/////////////////////////////////////
>>
>>
>>
>>
> 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]