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


Anders W. Tell wrote:

> 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). 
>
> Tell: 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. 

mm1: Anders, these questions could apply to any new and emerging 
technology today.  Embedding business rules and non-extensible code 
logic may be fine for SME in the short-term but does not help them 
remain agile or provide a competitive value add edge. To Kenji's point 
as well, there is much value in the
BP definition. If we are not seizing the value you reference, what 
specifically is missing that we have not addressed in v2.0 or is planned 
for v3.0? Thanks.



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