RE: New section for the TA document

[Stefano POGLIANI <stefano.pogliani@sun.com>]

Here are some comments and, mainly, questions on this "critical" piece of information. I refer to the last document Karsten forwarded.

/Stefano

1.	Line 7.
	"..., messaging and security considerations". 
	I do not understand how Messaging and Security considerations can affect sequencing.
	But this is probably an hidden concept behind many of my questions here. I think
	that sequencing should be described by the BP. Here we talk, I think, about
	sequencing (choreography) at business level, not at technical level.

2.	After the first figure, in page 2
	"Each Business Transaction can be implemented using one of many available 
	standard patterns. These patterns determine the actual exchange of messages 
	and signals between the partners to achieve the required legally binding 
	electronic commerce transaction."

	From this sentence it seems that these "patterns" provide choreographic information
	on the top of each Business Transaction. If I understand correctly :
	- a Business Collaboration is a choreography of Business Transactions
	  This choreography is described by the BP and, thus, in the Specification Schema
	- a Business Transaction is described by a pattern which develops a
	  choreography that is intrinsic to the atomic Business Transaction.

	Is my understanding correct ?

	If it is, I think that some "concrete" (real life) example of a Business Collaboration,
	of a Business Transaction and of one of these patterns would be very helpful.

	And, if it is correct, why having different places to express choreography? Isn't
	a pattern something like a "subprocess" ?

3.	First sentence of Page 3, after figure 2.
	There is a contraddiction, I think. In my reading, this is the interpretation : "It is
	not required to use any language, but if you use one it should be UML". 
	Why is this different from "Speak UML or don't speak at all!" ?




