Re: Comments on OTA Requirements

[srh@us.ibm.com]

Thanks Mike,
More explanation SRH:

Scott R. Hinkelman
IBM Austin
Architecture and Development, Industry XML/Java Standards
Office: 512-823-8097 TL793-8097
Home: 512-930-5675
Cell: 512-940-0519
srh@us.ibm.com
Fax: 512-838-1074



Mike Rawlins <rawlins@metronet.com> on 01/18/2000 11:56:25 AM

Please respond to rawlins@metronet.com

To:   "List, ebXML Requirements" <ebXML-Requirements@lists.oasis-open.org>
cc:
Subject:  Comments on OTA Requirements




Here are my comments (marked MCR) on the Open Travel Alliance
requirements submitted by Tim Cochran.

Again, there still seems to be some confusion about the differences
between functional requirements, non-functional requirements,
deliverables, etc.  However, what you call it in your submission is not
as important as our getting it captured and expressed somewhere in the
final document.

Mike Rawlins

---------------------------------------------------------------------------------------------


Scott Hinkelman, IBM. OTA member.

The OTA (Open Travel Alliance) is pleased to provide this initial list
of Requirements
and Considerations for ebXML.

This document lists some initial requirements and considerations for the
ebXML effort,
in order for any future potential to be realized of the Travel Industry
(meaning OTA)
endorsing and utilizing the ebXML deliverables. Much of what is outlined
is based on
current experience with work under way to define Travel industry XML
standards.

This document is not an endorsement of ebXML from OTA. The OTA does not
sanction
this list as complete or official, but only as an initial snapshot in
the 1/2000 timeframe
of considerations for ebXML. OTA may revise this list at anytime.

NonFunctional

- The OTA needs to understand the process model from ebXML concerning
fixes,
updates, turn around time, etc before considering basing the Travel
content on any
ebXML dependency.

- The OTA needs to understand the custodian and maintenance ownership
model of the
ebXML standards before considering basing the Travel content on any
ebXML
dependency.

-The OTA needs to understand the licensing model for ebXML standards
before
considering basing the Travel content on any ebXML dependency.

MCR:  You have stated these as "OTA needs to understand..."   It would
be more helpful for our requirements if you could offer your needs
regarding these items.

SRH: These are really business requiremnts. The OTA is not is position
to quickly define detailed parameters for these due to the focus on
spec activity, but yes you are correct it would be helpful. The point is
that there must of course be a crisp outline of the business processes
concerning these at some point in order for any upper level domain/vertical
group to align and depend on ebXML. Maybe we can side step this in the
name of "what ever the OASIS process is/will be", but I think we should
say something someplace.

Functional

MCR:  These are all primarily non-functional.

- Security: The Travel industry requires a wide range of security
service quality and
function from an underlying message infrastructure. Some messages will
contain highly
sensitive personal information that will require several aspects of
security (authentication,
authorization, etc), while some messages need to flow 'in the clear',
with minimal
infrastructure, such as a 'flight availability' query which does not
need encryption,
sender-id, authentication credentials, etc.

MCR:  This expresses a requirement for allowing flexibility in
implementing levels of security.

- Security: The Travel industry requires both 'Session-based' and
'NonSession-based'
security models. Session-based generally refers to a model where the
Subject 'becomes
authenticated', and then 'sends authenticated' messages. A Session-based
model requires
the Subject (client) to hold some form of time-out token that represents
authentication
credentials. A NonSession-based model generally refers to a model where
each message
stands alone, including all information to become authenticated, and the
Subject is not
required to hold any security tokens between messages.

MCR:  Similar to Miller and Rudie comments regarding a requirement for
communications based security and static security.

- Transaction Boundary: The Travel could make use of the caller (client)
being able to
own and demarcate traditional transaction boundaries, either across
trading partner
("servers") or across a single trading partner ("server").  However, the
Travel industry
requires a model that facilitates a "verify and <action>" model that
does not require the
client to explicitly own any transaction demarcations. It would seem
logical that a
common infrastructure should supply this form of verb-model for use
across many
industries.

MCR:  I'm not sure that I understand this requirement.  Perhaps we need
to discuss this more in Orlando, or you could expound a bit more on this
on the listserv.

SRH: Sorry for any confusion. The point here is that the travel
industry contains business processes (not unlike other domains but
perhaps more common in travel, and in fact somewhat reflect the
programming models of current travel legacy systems) that due to
extreme transaction rates of perishable inventory and fluctuating
fare/prices, require either a predefined form of "action", or the
ability to inject an action, that facilitates a "verify" pre-action
before the real action. An example helps, as there are many ways to
say this.

1 You go to get a "fair quote" from an airline for a seat.
2 Now you think a while.
3 Now you purchase it.

Due to typically limited resources within the legacy systems, it is
typical that it is not feasable to hold state of any kind between
1 and 2, so, when you purchase you must "verify" (re-pass in)
the quote you where told as a result from 1 when you do 3,
because you only want
to purchase if it is still available AND the price has not changed (it
is possible that the seat is not available any more, etc).

Now, the point of all of this is simply to say that whatever we do
in ebXML Architecture this model can not be precluded
(not to say explicitly supported). This model is acoomodated
within OTA now.  Hope this helps.


- Grammar: The Travel industry requires consistency in noun<->verb,
verb<->noun
utilization across all grammar.

MCR:  A detailed requirement on the ebXML guidelines.

- Grammar: The Travel industry requires avoidance of the use of synonyms

such as "new" and "create" within the grammar.

MCR:  A detailed requirement on the ebXML guidelines.

- Underlying Standards: The Travel industry would recommend avoiding all
underlying
XML standards until ratified by appropriate bodies.

MCR:  A very good point which I think we have all talked about, but
haven't stated explicitly.  I see this as a basic requirement on the
ebXML guidelines that they depend only on standards or recommendations
approved by the appropriate bodies.

--
Michael C. Rawlins, Rawlins EDI Consulting
http://www.metronet.com/~rawlins/