Talk:De-blue MessageCommunicationsControl

Transmission wrappers

Use, but remove from RIM

Dan Russler (in an e-mail, paraphrasing) suggests not to include the blue classes in the RIM anymore (but to keep on using them)

Replace by RIM classes

Replacing the blue classes by RIM classes is an option. This adds some abstraction (Structural Attributes) which will show at the XML level.

There is a secundary motivation for doing this: it will allow for requirements analysis to be (re)done. The existing blue classes were mostly ported from v2 and are based on requirements that may not exist for v3. The fact that INM has already removed attributes from the blue classes because of a "lack of underlying use-case" is a symptom of the need to do a requirements analysis.

A mapping is feasable:

RIM based wrappers (mockup)

• Message is an act,there is a participation/role/entity for for CommunicationFunction
• Attachment is just message.txt
• There is an ActRelationship for Acknowledgement to another message or transmission
• Batch has an ActRelationship to batches or messages.
• Acknowledgement detail is another act relationship/act?
• QueryByParameter is the act of querying. ParameterList is some kind of collection Act.
• ParameterItem is a problem if one attempts to fully model it - it can be any of the 6 base classes or an attribute. Only real options are to either stick with blue for parameter, or to be creative and use a "creative" act (the act of "selecting a subset") which is essentially a key/value pair.

WGM Sept2006, 20060911

At the joint MnM/INM meeting the issue was discussed. Rene reviewed the contents of the Wiki page (as of 20060911), and showed the mockup model. Grahame: another reason for doing this is related to ITS problems, because blue classes are different, no structural attributes. Initial response awful, but looking at it there may be good reasons. Woody: a RIM question. Will it lead to greater clarity. Document is a precedent, unfortunately. Grahame: initially felt the same, spent time working on what it would look like. More expressive, if you understand RIM more naturally, not convinced that its particularly worse. Craig: if redone, through ballot process, let it go ahead, go to ballot. Lloyd: any specific questions that INM should answer? Woordy: Can all of the concepts be expressed? Would some UML transport standards not be more appropriate? Charlie: mutiple options there. Grahame: grey zone advanced/simple transport.

Woody felt that moving the communications information into the backbone would obscure the content. He feels that the RIM backbone should be focused on Acts, and that communications concerns should not pollute the backbone. He suggested that finding an external approach that is commonly accepted may be preferable to spending significant effort maintaining our own.

There is some question as to the mappability from the existing model to the proposed model. However, this may be an opportunity to clean up the communications model.

Lee Coller expressed a reluctance to make significant changes to the transmission infrastructure based on the number of existing implementations of these. However, he also expressed a desire to have the query infrastructure revamped.

Lee C: There are R1 implementations, this is a radical change.

Charlie: slight disquite, not a methodlogical objection.

2006911: While there were some concerns MnM sees no functional objection and request a proposal (to represent the existing structures based on analysis supported by requirements) to do a mapping to RIM backbone. Evaluation of this more proposal [outcome by MnM to see if there is no methodlogical misfit] (Charlie/Woody, 21-0-3)

Jan2007 WGM

• Committee agrees to "de-blue" the current models. Some problems are expected with parameterItem.
• Motion: committee feels we should move forward and de-blue the models as a strategy. Has a number of advantages. (Mark/Rene, 6-0-0)

An advantage which has not yet been explicitely documented: de-blueing would allow the use of templates in queries.

Getting there gracefully

Gracefully migrating the message control classes to proper RIM classes.

I am glad that this subject finally gets momentum. I've been wanting this change to happen for many years. Here is a proposal to get there gracefully, with something very close to backward compatibility. Here is how we can get there:

1. color the classes, which is pretty straight forward

2. make these classes into subclasses of their appropriate parents, as is

2.1 Transmission is-a Act

2.2 CommunicationFunction is-a Participation (with a little bit of role stuff pulled in)

2.2.1 fix the association from CommunicationFunction to Transmission to many-to-one, and not many-to-many

3. re-route the 3 associations that went from a Participation direct to an Entity

3.1 this is easy for the Device connection, as the Role "Agent" is already there.

3.2 for the other class, also use the Agent role

4. make TransmissionRelationship subtype of ActRelationship

5. Lave the direct relationships between Act-like classes for now.

5.1 But fix the the association from Message to ControlAct to be Message:0..*::0..1:ControlAct, rename the wrong "payload" UML association role to "message".

6. do some mild attribute shuffling, nothing major

6.1 fix Act moodCode to EVN of course

This is pretty straight forward. Of course there would be much more to do to make it really nice, but we need something sooner that can be adopted with mild changes only, just to get us out of the mud. Gschadow 04:42, 12 August 2009 (UTC)

Woody: IMHO the timing of this is awful:

• In a period when there is finally action going on to revise the behavioral model and adopt a new (SA) Enterprise Architecture Framework, this would seem to be the worst possible time to re-cast the the Blue Classes.
• It isn't even clear to me that there is ANY advantage to shoe-horning these apparently-orthogonal concepts into the RIM backbone space, but I should probably not have added that to this note. GWBeeler

Discussion at the September 2009 WGM

Grahame points out that the blue message classes may be pulled anyway as part of the SAEF work. Rene points out that not all technology frameworks have the capability to carry such data (e.g. MLLP), so he still sees a requirement for this type of data. Grahame doesn't see the need for them, but would like to see a full fledged proposal.

Preparation of Proposal, Discussion

In response to Woody and Grahame's note: I would be most happy if this stuff would go away entirely -- it has always been my concern that we are duplicating this technical networking stuff rather than just using whatever SMTP or HTTP or SOAP have to offer. To Rene's point I would even respond that in these MLLP connections usually the sender and receiver are implicit and hence may not even require this stuff. One could deprecate MLLP altogether and only support HTTP and SMTP for also. But after all of this is said, when it comes to understanding communication activity for the business, I personally end up mapping all of this back to RIM Act. In my implementation, all system actions are RIM Acts also and I have already implemented this change in my ICSR implementation.

Does the above proposal stand a chance to be adopted at harmonization? Is not the impact of this too great? I suppose this would be effective not before the next complete new release of all the standards that use the wrappers today. If this stands no chance in harmonization, I don't really have the time to push this now. So, would be glad if the opponents would come forward and discuss this down right here and now. Gschadow 03:50, 25 September 2009 (UTC)