OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-coord message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: TA document report


I gather in part one, "General", a summery of the comments I got until
now, and part two are the  comments in details

Nagwa
--------------------------------------------------
Part one

General:
--------
-There are good hard work done and the document is moving in the
 direction  of an Architecture document but it is still not completely
at it.

-it is still difficult to understand which are the logical steps for a
SME  to
 establish an ebXML solution.

-There are assumption that a first implementation of ebXML will feature
 complete automation.

- ebxml Conceptual overview is depending completely on the TPA which is
not on
the Requirement Document

- the current draft contains pieces that don't seem to have anything
  to do with architecture.
        - Expresses a point of view about the role of object-oriented
          methodology
        - The open-edi sec. this is nothing but an advertising for a
          standard we have not,  formally adopted.
        - discussion of "Objects" should be dropped from the TA doc

- The assumption that the things exchanged in business transactions will

  contain methods. There is no description of basic ebXML functionality
  that would require this.

- lots of mention of UML, implies UML is required, The UML diagrams are
  a useful heuristic, but they are not sufficient in themselves to
  completely define business semantics

- the relationship between the TPA, the BSI and the MS is not clear

- needs more examples

-------------------------------------------------------------------
Part 2:

== Section 6 =====================================================

Section 6 starts out fine:

(para 1)
      Over 25 years ago the idea was born to eliminate the use of
      paper documents for exchanging business data by linking
      computer systems together so that the data, normally on
      paper, could be sent from one system to the other. This
      concept became known as EDI, Electronic Data
      Interchange. The advantages are still valid today: single
      point of information capture, electronic delivery, low
      storage and retrieval costs, to mention just a few. However,
      looking at the statistics of who is currently utilizing EDI
      only the top 10,000 companies on a global scale (Fortune
      1000 in the top 10 countries) are using EDI. For the rest of
      the business world only 5% are using EDI and therefore today
      common business processes are dominated by paper
      transactions.

(para 2)
      Today, Extensible Markup Language (XML) is at the forefront
      of efforts to replace paper-based business transactions.  In
      order for Small to Medium Enterprises (SMEs) to benefit from
      the next generation of electronic business standards, these
      standards must contain all the information to allow software
      developers to create programs that can be purchased
      off-the-self (shrink-wrapped-solutions) or developed
      in-house. The success of any new way to exchange data among
      businesses depends not only on the adoption by the Fortune
      1000 companies of standard agreements, but on their adoption
      by the other estimated 25,000,000 SMEs in the world. Without
      an economic incentive for the SMEs, any new method of
      accomplishing electronic business is just re-inventing the
      status quo instead of delivering a pervasive solution.

This is all good intro stuff.  But then it veers off into
methodology:

(para 3)
      The answer is to document and capture in an unambiguous way
      the business processes and associated information
      requirements for a particular business goal, which can then
      be processed by a computer program.  The use of XML
      technologies combined with business process and information
      modeling and object oriented technology can achieve this
      objective.  Instead of looking at the data requirements
      based on internal legacy database records, business experts
      identify the collaborations with other parties in order to
      achieve a certain business goal. Those collaborations are
      documented in a model developed in the Unified Modeling
      Language (UML).  Each activity requires the exchange of
      business information. Instead of taking the data element
      (EDI) approach, objects are used to describe and model
      business processes.

This paragraph is tendentious and expresses a point of view about
the role of object-oriented methodology that does has not achieved
consensus within ebXML.  It is not necessary to understanding the
ebXML architecture and should be omitted.

The fourth paragraph has problems, too:

(par 4)
      With the advent of XML, it is easier to identify and define
      objects with attributes (data) along with functions that can
      be performed on those attributes.  There are many objects
      that are common to many business processes (goals), such as
      address, party, and location..  By allowing these objects to
      be reused, ebXML can provide the means to unify
      cross-industry exchanges with a single consistent lexicon.
      However the role of ebXML is not to replicate the reliance
      on electronic versions of common paper documents such as
      purchase orders, invoices and tender requests and to offer
      up and develop such implementation examples.  Instead the
      ebXML specifications enable SMEs themselves to create
      consistent, robust, interoperable, and open business
      component libraries which will enable global electronic
      commerce.

