RE: Requirements and defintions documents

[David Burdett <david.burdett@commerceone.com>]

Hi Henry !!

See comments below.

David
PS Apologies for the delay but I've been down with the flu since Wednesday.
I am now, Monday, just about recovered.


-----Original Message-----
From: Henry Lowe [mailto:hlowe@omg.org]
Sent: Thursday, January 13, 2000 7:30 AM
To: ebXML Transport (E-mail)
Subject: Re: Requirements and defintions documents


Hi all,

Here are my comments on the set of requirements sent out 
Tuesday.  I will try to comment on the definitions document 
later today.  Due to being at an OMG meeting, I haven't been 
able to put as much time into them as I'd like.  Also, I 
am trying to get one or perhaps more of the OMG members 
to participate in ebXML, though it probably won't happen 
for this coming meeting due short time scale.

A few general comments first:

1. I think it would be useful if our requirements were 
   separated into packaging and transport sections.  
##Why? It really depends on what you mean by "packaging" and "transport"?##
I'm 
   not saying anything is out of scope, but it would 
   make it easier to see who is supposed to be doing 
   what; 
##I don't know what you mean by "who is supposed to be doing what"##

2. Some of the requirements that are not so designated 
   are really optional -- we should probably go thru and 
   agree which are mandatory and which optional; and 
##I think agreeing optional vs mandatory requirements will be very time
consuming. Also what is mandatory will vary depending on the particular
scenario in which the approach will be used. A better way, perhaps is to
consider the requirements more as a list of features that may be provided
and then, during the meeting identify, which approach seems to offer the
best way forward.## 

3. I have the feeling that not all of the requirements 
   are at the same level for transport -- some seem to 
   be fairly low level whereas others are high level. 
   Unfortunately, I don't have time to figure out how 
   to categorize the requirements (if that's what we 
   need) and put each in its proper place.  This will 
   be particularly usedful in evaluating technologies 
   for transport services and packaging services (assuming 
   they are not necessarily the same).
##I agree they are at different levels. However I don't think this really
matters since the evaluation we have in mind I think will be more subjective
rather than based on a weighted scoring approach.##

Specific comments (sequential): 

1.4 Some of the examples given are more than just a protocol, 
   in particular, CORBA and MQSeries includes service APIs
   (I'm not familiar enough with JMQ, JMS and MSMQ to say;
   I believe HTTP and SMTP are just protocols -- at least 
   they were originally).  
##Agreed - but I still think they are worth looking at.##
Also, not all of these are open;
   should we be focusing on open services and protocols?
##That is for us, as a group, to decide. My inclination is that we should
focus on open approaches. I think you feel the same. What does everyone else
think?##

1.5 I would suggest we mind use "unambiguous" instead of 
   "unique" as it's probably all that's required and is easier 
   to do.
##I'm inclined to disagree since, in a global ecommerce scenario - which is
the focus of ebXML. It will be necessary for documents to be "uniquely"
identified rather than "unambiguous". Also, according to the MS word
thesaurus, unambiguous can mean "unmistakable, clear-cut, explicit,
definite, decided, unquivacol, instantly recognizable or clear" wheras
unique is defined as "sole, single, exclusive, inimitible, distinctive,
matchless, ...". Of course it is impossible to *prove* that an identifier is
unique, but that doesn't mean that you should not assign a value that is
intended to be. Also, using the idea of namespaces associated with URNs it
is actually quite easy to assign unique values to ids.##

1.7 thru 1.10 These requirements are services that are normally 
   provided by a queuing service.  However, the requirement here 
   is being put on the envelope which is, I believe, a packaging 
   concern.  Is this necessary as a packing requirement?  It 
   definitely is for a queue based transport which we want -- see 
   long term transactions in requirements.
##Disagree. I think that these requirements are information that needs to be
communicated from one party to another with every message and therefore
should be part of the envelope. I do agree though that the information that
is communicated is likely to be **used** by a communication service.##

2.2.e We probably shouldn't use the term "abnormal errors" (all 
   errors are abnormal behavior) and what does "fell over" mean?
