Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]

[Abid Farooqui <farooqui@tampabay.rr.com>]

Dear James,
So let me understand this correctly.
As far as I can make out from your kind answers below what seems to be the case is
that :
1) ebXML can be used as a messaging mechanism to deliver traditional EDI to
traditional EDI engines
2) Now you mention 2 problems:
"First, it must correctly interpret the element that identifies the schema
(such as X12) in which the payload documents are encoded, so it can send
that data stream to something that can interpret it.  (Like your EDI engine.)"
My question to that is : Doesn't ebXML messaging has in it some indicator that
describes what kind of data it is and if not ... why?

"Second, it must correctly apply the ebXML business signals so that it can
read and process the simple business-rule context of that payload -- Is
this a response?  A request?  To what?  Is it logically dependent on or
conditioned on another message already received, or to come?  Is this
binding?  Does it conform to whatever rules for acknowledgement, encryption
or signature are invoked?"
Isn't this what an ebXML server would do anyway? I think these are basically
requirements for an ebXML platform, regardless of EDI payload or any other payload.
Am I correct?

Thanks
Sincerely,
Abid Farooqui



James Bryce Clark wrote:

> At 11:17 AM 6/4/01, you wrote:
>
> >Date: Mon, 04 Jun 2001 14:16:14 -0400
> >From: Abid Farooqui <farooqui@tampabay.rr.com>
> >Subject: Re: Example Scenarios Used Within the Aerospace Industry
> >
> >Isn't it true that ebXML messaging can be used to deliver traditional EDI
> >payloads as well.
>
> Yes indeed.
>
> >Probably there has to be ways of delivering that payload to
> >the EDI mapping engine like DI or GenTran but ebXML messaging could be used as
> >the transport correct?
>
> Once past transport, the receiver's business service interface has, broadly
> speaking, two problems.
>
> First, it must correctly interpret the element that identifies the schema
> (such as X12) in which the payload documents are encoded, so it can send
> that data stream to something that can interpret it.  (Like your EDI engine.)
>
> Second, it must correctly apply the ebXML business signals so that it can
> read and process the simple business-rule context of that payload -- Is
> this a response?  A request?  To what?  Is it logically dependent on or
> conditioned on another message already received, or to come?  Is this
> binding?  Does it conform to whatever rules for acknowledgement, encryption
> or signature are invoked?
>
> >I am new to ebXML so feel free to correct me.
> >I believe that changes from large EDI users to adapt ebXML will be slow
> >but they
> >have to be made because there is a very good business case to do that.
>
> The ebXML business process group spent a lot of time working closely with
> the X12, EDIFACT and RosettaNet communities precisely to preserve the
> upgrade path you describe.
>
> Best regards
>
> James Bryce Clark
> McLure Moynihan Inc.
> 818 597 9475     jamie.clark@mmiec.com