The first part of this paragraph says that the things being
exchanged in XML-based transactions consist of more than data.  I
disagree with this view, and I doubt very much that it represents
a consensus.

Furthermore, the last sentence of the paragraph above paints a
picture of life as it's lived by small businesses that I frankly
find unbelievable.  What I would want as a small business owner is
something that works most of the time using off-the-shelf software
that I do *not* assemble from pieces and that can be fixed when it
doesn't work by editing an XML document in a text editor, not by
poking around in code.  It's fortunate that this language is
completely unnecessary and can therefore be deleted.

== Section 7 ====================================================

Section 7 seems perfectly reasonable:

      7.0 ebXML Abstract Overview

(para 1)
      Although XML is a recent newcomer in the electronic commerce
      landscape, supply chains in many industries, as well as
      industry consortiums and standards organizations are using
      XML to define their own vocabularies for business
      relationships and transactions.  The vocabularies, business
      templates, and business processes used by these groups to
      transact business must be accessible by all partners at any
      time.

(para 2)
      Furthermore, newcomers to the supply chain or business
      partnerships must be able to discover and implement
      electronic business interfaces to interoperate in a secure,
      reliable and consistent manner.  In order to facilitate
      these needs, mechanisms must be in place that can provide
      information about each participant (Trading Partner),
      including what they support for business processes and their
      implemented service interfaces.  this includes information
      about what business information is required for each
      instance of a business message, and a mechanism to allow
      dynamic discovery of the semantic meaning of that business
      information.  The entire mechanism must be able to recognize
      semantic meanings at the business element level and be
      implemented using XML based representations and systems. The
      complete set of ebXML specifications explain this
      functionality in detail.

I think that section 7 would stand perfectly well on its own as an
short introduction.  The unobjectionable historical part of
section 6 is interesting but not necessary.  Section 6 should
either be rewritten to remove the debatable paragraphs, or it
should be dropped entirely.

== Section 8 ====================================================

figure 1, too complex.

== Section 9 ====================================================

Sect 9 Relating the ebXML Architecture to Existing Standards
(really about Open-EDI) should be removed completely.

This is an ebXML doc, not an EDI doc.
ebXML is being developed for those SMEs for which EDI is not
appropriate.

Figure 2 in Section 9 can be moved to Section 10 ebXML Architecture
after
removing the EDI in the title.

== Section 10 ===================================================

OK.

== Section 11 ===================================================

In Section 11 we run into disagreeable assumptions about OO
methodology again starting right at the beginning:

(para 1)
      ebXML Business and Information Models are created following
      the selected ebXML business process and information modeling
      methodology (see section 17).

At best this is irrelevant to the architecture.

The next paragraph says:

(para 2)
      Business knowledge is captured in a Lexicon. The Lexicon
      contains data and process definitions including
      relationships and cross-references as expressed in business
      terminology and organized by industry domain.  The Lexicon
      is the bridge between the specific business or industry
      language and the knowledge expressed by the models in a more
      generalized industry neutral language.

I don't think that something called a lexicon should contain
process definitions.  In fact, I don't agree that the things
exchanged in business transactions should contain methods.  I
can't find anything in the description of basic ebXML
functionality that would require this.  What I would agree with is
something like this:

      Business knowledge is captured in a Lexicon. The Lexicon
      contains data definitions and descriptions of relationships
      and cross-references as expressed in business terminology
      and organized by industry domain.

The larger point here is where we draw the line between stuff that
falls out of the modeling and stuff that can be (and in my opinion
therefore should be) handcrafted.  If what is meant by "process
definition" means something that will execute or that can
automatically generate something that can execute, then I believe
we are in the realm of code, and I think that code modules should
be developed with more regard for the peculiarities of what works
in good XML schemas than can be achieved automatically from the
top down.

The next paragraph says:

(para 3)
      The first phase defines the requirements artifacts which
      describe the problem using Use Case Diagrams and
      Descriptions. If Lexicon entries are available they will be
      utilized, otherwise new Lexicon entries will be created.

