Status of the Components 1.1 RTF

1
Status of the Components 1.1 RTF

• Philippe.Merle_at_lifl.fr
• INRIA Scientist Researcher
• OMG Components 1.1 RTF Meeting
• OMG Meeting, Helsinki, Finland,
• September 30th, 2002
• OMG TC Document ccm/2002-09-01

2
Outline

• Components 1.1 RTF summary
• Interim report and results of the vote 1
• Next Steps

3
Components 1.1 RTFFormation

• Chartered By Platform Technical Committee
• Meeting Location Yokohama, Japan, April 22-26,
  2002
• Voting List Deadline Date April 26, 2002
• Interim Comments Deadline Date July 1, 2002
• Interim Report Due Date October 7, 2002
• Final Comments Due Date February 3, 2003
• Final Report and Revision Due Date April 14, 2003

4
Components 1.1 RTFMembership

• Julien Maisonneuve Alcatel
• J. Scott Evans Computational Physics, Inc.
• Tom Ritter Fraunhofer FOKUS
• Garry Turkington Government Communications
  Headquarters (GCHQ)
• Jishnu Mukerji Hewlett-Packard
• Harald Böhme Humboldt Universitaet
• Nawel Sabri INRIA
• Philippe Merle LIFL (Chair)
• Jim Kulp Mercury Computer Systems
• Rudolf Schreiner Object Security Ltd.
• Hakim Souami THALES
• Diego Sevilla Ruiz Universidad de Murcia
• Shahzad Aslam-Mir Vertel Corporation

5
Components 1.1 RTFProduced Documents

• ptc/2002-08-02
• Interim Report of the Components 1.1 RTF
• ptc/2002-08-03
• Edited CORBA Components Specification
• Based on OMG TC Document formal/2002-06-65
• Will be presented to AB
• Next Thursday 03/10/02

6
Outline

• Components 1.1 RTF summary
• Interim report and results of the vote 1
• Next Steps

7
Components 1.1 RTF Interim ReportSummary

• Issue disposition
• 21 accepted
• 24 unresolved
• 0 rejected
• 0 duplicate
• Degree of changes
• 2 significant changes
• 5092, 5499
• 9 minor changes
• 4983, 5091, 5093, 5429, 5496, 5498, 5500, 5577,
  5584
• 10 support text changes
• 4986, 5340, 5492, 5493, 5494, 5495, 5497, 5506,
  5583, 5585

8
Components 1.1 RTF Interim ReportProfile of
Changes

• 7 - Editorial issues
• Issues 5493, 5494, 5395, 5497, 5506, 5583, 5585
• 1 - Two generic component operations (chapter 1)
• Issue 4983
• 3 - The CIDL grammar (chapter 2)
• Issues 5498, 5499, 5500
• 1 - CIF language mapping (chapter 3)
• Issue 5340
• 7 - XML DTDs (chapters 6 and 7)
• Issues 5091, 5092, 5093, 5429, 5492, 5496, 5584
• 1 - Component deployment (chapter 6)
• Issue 5577
• 1 - The Notification Service IDL
• Issue 4986

9
Components 1.1 RTF Interim ReportVoting History

• Vote 1
• Date 2nd to 9th September 2002
• 21 issues
• 4983, 4986, 5091, 5092, 5093, 5340, 5429, 5492,
  5493, 5494, 5495, 5496, 5497, 5498, 5499, 5500,
  5506, 5577, 5583, 5584, 5585
• Results
• 11 YES
• 0 NO
• 1 ABSTAIN (Hewlett-Packard)
• 1 non-voting company (GCHQ)

10
Components 1.1 RTF Interim ReportErratum

• Issue 5091 was accepted during the Vote 1
• Page 10, replace Unresolved by Accepted
• Ditto in Table of Contents

11
Outline

• Components 1.1 RTF summary
• Interim report and results of the vote 1
• Next Steps
• 24 unresolved issues from the interim report
• 1 new issue from THALES
• 25 issues to resolve

12
Next Steps

• Agenda
• Final Comments Due Date February 3, 2003
• Final Report and Revision Due Date April 14,
  2003
• gt report presented to AB April 10, 2003
• gt report sent to OMG March 17, 2003
• gt last vote starting date March 1st, 2003
• Tasks
• Assign issues to RTF members
• Send draft resolutions on the RTF mailing list
• Start the vote 2 when enough resolutions

