[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]
Powered by eList eXpress LLC