MSH - MSI vs BSH - BSI replaced by MSH - MSI vs BPSSH - BPSSI

[Sacha Schlegel <sschlegel@cyclonecommerce.com>]

Hi ebBP team

What is a BSI seems to be a good question.

I made one bad choice (name of BSH):

I guess it is clear what an MSH is. As Steve pointed out it is the one
components which "does the job" of messaging. The MSI is supposed to be
the interface of the MSH. But the ebMS spec does "acknowledge" the
interface it but does not define it.

One thought I have is to have "just" another component for the ebBP
BPSS. The reason for this approach probably comes from my experience of
partly implementing some sort of an ebXML BPSS engine. As I had no time
to do a MSH I picked up the idea of the MSI. My ebXML BPSS engine could
just use a MSH through its MSI interface. Well thats what an interface
is for. And on top, my ebXML BPSS engine could use "any" MSH if it
implements an specified MSI: the open source one, the high performance
one, the clustered one, the cheap one, any one as long as I program
against the interface. In fact I did not program against an interface
because there is none so I have done something non-coform all together.

Steve expressed what I was all about, to have a ebBP BPSS component.
Analog to ebMS I called that component BSH aka Business Service Handler.
That was a wrong choice because an interface to that component must be
called BSI aka Business Service Interface. And as everyone knows BSI has
a complete different meaning.

So sorry about that.

First question would be: Is it wise to have an ebBP component on its
own?

To be honest I like this idea, as you might have found out. As Patrik, I
think it would be cool to combine any MSH's with any ebBP component.

If som we need a name for an ebBP BPPS component. In this email I will
call it BPSSH. So if the component approach is a valid approach, again
this component will also need an interface. I call it BPSSI.

The BPSSH, would be responsible to take care of BPSS signals. With a
BPSSI and MSI we would have the messaging of ebXML messages and BPSS
signals done. Such a BPSSH can take care of timers. What such a BPSSH
cannot do is decide when to send a positive AcceptanceAcknowledgment or
a negative AcceptanceAcknowledgement [1]. In my view it does not make
any sense at all if such a BPSSH just sends a positive
AcceptanceAcknowledgment because, state alginment, is based on correct
AcceptanceAcknowledgment signals [2].

Well there we have another interface, in my view. Some component (BSI
maybe), some unknown component has to know that it must generate an
positive or negative Acceptance Acknoledgment. That unknown component,
in a multi component architecture, must provide that information to the
BPSSH through the BPSSI interface.

I know that a BPSS cannot be executed per se as it captures the complete
business collaboration. I think at least each party involved can execute
its part of it.

JJ was mentioning that he envisions to convert a BPSS to something else,
well what would that something else be? Part of a private business
process? Somehow I think of this scenario as an inside-out (from inside
the organization to the outside) scenario. That scenario would still
need an interface to the MSH. The one commercial MSH I know has a
proprietary interface, maybe no big deal ... I would prefer to have a
openly specified interface.

Regards

Sacha

PS: ebBP BPSS I mean the XML file which conforms to the ebBP BPSS XML
Scheme.

[1] How to determine if an AcceptanceAcknowledgment is postive or
negative or when to send it is another good question. If for example an
incoming request message goes through 5 sequenced service (eg service 1
first, followed by service 2, followed by service 3, etc). When to send
a postive AcceptanceAcknowledgment? When it passed through service 1? or
after it passed through service 2? :)
[2] A JJ statement.