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: [Fwd: Example Scenarios Used Within the Aerospace Industry]


Abid,

Please see below.

Cheers,

Chris

Abid Farooqui wrote:
> 
>   ----------------------------------------------------------------------------------------------------
> 
> Subject: Re: Example Scenarios Used Within the Aerospace Industry
> Date: Mon, 04 Jun 2001 14:16:14 -0400
> From: Abid Farooqui <farooqui@tampabay.rr.com>
> To: "Schuldt, Ron L" <ron.l.schuldt@lmco.com>
> References: <667ED598F8A2D311981D00508B12238006E348A6@emss02m04.ems.lmco.com>
> 
> Isn't it true that ebXML messaging can be used to deliver traditional EDI
> payloads as well. 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?

Correct, ebXML's use of MIME multipart/related packaging for
messages (using the SOAP Messages with Attachments binding)
allows for any type of data to be carried as payload for the
message, including traditional EDI payloads. A Message Service
that is bound to an EDI mapping engine would be a perfectly
valid use of the ebXML Messaging Service.

> 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. It opens
> these large corporations up to potential partners that with traditional EDI just
> were not able to come onboard because of the complexity and financing involved.

Correct! 

> Return on such an investment may be in the very near future if looked upon in
> this way.
> I do believe that any ebXML platform HAS to provide an easy way to run side by
> side with traditional EDI tools.

Obviously, the vendors of EDI mapping tools will need to provide
this binding to the ebXML Message Service.

> Sincerely,
> Abid Farooqui
> 
> "Schuldt, Ron L" wrote:
> 
> > Eric,
> >
> > I concur with your suggestions. I propose that we use something that is
> > "representative" of the current EDI based environment and then address the
> > relevant issues/solutions that will enable the smooth transition to the
> > ebXML specifications. Hopefully, the following assertions will reinforce
> > Eric's suggestions --
> >
> > In my opinion, very few large (Fortune 500/1000) companies can afford to
> > make sweeping changes from their current legacy EDI-based environments
> > without strong business cases. For the ebXML specifications to gain
> > momentum, the large companies must find a relatively painless (inexpensive)
> > or cost justifiable transition path for integrating ebXML to their
> > back-office systems. I also believe that the major global digital exchanges
> > (Exostar is an example for the Aerospace and Defense Industry) must take an
> > active role in adopting the specifications. If and when both of the above
> > conditions are true, then ebXML will be on a rapid path toward achieving its
> > intended goals.
> >
> > Without question, adopting the ebXML specifications will enable or require
> > business process modifications. In a generic sense, it would be helpful to
> > identify those business process changes that are required or possible when
> > transitioning to ebXML. The list of changes could form the basis for a
> > business case that could be used to convince management that the change is
> > justified.
> >
> > With regard to core components, the key is that once candidates they have
> > been identified, they need to be tested for all possible uses. An example
> > that jumps out at me is "address." For address to be a suitable core
> > component candidate, it must be able to handle all possible uses within B2B,
> > B2C, B2G, etc.). I would suggest that we take a subject such as "address"
> > and ask the list for candidate standard DTDs/Schema that might handle all
> > possible variations. If the list concurs with this suggestion, then I would
> > offer a candidate for "address" to get the ball rolling.
> >
> > Ron Schuldt
> > Lockheed Martin Enterprise Information Systems
> >
> >
> >
> > -----Original Message-----
> > From: Eric Chiu [mailto:echiu@imservice.com]
> > Sent: Saturday, June 02, 2001 7:28 PM
> > To: Schuldt, Ron L; ebxml-dev@lists.ebxml.org
> > Subject: Re: Example Scenarios Used Within the Aerospace Industry
> >
> > > Although the data details are EDI X12 oriented, the business process
> > > scenarios would apply to any data format standard. Therefore, I suggest
> > that
> > > members of this list at least look at the "business example" documents
> > > available from the following URL:  --
> > > http://www.aia-aerospace.org/edi/implcon.cfm
> > >
> > > For starters, I suggest looking at the purchase order business example
> > which
> > > is particularly useful. Portions of it could provide a model that this
> > list
> > > might find useful.
> >
> > Ron,
> >
> > Thanks for the suggestion on the AIA website for EDI transactions. May I
> > suggest that we look into following development issues:
> >
> > 1. Converting X12 implementation conventions into ebXML message service
> > payloads,
> > and related business process modifications
> >
> > 2. Requirements for converting existing EDI software, and possible
> > strategies:
> >     a. using X12 payloads over a ebXML messaging service structure only
> >     b. incorporating ebXML core components
> >     c. business process re-engineering
> >
> > Thanks,
> > Eric Chiu


[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