13
Unresolved Issues Summary

• 20 issues related to XML DTDs
• Issue 5576 related to the component deployment
• Issue 5588 related to EJB interworking
• Issue 5591 related to the Configurator interface
• Issue 5594 related to the IDL metamodel
• Issue 5639 related to the container API

14
Unresolved Issue 550769.8.2 Property File XML
Elements

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• Why empty properties files are possible?
• Replace
• lt!ELEMENT properties ( description? , ( simple
  sequence struct valuetype ) ) gt
• by
• lt!ELEMENT properties ( description? , (
  simple sequence struct valuetype ) ) gt
• Comments
• Could be rejected because
• no impact on implementation, not spec. or impl.
  Issue
• Empty files could simplify generation from MDA
• But could be also accepted

15
Unresolved Issue 550869.8.2.8 The simple
Element, page 69-538

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• A) No way to set IDL enum properties
• Add the enumerations to the simple element
• B) 2 occurences of short in the simple element
• C) Add an optional units element
• D) Add property kind
• Comments
• A) Accept but a new proposal must be written
• B) Already resolved in issue 5429
• C) Reject as not required for automatic
  deployment, units is just a descriptive
  information
• D) Reject as no semantics defined and not related
  to deployment BUT problem must be studied
  before any resolution

16
Unresolved Issue 550969.8.2.7 The range Element,
pages 69-537/538

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• Why is the min and max order not specified in the
  range element?
• lt!ELEMENT range (value, value) gt
• Proposal
• lt!ELEMENT range EMPTYgt
• lt!ATTLIST range min CDATA REQUIRED
  max CDATA REQUIREDgt
• Comments
• Already addressed during FTF, must be checked
• More precise or readable
• Could be accepted or rejected

17
Unresolved Issue 551069.8.2.3 The choices
Element, page 69-537

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• Why range is a child of the choices element
• lt!ELEMENT choices ( choice range )
• Proposal
• lt!ELEMENT choices ( choice )
• lt!ELEMENT simple ( description? , value ,
  choices? , range? , defaultvalue? ) gt
• Comments
• Could be rejected as a choices could be equals to
  1 10..20 - 30

18
Unresolved Issue 551169.8.2.9 The sequence
Element

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• Sequences of simple properties could be
  syntactically correct but semantically incorrect,
  i.e. each simple elements could have a different
  types
• Add a simplesequence element
• Comments
• Could be accepted but proposal must be study in
  depth

19
Unresolved Issue 5512

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• add a test property definition to the properties
  DTD
• Comments
• Could be rejected as
• No semantics defined
• What the associated use case is
• See if this will be addressed by submissions on
  the Deployment and Configuration RFP
• Wait the last minute before resolving this issue

20
Unresolved Issue 5513

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• Add the capability to define a component artifact
  property
• Comments
• Could be rejected as
• What the associated use case is
• Seems to be domain specific?
• See if this will be addressed by submissions on
  the Deployment and Configuration RFP
• Wait the last minute before resolving this issue

21
Unresolved Issue 551469.3 Software Package
Descriptor

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• Replace
• lt!ELEMENT softpkg ( title pkgtype author
  description license idl propertyfile
  dependency descriptor implementation
  extension ) gt
• By
• lt!ELEMENT softpkg ( title? , author ,
  description? , propertyfile? , license? ,
  pkgtype? , implementation , ( idl dependency
  descriptor extension ) ) gt
• Avoid several title, description, propertyfile,
  license, pkgtype
• Comments
• Could be accepted as make sense
• But this will be better to define a meta model
  for packaging

22
Unresolved Issue 5515 - 69.3.2.15 The
implementation Element, pages 69-478/479

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• Replace
• lt!ELEMENT implementation ( description code
  compiler dependency descriptor extension
  programminglanguage humanlanguage os
  propertyfile processor runtime ) gt
• By
• lt!ELEMENT implementation ( description?, code,
  compiler?, humanlanguage?, programminglanguage?,
  propertyfile?, ( dependency descriptor
  extension os processor runtime
  usescomponent ) )gt
• Avoid several description, code, compiler,
  humanlanguage, programminglanguage, propertyfile
• Comments
• Could be accepted as make sense
• But this will be better to define a meta model
  for packaging

23
Unresolved Issue 551669.8.2.7 The code Element,
pages 69-474

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• a) Add the optional stacksize and priority
  elements to code element definition
• b) Other valid values for type attribute
  "KernelModule", "SharedLibrary", and "Driver".
• Comments
• Could be rejected as domain specific
• a) Element extension could be used or define a
  generic property element child of the code
  element, e.g.
• ltcode gtltproperty namestacksize
  value1000/gt lt/codegt
• b) CCM gives code type examples other are
  possible, proposed examples could be friendly
  added

24
Unresolved Issue 5517 - 69.3.2.15 The
implementation Element, pages 69-478/479

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• Add the license element to the implementation
  element
• Else all implementations of a soft package have
  the same license
• Comments
• Could be accepted as this makes sense

25
Unresolved Issue 5518 - 69.3.2.25 The
propertyfile Element, page 69-482

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• Propertyfile clarification is needed for
  consistent behavior. The only statement made
  about propertyfile is that the implementation's
  propertyfile has precedence over the same
  propertyfile types at the softpkg level. Why are
  multiple property files needed at the softpkg and
  implementation levels? If more than one
  propertfile exist at any level, which property
  file has precedence in the list? If multiple
  property files exists are they merged together?
  Are the softpkg's descriptor element property
  files merge with the softpkg property files and
  which one has precedence? Are the
  implementation's descriptor property files merge
  with the implementation property files, and which
  one has precedence? Are implementation property
  files merge with the softpkg property files?
• Comments
• Must be accepted as clarification is required

26
Unresolved Issue 551969.3.2.14 The idl Element,
page 69-478

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• a) Add idl element to implementation element. Why
  is idl only at the softpkg level? This is saying
  that all implementations use the same IDL. This
  is inconsistent with descriptor element. An
  implementation can specify a descriptor, why not
  idl? Cannot an implementation use a specific IDL
  for its implementation?
• b) Why is IDL defined in the software package
  descriptor instead of the CORBA Component
  descriptor?
• Comments
• a) one IDL by softpackage and all its
  implementations
• B) normal as it is shared by all implementations

27
Unresolved Issue 5520

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• How does the Assembly Descriptor support multiple
  components within an implementation?
• Comments
• An example must be provided

28
Unresolved Issue 552169.3.2.2 The author
Element, page 69-474

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• Replace
• lt!ELEMENT author ( name company webpage ) gt
• By
• lt!ELEMENT author ( name, company?, webpage? )gt
• Allow to group several author names of a same
  company
• Comments
• Could be accepted or rejected as this is not very
  important

29
Unresolved Issue 5522Component Artifact
Dependency

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• An implementation may request a dependency on a
  specific component based upon its artifacts. Add
  artifactdependency to the dependency element
• Comments
• Could be rejected as
• What the associated use case is
• Seems to be domain specific?
• See if this will be addressed by submissions on
  the Deployment and Configuration RFP
• Wait the last minute before resolving this issue

30
Unresolved Issue 5523Device Artifact Dependency

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• A component's implementation may have additional
  dependencies on a device's artifacts (e.g.,
  capacity and/or characteristics) to ensure the
  right type of device is chosen for deployment
  and/or the device has sufficient capacities for
  deployment. To allow for this capability add a
  deviceartifactdependency element to the
  implementation element.
• Comments
• Could be rejected as
• What the associated use case is
• Seems to be domain specific?
• See if this will be addressed by submissions on
  the Deployment and Configuration RFP
• Wait the last minute before resolving this issue

31
Unresolved Issue 5524Uses Relationships

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• The softpkg element only deals with deployed on
  and library load dependency relationships for
  implementations. Component implementations may
  also have specific using relationships with
  another component, such as a device within the
  system. This relationship can be stated at the
  softpkg or implementation level.
• Comments
• Could be rejected as
• What the associated use case is
• Seems to be domain specific?
• See if this will be addressed by submissions on
  the Deployment and Configuration RFP
• Wait the last minute before resolving this issue

32
Unresolved Issue 557669.3 AssemblyFactory
Interface

• Source Gerald_L_Bickle_at_raytheon.com
• Summary
• 1. Ease of use Issue. After the create
  operation is performed, one is force to call
  lookup to get the Assembly that just got just
  created. Why is a cookie returned by the create
  operation instead of an Assembly? Is the reason
  because of security? If the interface were more
  open this would still allow a secure
  implementation to be implemented. Suggested
  change is
• to return an Assembly instead of a Cookie.
• Change destroy operation to take in an Assembly
  parameter instead of Cookie.