##I don't think that *all* errors indicate abnormal behavior. For example if
you are processing a purchase order then some (or all) of the items may be
out of stock. This will generate an "out-of-stock" error or business
failure. This error is, however quite "normal" since no business will always
be in stock for all its product lines all the time. On the other hand, if
the purchase order that was being processed caused the
purchase-order-processing-system to "crash" then that is an "abnormal error"
since you don't normally expect systems to crash. Perhaps "fell-over" is a
UK english expression for a system crash - I'll change the words.##

2.4 and 2.5 I believe would be better placed in clause 4 which deals 
   with security and signatures in particular.
##You're absolutely right - they've been moved.##

6.0 In the text before 6.1, is this saying that the following are 
   requirements for dynamic (vs static, i.e., designated or selected 
   before the transaction is begun) QoS?  If so, do we have any 
   static QoS requirements?  [Selecting QoS staticall is probably 
   more efficient opertionally than dynamic.]
##I think that potentially they could be selected dynmamically or statically
depending on the requirement - I'll clarify the text.##

6.1.a and 6.1.b  Aren't these definitions?
##Yes - I've moved them to the defintions document.##

6.2 is part definition part requirment -- should we separate them?
##Yes - I've moved the definition to the definition document.##

6.2.e  The requirement doesn't seem to be complete -- an instance 
   of what?  I'd guess this is a typo.
##I really meant *the* instance - anyway clarified the definition.##

7.1 How are "black boxes" relevant to interoperability?
##In my last email I responded on this point to you as follows ...

>>Surely you should be able to send a document (e.g. an XML document wrapped
in MIME over HTTP) to someone else without *having* to know anything about
the internal architecture of the "box" that will receive it (see my last
email for more on this). If you accept this premise then it means as it is
says ... "Servers/systems that support the transport of documents can be
treated as black boxes"?<<

Does this make sense?

I think that you need to be able to treat the destination for a message as a
"black box" - i.e. you only need to know *what* the box does rather than
*how* it works. If you *need* to know *how* a destination will handle a
message before you send it then it implies:
1) Some attributes of message need to change depending on how it needs to be
processed,
2) Changes to the internal operation of the process need to be tracked in
case it has impact on the attributes of the message, and therefore
3) You can't get interoperability

As a very simple analogy - many hand-held calculators have a "square-root"
key. Anyone can use it to calculate a square root but you don't need to know
how it was calculated.##

7.2 I would suggest we add an item (c) as follows:
   c) the language used for implementation of systems and applications.
##Good idea.##

8.1 I would suggest we specify when the service becomes unavailable, 
   i.e., before the start of the transaction or after the start of the 
   transaction, as this probably makes a lot of difference in the 
   capability we are requiring of the system.  Of course, it could be 
   that we require both -- if this is the case, I would suggest we 
   state this explicitly.
##I really meant both.##


Best regards,
Henry
---------------------------------------------
At 04:53 PM 01/11/2000 -0800, David Burdett wrote:
>I attach updated versions of the requirements and defintions documents. You
>will find quite a few changes since I received quite a lot of feedback.
Some
>of the suggestions came in emails sent privately to me so not everyone will
>be able to trace the original unless those individuals to whom I've posted
a
>reply want to forward my reply to the list.
>
>There are three pdf files:
>*      Version 5 of the requirements (with changes highlighted)
> <<ebXML Transport Requirements 5.pdf>> 
>*      the same as the previous item but with no changes highlighted - this
>is much easier to read
> <<ebXML Transport Requirements 5 without changes highlighted.pdf>> 
>*      and the ebXML Transport definitions document that is unchanged but
>I'm including in case someone new to the list hasn't seen it yet.
> <<ebXML Transport Definitions 1.pdf>> 
>
>We really need to tie these down and, after discussion with Rik, he's
>suggesting that we finally freeze the requirements document by 5PM PST this
>Thursday.
>
>David
>
>Advanced Technology, CommerceOne
>1600 Riviera Ave, Suite 200, Walnut Creek, CA 94596, USA
>Tel: +1 (925) 941 4422 or +1 (650) 623 2888; 
>mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
>
>
>
>