I do not see how the basic ebXML scenario requires Use Case
Diagrams and Descriptions to be part of a lexicon.

Continuing in section 11, we read:

(para 4)
      The second phase (analysis) will create activity and
      sequence diagrams describing the business processes. Class
      diagrams will capture the associated information parcels
      (business messages). The analysis phase reflects the
      business knowledge contained in the Lexicon. No effort is
      made to force the application of object-oriented
      principles. The class diagram is a free structured data
      diagram (e.g. a UML diagram).

This seems to me to be completely irrelevant to the architecture.

(para 5)
      The design phase is the last step of standardization, which
      may be accomplished by applying object-oriented principles.

Or it may be accomplished by consulting sheep entrails.  Either
this passage adds nothing, or what it adds is not something that
we all agree with.

It isn't until I hit paragraph 6 that I find a paragraph in section
11 that actually contributes something uncontroversial to the
description of the ebXML architecture:

(para 6)
      Therefore in ebXML interoperability is achieved by applying
      business objects across all class models. The content of the
      business object library is created by analyzing existing
      business objects as used by many industries today in
      conjunction with the Lexicon content and ebXML selected
      modeling methodology.

Leave off the first word, define "business object" as suggested
above, and this becomes a good paragraph with which to begin the
section.  I think that everything else that precedes this in
section 11 is irrelevant to the architecture and should be
omitted.

== Section 12 ====================================================

The box labeled "UML to XML" conversion should be omitted.  I do not
believe that we will in general be getting standard XML schemas
through mechanical conversion of UML.  I believe that schemas
generated directly from UML will tend to be be ugly, suboptimal, and
unintuitive for the small business user.  Users deserve the products
of human skill.

One small clarification along the path.  I would rewrite the last
sentence of this paragraph:

(para 6)
      Additionally, all participating components in ebXML must
      facilitate multilingual support.  Again, a UID reference is
      particularly important here as it provides a language
      neutral reference mechanism.  To enable multilingual
      support, the ebXML specification must be compliant with
      Unicode and ISO/IEC 10646 for character set and UTF-8 or
      UTF-16 for character encoding.

To read as follows:

      To enable multilingual support, applications compliant with
      the ebXML specification must support Unicode and ISO/IEC
      10646 for the character set and UTF-8 or UTF-16 for
      character encoding.

== Section 13 ====================================================

In Section 13, we find once again the assumption that a first
implementation of ebXML will feature complete automation.  In
fact, the process specified in Section 12 nowhere requires this.
So the bottom four function calls in Figure 6 are misleading:

      RequestSomeOnesBusinessProcessInformationModel()
      ReceiveBusinessSomeOnesBusinessProcessInformationModel()
      SendOwnBusinessProcessInformationModel()

ReceiveAcknowledgementForOwnBusinessProcessInformationModelAcceptance()

If these are, as the legend says, just "some examples of possible
access service methods," then they should be omitted.  The same is
true of these lines in Figure 7:

      RequestSomeOnesNew/UpdatedBusinessProcessInformationModel()

ReceiveBusinessSomeOnesNew/UpdatedBusinessProcessInformationModel()

== Section 14 ====================================================

Section 14 likewise suffers from putative requirements to support
OO functionality that is not actually required by the
architecture.  It begins:

(para 1)
      A Trading Partner who has implemented an ebXML Business
      Service Interface may now begin the process of discovery and
      deployment.  One possible discovery method may be to request
      the Trading Partner Profile of another Trading Partner.

Note that there is absolutely no requirement here or anywhere
earlier that the BSI has to be implemented automatically from some
top-down model.  But then the paragraph continues:

      Requests for updates to Lexicons, Business Object Libraries
      and updated or new business process and information models
      are also methods which shall be supported by an ebXML
      application.  This is the phase where Trading Partners
      discover the semantic meaning of business information being
      requested by other Trading Partners.