> -----Original Message-----
> From: Karsten Riemer [mailto:Karsten.Riemer@east.sun.com]
> Sent: Tuesday, December 19, 2000 4:09 PM
> To: Jim Clark
> Cc: ebxml-bp@lists.ebxml.org
> Subject: Re: New section for the TA document
> 
> 
> Jim,
> you are right,
> here is the correct document,
> 
> -karsten
> 
> >Karsten,
> >
> >I think you sent out the wrong doc.
> >
> >Jim
> >
> >Karsten Riemer wrote:
> >
> >> Jim,
> >> I have re-instated the orignal TA phrase about UML being 
> optional, instead
> >of
> >> my closing paragraph about UMM being optional. Let's see if we 
> can agree
> >on
> >> the document in that form, even though clearly the TA phrase needs some
> >> re-wording. The document now consists of 3 short paragraphs 
> over and above
> >the
> >> current TA section, and this is the minimum we can get away 
> with, if we are
> >to
> >> cover how the Specification Schema is a semantic subset of the 
> metamodel,
> >what
> >> it covers, and that the patterns are a necessary companion.
> >>
> >> -karsten
> >>
> >> >Karsten,
> >> >I believe I understand the goal you had in the rewriting of sec 9.2.1.
> >> >However, I have some strong
> >> >objections to the new perspective.
> >> >
> >> >1) The statement that use of UMM as optional is not 
> necessarily true. The
> >use
> >> >or non use of a particular
> >> >methodology is determined on the goal desired. The BP 
> analysis who role is
> >to
> >> >define a analysis process and
> >> >methodology would state that if one were going to develop a Business
> >> >Collaboration specification, (Top down
> >> >as you know it) UMM is a requirement. We should not put text 
> into the TA
> >that
> >> >is contrary to a different
> >> >viewpoint.
> >> >
> >> >2) There is wording that the different views of the metamodel 
> are there
> >to
> >> >support the different phases of
> >> >the UMM. This is also incorrect. The fact that the UMM now uses this
> >> >metamodel is coincidental. The views
> >> >are different perspectives of the same metamodel, based on 
> the "ViewPoint"
> >of
> >> >the user/audience of the
> >> >specification, dependent on whether the user is a Business 
> Person, Domain
> >> >Expert, Business Analyst,
> >> >Information Modeler, System Analyst, System Integrator or Implementor.
> >These
> >> >viewpoints provide a set of
> >> >semantics (vocabulary) that is familiar to each and form the basis of
> >> >specification of the objects and
> >> >artifacts that are required to facilitate business process and
> >information
> >> >integration and
> >> >interoperability.
> >> >
> >> >3) My understanding of the Specification Schema was to 
> provide a mechanism
> >to
> >> >specify the ebXML
> >> >business process for the "Infrastructure Release". It is providing a
> >> >mechanism which allows for the "bottom
> >> >up" specification approach and a possible point of integration of the
> >"top
> >> >down" approach. In the TA, this
> >> >new section positions it as a competition to the use of UMM, thus
> >inferring
> >> >that it is the required
> >> >approach.
> >> >
> >> >4) In the end of the section, the reference to mandating the 
> use of UML
> >was
> >> >dropped or changed to making
> >> >the use of UMM optional but recommended. Again, this may/does 
> not reflect
> >the
> >> >view of others in the BP
> >> >Team. Originally, this section was trying to say that use of UML, as a
> >formal
> >> >specification language
> >> >(remembering that we are talking about syntax and semantics, 
> not notation
> >> >(diagrams)) was mandatory and not
> >> >saying anything about a methodology.
> >> >
> >> >I would recommend that we simply clean up the section a 
> little (there are
> >> >inconsistencies in terminology)
> >> >and leave it as is. Currently it does not preclude the different
> >perspectives
> >> >and at a high level explains
> >> >what we are doing. If we must include the level of detail 
> that you have
> >> >included, then we must do so from
> >> >each perspective and I suspect supply some rationale. I would 
> rather do
> >this
> >> >in each respective document or
> >> >specification. If we must do it here, then we have a lot more to do.
> >> >
> >> >Also we may want to a simple statement about the Infrastructure
> >Specification
> >> >without postioning it against
> >> >other perspectives.
> >> >
> >> >I guess I am asking, how detailed must this section and how 
> much wiggle
> >room
> >> >can we give ourselves.
> >> >
> >> >Respectfully,
> >> >Jim Clark
> >> >
> >> >PS: I am also working on the ebXML Collaboration 
> Communication Reference
> >> >Model, which defines the logical
> >> >(software) layers that provide for the definition of 
> responsibility and
> >> >seperation of concerns. I have more
> >> >than enough, for the TA, but again I am wondering about the level of
> >detail
> >> >in the TA doc. I would rather
> >> >make reference in the TA and leave the details in the specification.
> >> >
> >> >Karsten Riemer wrote:
> >> >
> >> >> Hi,
> >> >> I have grabbed pieces from the current TA doc, pieces from 
> Jim Clark's
> >> >> metamodel specification doc, and pieces from my original TA 
> proposal to
> >> >form
> >> >> the attached replacement for section 9.2.1. in the TA v0.94.01.b
> >> >>
> >> >> Please let me know if you have any issues with this.
> >> >> If not, I will send it to TA group for inclusion.
> >> >>
> >> >> This satisfies one of the two pieces we had promised TA.
> >> >> The other is an explanation of software tiers to support Business
> >> >> Transactions, vs. those to support Business Collaborations.
> >> >> Bob Haugen, do you want to take a stab at that, since you 
> were the one
> >who
> >> >> asked for it.
> >> >>
> >> >> I will now cut and paste from the attached doc into Jim's 
> specification
> >> >> document to make sure wording is consistent both places.
> >> >>
> >> >> thanks,
> >> >> -karsten
> >> >>
> >> >>  
> >------------------------------------------------------------------------
> >> >>                                                Name:
> >> >MetamodelArchitectureRevisedAgain.zip
> >> >>    MetamodelArchitectureRevisedAgain.zip       Type: Zip Compressed
> >Data
> >> >(application/x-zip-compressed)
> >> >>                                            Encoding: BASE64
> >> >>                                         Description: WinZip
> >>
> >>   
> ------------------------------------------------------------------------
> >>                                         Name:
> >SpecificationSchemaRevised.zip
> >>    SpecificationSchemaRevised.zip       Type: Zip Compressed Data
> >(application/x-zip-compressed)
> >>                                     Encoding: BASE64
> >>                                  Description: WinZip
> 
>