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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

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


Subject: Re: [ebxml-dev] signed acknowledgement - BSI's role?


The BSI is built of two components - the Business Interface and the
Service (Technical) Interface.  Since the Technical Interface includes
details of endpoint, protocol, etc, which CAN be the ebXML MS, it could
be argued that the BSI sends the Transport level acknowledgements.

These are different than the Business logic level acknowledgements.  Let
me explain:

The Transport level acknowledgements basically says "I received your
message, but have not yet read it or agreed to anything you propose". 
The Business level acknowledgement says "I received your [name of
specific document] and acknowledge receipt and possibly agree to it
[depending on the BP you are engaging in]".

Cheers

Duane

"Himagiri(Hima) Mukkamala" wrote:
> 
> No, Acks at MSH and BSI level are different.
> Acknowledgments sent at MSH level do not have to deal
> with any payload validity check. This is a SOAP Header extension
> and not derived from RosettaNet. Please refer to section 6.3.2
> in the ebXML MSH 2.0 specification.
> 
> http//www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v2_0.doc
> 
> FYI, Acks for BSI (BPSS 2.0) are not derived from RosettaNet.
> 
> -hima
> 
> Nandini Ektare wrote:
> 
> > Correct me if I am wrong. Isn't the Receipt Acknowledgement at MSH
> > level and BSI level same?
> >
> > Both are derived from same Standard Rosettanet dtd and both say
> > "this ack is sent if the message received is legible(i.e the
> > *message* has passed a structure/ schema validity check)"
> >
> > -Nandini.
> >
> > "Himagiri(Hima) Mukkamala" wrote:
> >
> >> No. BSI doesn't play a role in sending/receiving acks at MSH
> >> level.
> >>
> >> There are different acknowledgments that are to be dealt at the
> >> BSI layer
> >> implied by some attributes in BPSS instance document. These
> >> include
> >> the "ReceiptAcknowledgment" and the "AcceptanceAcknowledgment".
> >>
> >> So in that sense as MSH has control over the MSH Acks, it has to
> >> have
> >> control over the keys to sign the acknowledgments.
> >>
> >> -hima
> >>
> >> Nandini Ektare wrote:
> >>
> >> >
> >> > As this question has been raised, I want to add to the question.
> >> >
> >> > I agree sending receipt acknowledgement is the responsibility of
> >> > MSH but is it also true that creation of the ack automatically is
> >> > MSH's responsibility. >From what Patrick has asked I get a
> >> > picture that Acknowledgements are 'traded' just between the MSH
> >> > at both ends.
> >> >
> >> > As a layer above MSH in the ebXML stack, a BSI may want to alter
> >> > the ack before sending (say) to state the reason for negative
> >> > ack. (the <FreeFormText> element in the standard
> >> > ReceiptAcknowledgement dtd could be used). Similarly  the BSI
> >> > wants to receive the ack in order to (say) send a separate
> >> > "Notification of failure" in case of a -ve  ack which is treated
> >> > as a business protocol exception by the BSI.
> >> >
> >> > All in all, doesn't the BSI play a role in sending/receiving
> >> > Acknowledgements - whether Receipt or Acceptance?
> >> >
> >> > And if BSI does play a role, the key/passwd per appln need not
> >> > necessarily be stored in MSH keystore.
> >> >
> >> > thanks,
> >> > Nandini
> >> >
> >> >
> >> > Patrick Yee wrote:
> >> >
> >> >>  Dear all, I have a question about messaging service. According
> >> >>  to the specification, the sender of a message can request an
> >> >>  acknowledgement from the receiver, and optionally, the sender
> >> >>  can request that acknowledgement to be signed. Since the
> >> >>  acknowledgement sending is done automatically by the MSH, does
> >> >>  that imply the MSH should keep the application's private key
> >> >>  and password to the keystore for signing automatically? Will
> >> >>  that cause any vulnerability problem?Thanks in
> >> >>  advance.Regards,-Patrick--
> >> >>  Patrick Yee
> >> >>  System Architect
> >> >>  Center for E-Commerce Infrastructure Development (CECID)
> >> >>  Dept. of Computer Science and Information Systems
> >> >>  The University of Hong Kong
> >> >>  Tel: (852) 22415674
> >> >>  Fax: (852) 25474611
> >> >

-- 
CTO, XML Global Technologies
****************************
Transformation - http://www.xmlglobal.com/prod/foundation/
ebXML Central - http://www.xmlglobal.com/prod/central/


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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC