[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: New section for the TA document
Stefano, your points 1. and 2. can be covered with one answer. The choreography among business transactions, i.e. the collaboration, is NOT affected by messaging and security considerations. The patterns included in the diagram are NOT at the collaboration level, but only inside a single business transaction. And those patterns do in fact vary by security and messaging considerations. Messaging in this sense means whether the two parties agree on no confirmation, only one confirmation, or also one or more non-substantive confirmations. your point 3 is well put. The sentence was taken directly from the TA document, I did not write it. In fact I tried to change it to say that it is not UML that is optional but UMM, but that drew strong reactions from Paul and Jim. Rather than starting a big discussion on UMM I agreed to put the original sentence back in, even though it doesn't make sense to me either. I propose we dropt the sentence all together since it is not crucial to the understanding of the technical architecture. thanks, -karsten >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 >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC