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

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

Thanks for the answers Chris. I am not directly into the EDI world much, I
am a Java developer but I do work with a lot of people using EDI tools like
DI for doing Maps and so on.
One problem that nagged me about EDIFACT was that even though it is a
standard what was quite annoying and what made it much more complex than it
ever needed to be is the fact that each of the vertical markets can
basically come up with their own version of an 855 and so on. So many fields
are optional making it even more complex. I am not sure, may be it is my
strict upbringing or something (hope my mom never reads this:)) but giving
so much leeway really gets away from the point of being a standard. With
such complexity you give rise to complex programming tasks making EDI or
ebXML platforms rise way higher in price than they otherwise would be and
make so many people so specialized in one area that their whole career is
based on it. For instance there are EDI people who are just experts in the
Airline industry and so on.
If the standard was more like a standard (more stringent) then there could
be say just one and only one version of a PO and it would be easy to parse
it, reducing cost and complexity a hundread fold. It seems like ebXML has
not achieved that state yet either. May be we are just making jobs and
careers for ourselves in the industry and not really solving business
problems. In my opinion there is no reason that if enough thought is put
into a standard that anything should be left up to the vertical markets to
decide.
Sincerely,
Abid Farooqui


----- Original Message -----
From: "christopher ferris" <chris.ferris@east.sun.com>
To: "Abid Farooqui" <farooqui@tampabay.rr.com>
Cc: <ebxml-dev@lists.ebxml.org>
Sent: Monday, June 04, 2001 4:46 PM
Subject: Re: [Fwd: Example Scenarios Used Within the Aerospace Industry]


> Abid,
>
> Please see below.
>
> Cheers,
>
> Chris
>
> Abid Farooqui wrote:
> >
> > 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
>
> Yes, it can.
>
> > 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?
>
> Yes, it does. This is the purpose of the Manifest. Of course, there are
other
> elements of the ebXML SOAP extension headers that the message service can
> use for purposes of internal dispatching of messages to the appropriate
handler
> application. These include the CPAId, Service and Action elements. The
CPAId
> can be used to identify a CPA (whether a true CPA document or an implied
or
> logical "agreement" between the parties that specifies what messages will
> be exchanged, etc.). The Service and Action elements can be used for
internal
> dispatching as well. Again, ebXML MSH places no specific constraints on
> how these elements are (or are not) used in any given implementation.
>
> >
> > "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?"
>
> The business signals referred to here are those that are defined in terms
> of an ebXML business process. The business signals are low-level messages
> that parties exchange to signify things such as:
> - I've received your message
> - I've pre-processed your message and it passed the preliminary
> edits
> - ...
>
> The ebXML Business Process Specification Schema specification describes
these
> in more detail. Business signals may, or may not be necessary. This is
clearly
> the realm of the "owner" of a business process to determine. Typically,
this
> would be the purview of a vertical standards body such as OTA, RosettaNet,
OAG, etc
> or a horizontal standards body such as X12 or EDIFACT, etc.
>
> > 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?
>
> Basically, yes.
>
> >
> > 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