As some of you may know but many probably don't, Everware-CBDi is intimately involved with the work going on within the Object Management Group (OMG). This is an industry group that has standardized such things as the Common Object Request Broker Architecture (CORBA) and the Unified Modeling Language (UML), and coined the term "Model Driven Architecture" (MDA ™). Last week the Object Management Group (OMG) held a week long Technical Meeting in Orlando, FL. It was quite an interesting meeting with a number of rather notable events. Below is a brief summary of some of these events. Please take note that there are many parallel meetings taking place at any one time and since I'm just one person, items that some might find valuable were surely missed. With that caveat, here goes:

UML Profile and Metamodel for Services (UPMS): This is an area where Everware-CBDI has been particularly active. We're part of a submission team with numerous other large and small organizations from around the world. The team has put forth a revised submission (the equivalent of a draft standard) to the Analysis and Design Task Force. However, due to a number of changes that came up subsequent to the submission but prior to the meeting, we’ve extended the submission date to the 4 week rule for the December meeting in Santa Clara, CA. Here are the two major changes from the Everware-CBDI perspective (note: the descriptions below are for UML devotees):

• Change "Service" to "ServicePoint": The original thought on the team was to create a stereotype of Port for Service. This would mean that one would not be able to model what we refer to as Services without Participants (the things that offer the Services in the UPMS parlance). It would also mean that a Service is a kind of "access point" (to interpret UML) instead of the generally accepted view that a Service is a capability made available to a consumer. Upon further reflection, the "access point" didn’t make sense to the team. Though we were not initially sure what the alternative would be, we finally agreed to change that stereotype name to "ServicePoint" since this is the point at which the service is accessable. The result of this change is that there is no longer a singular element called "Service". However, the team agreed that this might actually be a benefit given that there are so many slightly different definitions thereof.
• Change "ServiceCapability" to "Capability": We also decided to change the name of the element we called ServiceCapability to just Capability. ServiceCapability is the element that most closely resembles what Everware-CBDI has referred to as ServiceSpecification. We believe this makes sense because it allows us to specifically model Capabilities and relate them to ServiceInterfaces (Capabilities are accessed through ServiceInterfaces at a ServicePoint). Further, we can now say that Participants realize Capabilities. Since Participants can be organizational units, automation units, infrastructure nodes, etc., we now have a parallel mechanism for modeling capabilities of these elements and creating services to get at those capabilities. Further, this model is now compatible with the proposed standard for a Unified Profile for DoDAF/MoDAF (UPDM) that is currently out for comment. Everware-CBDI this will be a slight change but it will be relatively easy to incorporate and as stated earlier will provide a relatively standard way to model Capabilities.

Executable UML Submission Adopted: A revised submission for executable UML was accepted by the ADTF and Architecture Board. Named fUML for “Foundational UML”, this is work that has been driven primarily by Steve Mellor and Ed Seidewitz and supported by many others for the past 10 yrs or so and has finally been voted through. Executable UML potentially represents a major breakthrough in the way systems, particularly embedded systems, are built and could be the basis for the next generation of MDA tools. This standard is being closely followed by an RFP for a concrete syntax for a UML Action language. The responses to the Action Language RFP will provide a standardized concrete syntax for the executable elements of UML.

Unified Profile for DoDAF and MoDAF (UPDM) RFC Issued: For those not familiar with all the acronyms let me fill in the blanks. “DoDAF” stands for (US) “Department of Defense Architecture Framework” while “MoDAF” stands for (UK) “Ministry of Defence Architecture Framework”. The “RFC” acronym stands for “Request for Comment”. What this means is that the UPDM submission process has been changed from the more common “RFPSubmissionRevisionAdoption” process to one that is normally applied to what is considered an industry defacto standard. The RFC process essentially boils down to taking an industry standard, issuing a Request for Comment on the standard and if no major issues arise, adopt it as an OMG standard. However, if any major issues arise during the comment period, it is rejected as an OMG standard. This is the process that the OMG used to adopt the Business Process Modeling Notation (BPMN) as an OMG standard.

The thing that is remarkable in this case is that one would be hard-pressed to say that UPDM is an industry standard so let me provide some background. Much work has been going on to create a submission for the UPDM RFP that was issued by OMG some years ago. At the March meeting in DC, there was major disagreement among the submission team about the direction of the submission. Chaos ensued.

Normally, that would kill the standard. However, everyone realized the importance of this standard to all parties and so DoD and MoD decided to just go the RFC route by taking the submission and turning it into an RFC. As issued, UPDM targets DoDAF 1.5/MoDAF 1.2 support. While some in the meeting suggested that it’s not ready and there’s not enough time to thoroughly review and provide comments by the 4 week rule for the December meeting (November 10), when it came to the vote, it passed 22 for, 0 against, 2 abstains.

My suspicion is that those that were initially opposed to this form of the submission will log a number of significant comments – more than what would typically be allowed for an RFC to pass. The Architecture Board will then have to decide how to get the changes made and incorporated. I believe that since DoD and MoD are such big customers, no one will want to be seen as opposing them and so the concerned parties will work to compromise and resolve the issues.