• Change lookup operation to take in a name
  parameter.
• These changes make it consistent with the other
  CCM interfaces, such as Container,
  KeyLessCCMHome, ComponentServer, and
  ServerActivator.
• 2. Multiple users Issue. For multiple users,
  how does a client know what assemblies are
  created. Add a get_assemblies operation that
  returns a list of assemblies. These changes make
  it consistent with other CCM interfaces, such as
  Container, ComponentServer, and ServerActivator.
• 3. User-friendly identifier for Assembly
  Instance issue. Add an input name parameter that
  can be assigned to the Assembly instance that
  gets created. Add a read only name or label
  attribute to the Assembly interface.
• Comments
• 1. Could be accepted as discuted on the mailing
  list
• 2 and 3. Could be accepted or rejected

33
Unresolved Issue 5588 - Update Table 5-13 in the
EJB Chapter of formal/02-06-65

• Source Philippe.Merle_at_lifl.fr
• Summary
• In ptc/01-11-03, page 64-410, there is the
  following note
• Issue This table will be completed after the
  Interface Repository chapter is ready.
• Then Table 5-13 in formal/02-06-65 would be
  completed.
• Comments
• Must be done

34
Unresolved Issue 5589Description for the
impltype Element?

• Source Philippe.Merle_at_lifl.fr
• Summary
• In formal/02-06-65, page 6-54, there is the
  following text
• Placeholder for future version.
• The section 6.7.2.33 would be written.
• Comments
• Must be done

35
Unresolved Issue 5590 - Checking XML DTD elements
related to the trader service

• Source Philippe.Merle_at_lifl.fr
• Summary
• In ptc/01-11-03, page 69-533, there is the
  following note
• Issue The trader elements have to be reviewed
  to make sure that they serve the purpose
  intended. Also, consider using a property file.
• XML DTD elements related to the trader service
  would be checked.
• Comments
• Must be done

36
Unresolved Issue 5591 - Using Configurator on
CCMHome or any CORBA objects?

• Source Philippe.Merle_at_lifl.fr
• Summary
• In ptc/01-11-03, page 69-545, there is the
  following note
• Issue The Configurator interface takes an
  argument of type CCMObject and therefore cannot
  be used to configure component homes. I see no
  reason not to widen the type to CORBAObject so
  that the Configurator can be used for objects
  other than CCMObjects. The StandardConfigurator
  is after all a basic name value pair configurator
  that simply executes calls on mutator operations
  resulting from attribute declarations. J.S.E.
• The Configurator interface could be updated to
  allow configuration of any CORBA objects.
• Comments
• Could be accepted by changing Configurator API

37
Unresolved Issue 5594CCM Interface Repository
Metamodel

• Source egon.teiniker_at_tugraz.at
• Summary
• in the BaseIDL there is a class StructDef which
  has the Attribute members of Type Field. How can
  I model a IDL struct with more than one entry? I
  think there should be a aggregation from
  StructDef (1ltgt-----gt) to the Field class (Page
  8-10 of the CCM Spec).
• ) With EnumDef there is the same problem, I
  guess a assotiation from EnumDef to string
  (1ltgt-----gt) would solve it (Page 8-10 of the CCM
  Spec).
• ) Also with ExceptionDif and its attribute
  members (Page 8-11 of the CCM Spec).
• Comments
• Must be accepted as the meta model is incorrect

38
Unresolved Issue 5639

• Source Hakim Souami, THALES
• Summary
• BE BE COMPLETED
• This is about one operation of the container API.
• Comments
• Could be accepted

39
Issues AssignationRelated to XML DTDs

• 5507 who?
• 5508 who?
• 5509 who?
• 5510 who?
• 5511 who?
• 5512 who?
• 5513 who?
• 5514 who?
• 5515 who?
• 5516 who?

• 5517 who?
• 5518 who?
• 5519 who?
• 5520 who?
• 5521 who?
• 5522 who?
• 5523 who?
• 5524 who?
• 5589 who?
• 5590 who?

40
Issues Assignation

• Related to the component deployment
• 5576 Tom Ritter and Harald Böhme
• Related to EJB interworking
• 5588 who?
• Related to the Configurator interface
• 5591 who?
• Related to the IDL metamodel
• 5594 Fraunhofer FOKUS?
• Related to the container API
• 5639 THALES?

41
Other Work?