This attempts to normatively specify an approach to how semantics
are conveyed that I doubt will work and that is not actually
required by the architecture.  I believe that in the first release
of ebXML (and maybe for a long time after that), semantics will be
conveyed not through formal models, but through labels whose
meaning we have defined and agreed upon through prose
descriptions.  The UML diagrams are a useful heuristic, but they
are not sufficient in themselves to completely define business
semantics, at least not given the current state of information
technology.  (My hunch is that business semantics can be
completely defined in machine-processable form through very
carefully constructed and applied standard ontologies, but we're
not there yet.)

== Section 15 ====================================================

Sections 15 is excellent.

== Section 16 ====================================================

Sections 16 is excellent.

I would make one minor change
to the first sentence of Section 16, which currently reads as
follows:

      To facilitate the process of conducting electronic business,
      SMEs and other organizations need a mechanism to publish
      information about the business processes they support along
      with specific technology implementation details about their
      capabilities for exchanging business information.

I think that we can omit the words "SMEs and other" from before
"organizations."

== Section 17 ====================================================

Section 17 is, as far as I can see, nothing but one long,
irrelevant lecture on methodology.  As before, the parts that
might be relevant are parts that I disagree with.  Here XML is
presented as the output of UML-to-XML production rules.  I don't
doubt that you can create XML schemas this way, but it's my
observation that such schemas are ugly and unintuitive.  If Figure
9 describes an architecture, then it is an ugly architecture, one
that will produce unfriendly standards that real users will hate
us for.

I do wholeheartedly agree with the description of the relationship
to Core Components in Section 17.7:

      A business process can be seen as a series of actions on
      entities within an enterprise, interleaved with a set of
      communications with parties outside the enterprise. The
      communication between the parties is the shared part of the
      business process. This is the focus of ebXML.

This is lovely: clear, concise, and accurate.

      The entities within an enterprise are called business
      entities, and their data structure can be represented by
      Business Objects.

But it must be understood that XML business objects are nothing
but data.

      The communication with parties outside the enterprise takes
      place through an exchange of business messages.

I would add "whose meaning is standardized by ebXML."

      Both Business Objects and business messages are composed
      from core components, re-useable low-level data structures.

I would add "whose meaning depends to some extent on their
context."

      The exact composition of a Business Object or a business
      message is guided by a set of contexts derived from (among
      other sources) the business process.

I would rewrite this one as follows:

      The exact meaning and composition of a business message is
      guided by a set of contexts derived from (among other
      sources) the business process.

== Section 18 ====================================================

I think that Section 18 is quite good, but unless I'm missing
something, this part could be simplified:

(para 3)
      A Core Component may contain:

       - another Core Component in combination with one or more
         individual business information pieces.

       - other Core Components in combination with zero or more
         individual business information pieces.

Doesn't this say the same thing?

      A Core Component may contain one or more Core Components in
      combination with one or more individual business information
      pieces.

Also, in paragraph 5

      Context may be structural, identifying the placement of a
      Core Component within another Core Component. It may be a
      combination of structural contexts when the Core Component
      is re-used at different layers within another Core
      Component.

The beginning of the second sentence above seems to need further
work.

And there seems to be an OO assumption in paragraph 8:

      Individual Core Components will in general match the "data
      list" part of Business Objects.

This seems to suggest that there is more to a business object than
data.  This direction is followed throughout Section 19, which
immediately follows.

== Section 19 ===================================================

It seems to me that we are overloading the term "business object"
to the point of incomprehensibility here.  If the XML documents
being exchanged between businesses are "business objects," then
"business objects" are just data.  If "business objects" are more
than data, then they fall outside the domain of ebXML.  In my
opinion, we are not here to standardize the details of business
processes; we are here to standardize the meanings of references
to business processes.  The modeling of business processes is an
aid to correctly defining the XML data objects that real users are
going to be exchanging to do business.  But the users I care about
are not going to be exchanging objects with embedded methods.
Thus, I completely disagree with the view of business objects
expressed in Section 19.2 if the objects referred to are the
contents of business messages.

== Section 20 ===================================================

20.2, remove SQL discussion

20.4, bullet 5, will repository store any object or just XML documents

20.7, remove implementation details

== Section 21 ===================================================

21.3, bullet 6, remove mention of pagers and e-mail






[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