IMS Project - instructional media + magic

('8&$86(

,06�3URMHFW

Instructional Management Systems

8VHG�E\�SHUPLVVLRQ��'RZQORDGHG�IURP�KWWS��ZZZ�LPVSURMHFW�RUJ��$SULO��,QWURGXFWLRQ�DXWKRUHG�E\�'HQLV�1HZPDQ��'LUHFWRU�RI�0DUNHW'HYHORSPHQW��,06�3URMHFW�

http://www.imsproject.org/

IMS SPECIFICATIONS

The Instructional Management Systems (IMS) project has recently released technicalspecifications that will simplify the deployment and use of learning materials over theInternet and that will help organizations and individual learners manage the learningprocess. The goal of the IMS project is the widespread adoption of a set of openstandards for Internet-based education. The specifications will assure interoperabilityamong management systems and the independence of content from systems. Thespecifications address requirements from higher education, corporate and governmenttraining, continuing education and K-12.

The specifications that follow were released between March 23 and April 29, 1998 andare expected to be revised in August 1998. Latest versions of these specifications canalways be found on the IMS web site at http://www.imsproject.org/specs.html. Theseparate meta-data specification documents are described athttp://www.imsproject.org/md_overview.html and located athttp://www.imsproject.org/textdictionary.html andhttp://www.imsproject.org/metadata_sets.html.The project has also made freely available an example implementation of an instructionalmanagement system that illustrates many of the specifications.

Scope. The IMS specifications address five areas.

• Meta-data are fields and associated values that describe a physical or electronic item.IMS has defined an extensible collection of meta-data for learning materials. TheIMS is also developing, with the National Institute of Standards and Technology(NIST), a repository of meta-data terms that will be a resource to the broadcommunity of content developers, users, and service providers to facilitate theidentification and reuse of common meta-data terms. Common terms simplify theprocess of tagging and discovering learning resources via Internet-based tools.Common terms also enable the development of technologies that can enhance anonline learning experience through automated and intelligent processes (i.e. smartagents, intelligent tutors). The IMS Meta-data TermsRepository includes bothelectronic interfaces and a human-based conflict resolution process that providesstability of meta-data while supporting innovation via the creation of new meta-dataterms for specialized content areas and organizations, but all inheriting core, stableIMS meta-data terms.

• Content interfaces define the actions and responses that IMS-conforming content mayperform. In some cases, such as with static HTML content, the content's support ofthe actions/responses associated with a particular interface may be inferred by meta-data values and mediated by an IMS-conforming management system.

• The management interfaces support interoperability and deployment of any IMS-conforming content to any IMS-conforming management system. Managementinterfaces will form the skeleton of instructional management system products thatconform to the IMS specification for management software. The IMS specifications

for management software do not specify user interface requirements. It is expectedthat management software will be developed with user interfaces appropriate for themarket that the developer wishes to address.

• Profiles are mobile, user-controlled collections of personal and educational data.Portfolio information may be stored or referenced within the profile. Preferenceinformation such as learning styles, default meta-data selections may be included. AnIMS Profile for a user may include both learner-specific and author-specificinformation since an individual can be both a teacher in one context and a learner inanother. The granularity of the educational or skill certifications stored in the profileis not specified. Skill certifications can be digitally signed or not.

• External interfaces provide a means by which IMS-conforming content andmanagement software can leverage external systems that are likely to be found in anonline learning environment such as student information systems, registrationsystems, electronic commerce systems, and libraries.

Industry consensus. The IMS specifications already have broad support among industryand among leaders in higher education, training, government and K-12 schools. A widerange of organizations have invested in the IMS project and continue active involvementin the technical work, in advanced work with the example implementation as well asinternal development of products for the new digital education marketplace. As of April29, 1998, IMS investment members are: Apple Computer, Asymetrix, AT&T LearningNetwork, @Learning, Buena Vista University, California State University, COLLEGIS,COLLEGIS Research Institute, Committee on Institutional Cooperation (CIC),Educational Testing Service, Empower Corporation, Farance Inc., George MasonUniversity, IBM Education, International Thomson Publishing, KPMG Peat Marwick,Miami-Dade Community College, Microsoft, National Institute of Standards andTechnology (NIST), Oracle, Peoplesoft, Simon & Schuster, Sun Microsystems, Unisys,University of California, University of Michigan, University of North Carolina at ChapelHill, UK Joint Information Systems Committee, and the US Department of Defense.

Establishing a standard. The specifications are being submitted to the Institute ofElectrical and Electronics Engineers (IEEE) to begin the process of establishing aninternational standard. The National Institute of Standards and Technology (NIST) isassisting the IMS project team in developing a conformance testing and certificationprogram.

Relationship to AICC. The IMS specifications are more general and address a broaderset of issues for interoperability than those developed by the Aviation Industry CBTCommittee (AICC). Like IMS, the AICC submits its specifications to IEEE. To a largeextent, AICC and IMS are complementary. Where they overlap, IMS takes a moregeneral approach. While AICC applies narrowly to training courseware, IMS’sspecification applies to higher education, K-12 learning, as well as to training, includingperformance support, and aspects of knowledge management. IMS also addressessecurity and the integration of instructional management into the enterprise, providingspecifications for the connections to student record systems, student profiles, electroniccommerce and libraries. IMS and AICC are working together under a memorandum of

understanding to assure that their approaches are consistent. IMS is implementing anadaptor that will assure that content conforming to AICC will operate on a serverconforming to the IMS specification (however, IMS-conforming content will notnecessarily run on an AICC-conforming server).

Background on the project. The IMS project is part of Educom(http://www.educom.edu), a non-profit consortium of 600 colleges and universities and100 Corporate Associates that facilitates the introduction, use and access to, andmanagement of information resources in teaching, learning, scholarship, and research.Project staff are drawn from California State University's Center for DistributedLearning, from the COLLEGIS Research Institute, and from other member organizations.Blackboard Inc. is developing the example implementation under contract incollaboration with other project members. IMS works with the Defense Department'sAdvanced Distributed Learning (ADL) initiative providing technical specifications tosupport their guidelines for distributed training systems. Additional information on theIMS project can be found at http://www.imsproject.org.

Educom’s IMS Design Requirements

December 19, 1997

IMS Project Requirements

This information is confidential and proprietary to the EDUCOM IMS Partnership and may not be disclosed without permission.

ii

Table of Contents1. OVERVIEW................................ ................................ ................................ ................................ .. 1

1.1 STATEMENT OF NEED ..................................................................................................................11.2 IMS PROJECT GOALS AND OBJECTIVES ........................................................................................11.3 STAKEHOLDERS...........................................................................................................................21.4 SPECIAL TERMS ...........................................................................................................................31.5 ORGANIZATIONAL/POLICY ISSUES ................................................................................................3

1.5.1 Project Deliverables.......................................................................................................... 31.5.2 Scope of Specification ....................................................................................................... 41.5.3 Future developments and potential roles of IMS................................................................ 51.5.4 Value propositions/market forces ...................................................................................... 61.5.5 Relationship to prior work................................................................................................. 71.5.6 Specification vs. Standards................................................................................................ 71.5.7 Compliance and Certification of Compliance .................................................................... 7

2. DESIGN................................ ................................ ................................ ................................ ......... 9

2.1 DESIGN CONTEXT........................................................................................................................92.2 DESIGN METHODS ......................................................................................................................122.3 DESIGN STRUCTURE ...................................................................................................................13

3. REQUIREMENTS................................ ................................ ................................ ...................... 16

3.1 GROUP MANAGEMENT................................................................................................................163.1.1 Essential Requirements ................................................................................................... 173.1.2 Secondary Requirements ................................................................................................. 193.1.3 Don’t Preclude................................................................................................................ 19

3.2 PERSONAL PROFILE MANAGEMENT ..............................................................................................193.2.1 Essential Requirements ................................................................................................... 203.2.2 Secondary Requirements ................................................................................................. 21

3.3 ACTIVITY MANAGEMENT ............................................................................................................213.3.1 Essential Requirements ................................................................................................... 223.3.2 Secondary Requirements ................................................................................................. 23

3.4 ASSESSMENT AND CERTIFICATION MANAGEMENT.........................................................................233.4.1 Essential Requirements ................................................................................................... 233.4.2 Secondary Requirements ................................................................................................. 243.4.3 Don’t Preclude................................................................................................................ 24

3.5 CONTENT MANAGEMENT ............................................................................................................243.5.1 Essential Requirements ................................................................................................... 253.5.2 Secondary Requirements ................................................................................................. 28

3.6 COMMERCE AND LICENSING MANAGEMENT.................................................................................283.6.1 Essential Requirements ................................................................................................... 293.6.2 Secondary Requirements ................................................................................................. 323.6.3 Don’t Preclude................................................................................................................ 32

3.7 SECURITY MANAGEMENT............................................................................................................323.7.1 Essential Requirements: .................................................................................................. 323.7.2 Secondary Requirements ................................................................................................. 33

3.8 TECHNICAL ADMINISTRATION MANAGEMENT ..............................................................................333.8.1 Essential Requirements: .................................................................................................. 343.8.2 Secondary Requirements ................................................................................................. 36

3.9 SUMMARY OF REQUIREMENTS..................................................................................................... 36

4. IMPLEMENTATION AND DESIGN RATIONALE................................ ................................ 38



iii

4.1 RECOMMENDED REQUIREMENTS ................................................................................................. 384.1.1 GROUP MANAGEMENT................................................................................................ 394.1.2 PERSONAL PROFILE MANAGEMENT.......................................................................... 394.1.3 ACTIVITY MANAGEMENT............................................................................................. 394.1.4 ASSESSMENT AND CERTIFICATION MANAGEMENT................................................. 394.1.5 CONTENT MANAGEMENT............................................................................................ 394.1.6 COMMERCE AND LICENSING MANAGEMENT........................................................... 404.1.7 SECURITY MANAGEMENT ........................................................................................... 404.1.8 TECHNICAL ADMINISTRATION MANAGEMENT......................................................... 40

4.2 ISSUES AND APPROACHES............................................................................................................404.2.1 Metadata......................................................................................................................... 424.2.2 User Profile..................................................................................................................... 434.2.3 Content ........................................................................................................................... 434.2.4 Management.................................................................................................................... 444.2.5 External .......................................................................................................................... 44



iv

PrefaceThis public document is derived from the EDUCOM/NLII Instructional ManagementSystems (IMS) design requirements process and presents the operational, business andfunctional requirements for development of the IMS specification. This specification willbe published and implemented in a proof of concept prototype that demonstrates theoperation of an IMS-compliant system. Both the specification and the prototype will bemade freely available early in 1998.

The IMS specification and prototype are being developed by an EDUCOM-sponsoredpartnership consisting of academic, commercial and government organizations. A groupof representatives from the partnership (reflecting the perspectives of all the different IMSstakeholders) created the original version of this document in March 1997. While theprimary audience for this document is a technical one, it is also intended to serve as ameans for communicating the scope and functionality of the IMS to other individuals suchas educators, learners, and the business community.



v

Organization of this DocumentThe document has four major sections:

1. Overview: presents a brief rationale for an industry-standard specification, describesthe IMS project, identifies the stakeholders, introduces some special terms used indescribing the requirements, and identifies organizational and policy issues associatedwith the project. The project deliverables are enumerated as 1) a technicalspecification that outlines how learning materials and environments should bedeveloped for operating and managing compatible content and courses, and 2) aprototype that serves as a proof-of-concept implementation of the specification.

2. Design: defines the overall design context and parameters for the IMS technicalspecification, and describes the design methods for collecting user requirements.

3. Requirements: the core of the document is a comprehensive list of the functionalrequirements that will serve as the basis for the IMS specification. The requirementsare organized by features and prioritized according to the centrality of any givenrequirement to the specification.

4. Implementation and Design Rationale: discusses how the IMS requirements will betranslated into the technical specification and proof-of-concept prototype. In addition,this section discusses implementation issues and design rationale for addressing theissues of implementing the requirements.



1. OVERVIEWThe IMS project is a partnership of educational organizations and companies workingunder the auspices of the EDUCOM National Learning Infrastructure Initiative to make iteasier for children, students, employees, and adults to learn via the Internet.

Development of software tools for teaching and learning and their integration into thelearning environment have historically been hampered by the lack of a commonly acceptedspecification that would permit them to be readily shared among institutions and across awide range of technical environments. Given the rapid transition in the informationtechnology environment from a PC-based model to a network-based model, coupled witha shift in pedagogy from teacher-centered to learner-centered paradigms, the developmentof a non-proprietary industry-standard specification can overcome this limitation andimprove the effectiveness of technology as means of enhancing learning.

1.1 STATEMENT OF NEEDSeveral obstacles have been identified that may impede the provision of effective onlinelearning materials and learning environments. The IMS Project will provide for thefollowing needs:• Standard methods for describing and locating online environments and materials• Integrative strategies for activities of teaching, learning, coordinating, and providing

educational content and experiences• Support for interactive platform-independent materials• Incentives and structure for developing and sharing content across contexts

1.2 IMS PROJECT GOALS AND OBJECTIVESIn order to address the above needs, the IMS project will seek to support the NLII’s goalsof improving access, containing costs and enhancing the quality of educationalopportunities. To this end, the goal of the IMS project is to enable an open architecturefor online learning.

An open architecture will provide for the following objectives:• Center the educational experience around the needs and interests of the learner.• Enable learning to occur any time, any place.• Allow for greater customizability and flexibility of the learning environment.• Promote interactions among teachers and learners.• Protect and compensate the work of educational content developers.• Improve the quality and number of choices in on-line learning content and services

IMS Project Requirements Overview


2

In order to create an open architecture for online learning, the development of the IMSspecification began by defining a range of interchanges, or interactions, betweeneducation-oriented parties such as learners, teachers, and education providers andcollections of learning materials.

Interchanges within and between learning environments will use Internet protocols acrossthe public Internet, through private Intranets, or within self-contained implementations.The IMS specification will define the interface between systems and components, anddescribe the information that may be exchanged through these interfaces. As an openarchitecture, however, it will not prescribe the operations of specific components, nor willit prescribe a particular user interface or instructional methodology. Systems and contentthat abide by the IMS specification will be considered IMS-compliant systems andcontent.

1.3 STAKEHOLDERSThere are several stakeholders who will be affected by the IMS project. We haveidentified these stakeholders in terms of the different roles involved in the process oflearning: learners, teachers, coordinators, and providers. These roles are not discrete andpeople will often assume the activities of multiple roles. For example, a teacher may alsobe a learner and a content provider. A service provider may also play the role of anacademic coordinator and vice-versa.

The IMS project has identified some of the characteristics of and benefits for its differentconstituencies:• Learners – will be able to own and customize the learning process to a degree

heretofore not possible. They will be able to learn anytime, anyplace. Learners maybe children, students, teachers, workers, or adults. They may have a range or mix ofmotivations for learning, such as education, employment, or enjoyment.

• Teachers – will be able to access and customize easily a wide range of instructionalmaterials. They will be able to interact with learners - anytime, anyplace - and willhave extraordinary flexibility. Teachers may be formal instructors and trainers orinformal mentors and guides.

• Providers – will be able to publish to standards that will assure them of a large marketfor their products and thus promote the development and distribution of instructionalsoftware. Content providers may be large publishing houses or single authors. Theywill both have the ability to gain broad dissemination of their work and will be assuredthat it will interoperate with other objects on a basic level.

• Coordinators – will be able to offer innovative programs and learning opportunities inboth traditional and non-traditional environments. Coordinator include educationalinstitutions, commercial education providers, technology companies, etc.

While these stakeholders are described in traditional terms that reflect today’sorganizational structures and functions, availability of IMS implementations will facilitatethe development of non-traditional roles and structures, thus creating a potential for thedevelopment of new groups of stakeholders.



3

1.4 SPECIAL TERMSA brief overview of the special terms used in this document is provided here.

An IMS container is a collection of one or more learning materials. The learning materialscan be non-interactive information, such as a Web page with text and images, interactivecontent which responds in different ways based on input from a learner, or tools forcollaboration with other learners. Containers include a Container ID, a unique identifier,and metadata, information that describes the container and its contents.

Containers can be aggregated, or nested, by placing one or more containers inside anothercontainer, like building a course from a collection of selected readings, self-tests, etc. Acontainer can be disaggregated by removing it from a larger container which encompassesit. An IMS container which is self-sufficient for teaching and learning is called a learningoffering.

Containers are packaged before they are distributed. Packaging might include filling outinformation, such as copyright attribution and licensing restrictions, if any.

Offerings, or any IMS container in general, operate in an IMS environment, which is animplementation of the IMS Specification. An IMS environment “unwraps” the IMScontainer and extract its contents for delivery to the learner and facilitates interactionswithin the learning environment.

1.5 ORGANIZATIONAL/POLICY ISSUESThis section identifies assumptions, requirements and policy issues that relate to themanagement of the IMS project, rather than to the design or content of the IMSspecification.

1.5.1 Project DeliverablesThe benefits of the IMS will be realized through the creation of a technical specificationdocument that outlines how learning materials and environments should be developed foroperating and managing compatible content and courses. The first iteration of thetechnical specification will be openly available to developers in March of 1998.

In order to demonstrate the functionality of the technical specification, IMS prototypecomponents and base environment will be created as a type of reference implementation.The prototype will serve as a proof of concept for the community of potential IMS usersand developers. Any code developed for the prototype will also be made freely available.The prototype is only one implementation of the specification; the intention of the IMSProject is to enable numerous IMS implementations.

The IMS project is focused on practical outcomes: the enhancement of learning, broaderdissemination of best practices, and market development for technology-mediatedlearning. It is not a research project, though the development of enhanced on-line learningenvironments may offer opportunities for research into technology-mediated learningmethods and outcomes.



4

Therefore, the primary deliverables of the IMS project are:• Technical Specification• Proof-of-concept Prototype

1.5.2 Scope of SpecificationThe IMS Specification includes requirements for some of the activities within an onlinelearning environment. These requirements prescribe specific behavior and boundaries ofIMS-compliant environments.

For other activities, the IMS Specification does not include prescriptive requirementsbecause doing so would be either unrealistic or would stifle innovation in the developmentof IMS-compliant environments and content. These activities play a necessary role inonline learning environments. Therefore, the IMS Specification includes ways in whichthese activities can be interfaced into an IMS environment. The IMS Specificationprovides an interface to but does not prescribe how to:

• Establish costs of educational materials - Most organizations have their own businessrules that determine the cost of their offerings. In many cases, these business rules andassociated databases represent a large investment in their creation and the cost of thecomputer systems in which they reside. The IMS provides interfaces into thesesystems to leverage the investment they represent.

• Develop or select a pedagogical or assessment methodology - The IMS providesinterfaces to exchange certain types of information with instructional and assessmentcontent. The IMS does not prescribe how teaching and assessment should take place.The IMS specification is thus pedagogy-neutral, in that it enables a range of learningscenarios, including synchronous/asynchronous, local/distant, push/pull/hybrid,constructivist/behaviorist, etc., in any combination. IMS-compliant learningenvironments can support both traditional learning models, and enable thedevelopment of entirely new ones.

• Store and retrieve information --- There are many ways in which information iswritten to and read from computer storage systems. Each organization may havedifferent requirements and existing information storage/retrieval solutions. The IMSSpecification does not include requirements for storing and retrieving data withinstorage systems, such as relational databases, but the IMS Specification does includerequirements about how it will send and receive information from these storagesystems. It is assumed that each implementation of an IMS environment will providethe associated mechanism for storing/retrieving information to support the IMSenvironment’s need to send or receive information. The IMS specification and animplementation of an IMS environment is analogous to the relationship between acollege student and the registrar with respect to transcript information. There is adefined way for the student to request a copy of his or her transcript. How theregistrar stores and retrieves the information that constitutes the transcript is generallyof no concern to the student.

• Enroll and admit learners - Every organization has its own processes and criteria forenrolling and admitting learners. The processes may be supported by administrative



5

computer systems that represent large investments. The IMS provides an interface fororganizations to leverage their existing processes and computing infrastructure.

• User Interface - The IMS Specification will not include user interface requirements.User interface requirements could include such things as prescribing what buttons ormenu items must appear on a screen, where they should be located, what colorhighlighted text should be, how to display lists of items, how to display helpinformation, etc. Prescribing such features would stifle innovation and reduce theability of IMS-compliant software developers to differentiate their software from eachothers’ products. The IMS prototype will pull from “best practices” in visual designand therefore encourage common practices by example, but not required in thespecification.

The diagram below depicts the boundaries of the IMS Environment. The IMSSpecification will prescribe how interchanges occur both within the IMS Environment andbetween the borders of the IMS Environment and specific implementations. The shadedarea in the diagram represents the focus of the IMS Specification. Areas that are outsideof the IMS Environment and its gateways, or beyond the fence, are not bound by the IMSSpecification. For example, existing authoring and groupware tools can be implementedin a variety of ways, the only commonality being the ability to bring information to theIMS fence.

IMSEnvironment

Gateways

the IMS "fence"

ToolsAuthoring systemsSearch enginesGroupware

DatabasesAdministrative systemsContent storageFinancial systems

FIGURE 1: BOUNDARIES OF THE IMS ENVIRONMENT

The IMS specification is intended to be extremely generalizable, and to be permissiverather than restrictive. The objective of the specification is to facilitate the interchange andmanagement of learning materials, not to force all learning to comply with a particularorganizational, or pedagogical model, or with any particular visual interface.

1.5.3 Future developments and potential roles of IMSThe initial mission of the EDUCOM-sponsored IMS partnership is to develop anddisseminate the IMS prototype and specifications. In the long term, a scaled-downorganization will need to continue to exist, with one or more of the following potentialroles:



6

1. Continue to evolve specifications and facilitate the development of freely availablecode.

2. Mediate the convergence of market implementations of the IMS that have divergedfrom the existing standards. This function is analogous to the current role of W3C inreconciling market enhancements to HTML and releasing periodic new versions of theHTML standard.

3. Maintain a registry of authorized IMS ID issuers, as a means of ensuring globaluniqueness of IMS IDs.

4. Promote the establishment of a means for certifying learning offerings andenvironments as IMS-compliant.

Initial oversight of the IMS partnership is provided by EDUCOM. Long-term options foroversight of the project include continued EDUCOM sponsorship or becoming a workinggroup under the auspices of the W3C.

1.5.4 Value propositions/market forcesThe IMS partnership will seek to maximize the benefit-cost ratio of the entire IMS-basedbusiness/learning model, recognizing the interdependent relationship of goals such asenhancing learning, reducing costs and enhancing revenue. The business model for theIMS partnership will be value-based: the objective being to increase the relative value forall stakeholders.

From an educational consumer perspective, the primary market driver is the potential ofIMS-based learning to increase the quality of education, improve access, and reduce costs.

Commercial organizations can gain market advantage from:

• Visual interfaces: development of visual interfaces is an area where businesses andother organizations will add value, innovate, and compete (in the same way as thereare currently many different Internet email interfaces to the standard email protocols).

• Custom functionality: the IMS specification is intentionally permissive rather thanrestrictive, and offers many opportunities for local additions to the core functionality.Such additions can be used by IMS-compliant vendors to develop competitiveadvantage for their products, and to ensure that IMS does not create a lowest commondenominator for products that utilize the specification.

• Market growth: the current supply of on-line learning resources is inadequate. Thedevelopment of IMS-compliant systems should cause the supply to grow, thus creatinga larger market for such products and increasing total revenues for developers andsuppliers.

The IMS partnership will rely on market forces to determine a range of issues:

• Quality of offerings: the IMS specification does not impose any qualitative restrictionson content. The market will ensure that appropriate mechanisms develop to permitlearners and teachers to identify high quality content. As with any other product in thefree market, the advice of caveat emptor applies to consumers of IMS-basededucational offerings.



7

• Granularity of offerings: the IMS specification imposes no limits on the size of anoffering, but it is likely that, given the ability to easily aggregate learning materials, themarket will encourage content providers to break apart their current instructionalofferings into smaller modules.

• Certification structures: while the IMS specification will reflect current models ofcertification for performance or achievement, it will also permit the development ofnew educational certification models and structures that will arise in response tomarket demand.

1.5.5 Relationship to prior workOnline Teaching and Learning Projects: The experiences of Miami Dade CommunityCollege in developing Project SYNERGY Integrator and the results of a comprehensiveanalysis of other learning systems will inform the IMS design. In addition, the IMS team isaware of and exploring the many existing web-based teaching and learning managementsystems. While the IMS design will not be based on any particular learning system, thisanalysis will help the design group to ensure that no critical features are overlooked.

Indexing/searching Strategies: The IMS partnership will solicit guidance on datadictionary terms from partners and other respected parties that will be utilized to establishindexing standards. These standards are intended to make searching more productive thanit would be in their absence. The IMS design will reflect search strategies and mechanismsdeveloped by library scientists, creators of web search engines, and multimedia authors.

Existing Standards and Protocols: A core mantra for the IMS Project is to not build whatalready exists, and to leverage what already works. As much as possible we will drawfrom ongoing advances and solutions developed by industry players dedicated toovercoming obstacles for networked learning environments. Where applicable, formalstandards and protocols will be incorporated in the IMS design.

1.5.6 Specification vs. StandardsThe IMS partnership is creating a specification that is intended to become de factoindustry standards that will be distributed and implemented without first going through aformal standards process. At a later time, the IMS project will partner with anotherorganization that will take those industry standards and guide them through thenational/international standards process. The rationale for this approach is based on arealization that time to market is extremely important in this environment, and that defacto standards represent a much faster means of disseminating a design into themarketplace than do formal standards.

1.5.7 Compliance and Certification of ComplianceIMS compliance is determined relative to the IMS Specification. IMS compliance forcontent is defined as the complete implementation of required IMS metadata and IMScommunications protocols. Certification of content implies no value-judgment as to itsquality or appropriateness; only that it meets the technical requirements for use within anIMS-compliant environment..



8

IMS compliance for learning environments is defined as the ability to recognize and enableIMS communication between IMS-compliant content, between content offerings and theIMS environment, between environments from different vendors, and between users andthe environment. Communication, in this instance, implies a recognition and appropriateprocessing of metadata, and compliance with the IMS Specification with regard totransaction protocols and required operational functions.

IMS content and IMS learning environments may be certified as being compliant with theIMS Specification. Certification may include the right to use a service mark-registeredlogo on and in the certified product or content. The IMS Project will promote the creationof an entity or entities that provide IMS certification services.

A collection of IMS content may not be designated as IMS certified or compliant if it isshipped with a learning environment product that will not communicate with other IMSenvironments.

IMS Project Requirements Design


9

2. Design

OVERVIEWThis section will describe the design context into which the IMS Specification andPrototype will be introduced. Several paradigm shifts are underway in the field ofeducation, the software industry, and the marketplace that are converging to create anenvironment suited for the IMS Specification. In addition, this section will relate themethods used for determining what the basic user requirements are for integratinginstructional management systems into the current educational context. Finally, we willoutline some of the general technical architecture for implementing the Specificationaccording to the user requirements collected.

2.1 DESIGN CONTEXTOne of the most prominent attributes noted regarding the design context is the changingnature of the landscape, indicating that a paradigm shift is well underway for the processof learning. The shift does not imply a linear movement away from one approach toanother. Rather, the shift is more of an expansion suggesting that the landscape isbecoming richer and more diversified as it encompasses multiple approaches. Thefollowing diagram depicts the expanding learning landscape:

FIGURE 2: THE LEARNING LANDSCAPE

At the center of the diagram above are learners, supported by the other IMS stakeholderswe’ve identified: teachers, providers, and coordinators. The model above is intended toportray the learning landscape as becoming more learner-centered. Although some mayargue that learning is implicitly learner-centered, the pervasive methods for promotinglearning have not always been in the learner’s control. With a richer and more diversifiedlearning landscape developing, the learner has more opportunities to structure his or herown personal experience.

The actual relationship between learners, teachers, providers, and coordinators, however,is not represented well by a flat diagram of concentric circles. Rather, these parties allrelate to one another through a series of interchanges, in the form of communication orinteraction, represented more accurately by the tetrahedron model below.



10

FIGURE 3: TETRAHEDRON OF LEARNING INTERCHANGES

The black lines represent interchanges and depict two types of communication: betweendifferent stakeholders and within each stakeholder group itself. For example, there arepeer to peer interactions among learners, as well as interactions between learners andteachers, providers, and/or coordinators. What passes between parties involved in aninterchange is information, whether in the form of dialogue, a textbook, or a computerprogram.

The interchanges referenced above are affected by dimensions of the surrounding learningenvironment. There are four main dimensions: time, location, affiliation and deliverymethods, as indicated in the diagram below.

FIGURE 4: DIMENSIONS OF LEARNING INTERCHANGES

As for time, the learning environment is not limited to a linear progression and will mostlikely include both synchronous and asynchronous interactions. Regarding distance, theenvironment may be confined to one physical location, or distributed across physical andelectronic spaces. Finally, in terms of delivery methods, many learning environmentsemploy multiple channels and methods for delivering information and supportingcommunication. The combination of these dimensions constitutes the context of thelearning environment.



11

An understanding of the learning process and environment as a system of interchangessuggests a model of interrelated parts. The idea that parts of the learning process andlearning materials may be modularized supports the shift to a more diversified and learnerdriven environment. One example of this, is the popularity of the course packet withspecifically selected readings or exercises, over the static and standardized text book. Thistranslates easily to a web environment where teachers or learners are free to pick contentfrom the myriad of sources available. Another example of modularization in the learningprocess is the ability to offer a certification test at the beginning of a course that eitherpasses the student or creates an individualized set of materials and exercises to reachcertification.

This view of learning as a system of interrelated parts is mirrored by shifts in currentmodels of technology and business that will support the growth of a distributed learningindustry. On the technology side, both hardware and software systems are designed in amanner supportive of modular systems. Workstations are no longer the primary platformfor computer-based learning, rather it is the network of multiple learning stations thatconstitutes the learning environment. Similarly, the current interest in object-orienteddesign lends itself to supporting modular models of learning.

On the business side, companies are recognizing learning environments as dynamicsystems with diverse needs rather than one-size-fits-all. The ability to easily customizematerials and environments is supported by a system of interconnected parts. In addition,business models are exploring how to support the aggregation of content and the reuse ofcontent, rather than inflexible models of all-or-nothing final sales. The diagram belowhightlights the benefits of a model where content can be reused to add more value:

printed textbook model digital information modelsource: Bob Carlton, ITP

FIGURE 5: COMPARISON OF INFORMATION BUSINESS MODELS

Whether viewed from a technical, educational, or business model, the field of distributedlearning can be seen as the integration of several complimentary parts. The emphasis onthe ability to modularize content or processes should not detract from the seamlessinteraction of these different modules as the diagram below suggests.



12

source: Bob Carlton, ITP

FIGURE 6: INTEGRATIVE VIEW OF DISTRIBUTED LEARNING

Although the paradigm shifts for different aspects of the learning environments areunderway, there is often a tension between internal resistance to change and externalpressure for institution wide changes. This resistance will decrease as more stakeholdersrealize that the new paradigms for teaching will complement but not replace traditionalforms of education. Overall, however, whether or not change is welcomed, learners arebecoming more demanding consumers of instructional offerings. The need for change isbeing driven by learners and the impetus is to create and support truly learner-centeredenvironments.

2.2 DESIGN METHODSAs a result of the paradigm shifts described above, the lines between the teacher, learner,provider and coordinator are blurring. Teachers, for example, are engaging in activitiestraditionally associated with professional content providers such as publishers. Manyteachers are assembling their own work and the work of others into customized coursepackets for distribution. Similarly, content providers are engaging in teaching activities byoffering courses outside of traditional educational affiliations. Learners are assuming theroles of both providers and teachers, taking a more active approach to shaping theirlearning experiences. The coordinator of a learning environment establishes and maintainsthe relationships between teachers, learners, and providers; however, a formal relationshipwith one institution or organization is no longer required.

Relationships between providers, teachers, learners, and coordinators still exist, but theyhave changed and continue to change significantly. Because of these changes, the IMSProject focused on the activities of the learning process rather than on the fluctuating rolesof individual parties. Rather than solicit user requirements from the perspective of each ofthe stakeholders separately, we engaged in a process where representatives of all thestakeholder groups collaborated on identifying the necessary requirements for supportingthe activities of a learning environment.

The method for articulating these activities and their corresponding requirements wasbased on the practice of scenario based design. To start the process we agreed upon a setof activities characteristic of learning environments. These activities, or function groupsare listed below.



13

FIGURE 7: ACTIVITIES OF LEARNING ENVIRONMENTS

The function groups listed above served as an organizational canvas on which multiplescenarios were painted. For each function group, several scenarios were described. Fromeach scenario, we extracted the user requirements for supporting such a scenario online,the assumptions embedded in the scenario, and any issues raised by the scenario that theproject must address. The heart of this document elaborates on the user requirements anddesign assumptions gleaned from the scenarios. These requirements will be described inmore detail in the following chapter.

2.3 DESIGN STRUCTUREBased on the design context and on the user requirements collected, some preliminarydecisions were made regarding the structure of IMS environments. Two of these will bediscussed here: containers and the general architecture of IMS environments.ContainersContainers encapsulate a given amount of content, whether through literally containing theinformation or through providing a reference for the information needed. Content mayconsist of primary elements (text, graphics, movies, tools) and/or additional containers. Inthis way, containers may be added together, or aggregated within a larger container. Thecontents of a container may be sequenced according to different rules and criteria. Thepictures below are physical representations of a container and its design function (namelyto encapsulate information together). The image on the left depicts a simple containerwith primary elements of movie clips, html pages, text, and an assessment test. The imageon the right depicts a more complex container with primary elements in addition to nestedcontainers of learning resources.



14

FIGURE 8: CONTAINERS FOR LEARNING RESOURCES

In order to facilitate the discovery, storage, and retrieval of containers, each container willhave a set of metadata. The metadata of a container serves as a label on a can describingits contents.

FIGURE 9: METADATA FOR A LEARNING RESOURCE

By describing metadata about like contents in a similar manner, users will have more toolsavailable to them for locating appropriate learning resources. Metadata will also be usedto manage the distribution and use rights of a container.

ArchitectureSoftware that implements the IMS Specification is known as an IMS environment. TheIMS environment facilitates interactions and manages access to and delivery of content.The IMS environment also takes care of automatically creating and destroying temporaryIMS containers in support of developing and learning activities.

An IMS environment normally performs its responsibilities from a server in conjunctionwith a Web server, therefore supporting users with any standard Web Browser. However,the IMS Specification will not assume World Wide Web clients exclusively. Futureoperating systems and environments may provide non-World Wide Web user interfaces,such as virtual reality, for navigating data including HTML information.

An IMS environment can run on a single system disconnected from the network, but mustbe able to carry out network-based communications when and if the system is re-connected to the network. Some of the IMS environment’s functionality may bedistributed around a network to other servers or to client systems. An IMS environmentmay communicate with one or more IMS environments to exchange information. Thediagram below depicts the different types of configurations supported by the IMSSpecification.



15

Server/IMS

Environment

Server/IMS

Environment

Client/IMS

Environment

Client/IMS

EnvironmentClient

A

BC DB

FIGURE 10: IMS ENVIRONMENT CONFIGURATIONS

Connection A, above, shows two IMS environments exchanging information.Connections B, C, and D all depict the IMS server environment communicating with aclient. Connection B is a thin client, whereas in Connection C and D, part of theenvironment responsibilities are shared with the client. Connection C represents the caseof a client computer that is not continually connected to the network and may receive thebulk of its content through other means, such as a CD-ROM. This configuration,however, still must support network communication, even if only sporadically.

IMS Project Requirements Requirements


16

3. Requirements

OVERVIEWThis chapter is the core of the document. Here we will present the list of userrequirements organized according to feature sets. The feature sets will be described inturn, any assumptions regarding the features will be expressed, and then the requirementsthat engender these features are listed with italicized examples when appropriate. Thefeature sets organize the requirements according to functionality. There is not a one-to-one correspondence between requirements and features, and several of the requirementscould support more than one feature set. For organizational purposes, however, we havechosen to put requirements in only one category rather than replicate requirementsthroughout the document.

Within each category, or feature set, the requirements are listed in rank order, from thosethat are essential to any implementation of an IMS-compliant system, to those that aresecondary-i.e. while desirable they are optional and may or may not be implemented in aparticular IMS-compliant system, and, finally, to those identified as “do not preclude” –i.e. requirements that may at some time be useful, and should not be prevented from beingimplemented by virtue of decisions made during the design process. A fourth class ofrequirements were identified during the creation of this document that were considered tobe outside the scope of the IMS specification. These requirements are listed in section 4on Implementation.

3.1 GROUP MANAGEMENTGroup Management features organize the membership or enrollment in a group or classand customize what type of information and activities are available to the members of thegroup. A formal example of group management is the process of course design whereprerequisites or enrollment criteria are set, resources are chosen, and the content andactivities for the group are structured. Group formation does not need to always be at thelevel of a course, however, and groups may form on a very ad-hoc and temporary basis.

For formal groups, such as courses offered by a University, a key assumption behind therequirements listed here is that institutions have made large investments in theiradministrative systems. IMS environments should interface with these systems for thepurposes of registering students and recording grades and other student information.



17

3.1.1 Essential Requirements

3.1.1.1 Enable teacher control of offering access: enable teacher to set “prerequisites”among offerings.

3.1.1.2 Variable start and stop of offerings: enable multiple learners to start and endofferings at variable times subject to the provider’s constraints. Users should be able toengage in asynchronous education.

3.1.1.3 Provide timing flexibility: IMS should support variable times for start and end ofofferings.

The introductory accounting offering at the University of Michigan is scheduled to begin at the startof the semester in September; the introductory accounting offering at Xerox University is scheduledto begin on the first Monday after the offering reaches full enrollment.

3.1.1.4 Enable the distinction between an offering and an instance of an offering.George searches Yahoo for Metaphysics courses being offered at accredited Universities. Georgeconnects to the IMS environment at the University of Wisconsin and joins his Philosophy class for theweekly lesson.

3.1.1.5 Allow users to perform searches by location: allow user to confine search toparticular directories or repositories when supported by the search service.

Rachel looks for training development courses offered by the US Military.

3.1.1.6 Enable posting and controlling access to information: IMS implementations mustenable teachers and learners to post information they create for learners and set the accessrights for them.

3.1.1.7 Two-way communication between enrollee and owner: IMS specification willfacilitate two-way communication between an applicant/enrollee and the IMS environmentowner.

John’s application for admission to an IMS offering within the University of Michigan’s IMSenvironment lacks information or certification required for admission. U of M will be able to contactJohn to request the necessary information.



18

3.1.1.8 Interface with existing enrollment information: the IMS specification will providefor interfacing with existing enrollment information (e.g., there are existing specificationsfor transmitting enrollment information such as AACRAO’s SPEEDE ExPRESS).

3.1.1.9 Allow owner to accept or reject enrollment requests: IMS specification will allowIMS environment owner to accept or reject enrollment request for an offering.

3.1.1.10 Interface with administrative systems: transmit enrollment data to studentrecords system.

3.1.1.11 Permit exchange of administrative data: IMS will specify a data format forexchange of data (to and from) with significant existing administrative systems (e.g.,PeopleSoft, SCT Banner, etc.) and standards (e.g., AACRAO EDI).

3.1.1.12 Interface with online library systems.Professor Hardy puts several journals and text from the library on reserve for his students to accessonline.

3.1.1.13 Assign users to groups: IMS specification will enable assignment of users to oneor more groups.

Jon is a student at Williams College majoring in history and music. If the Cornell IMS were toclassify groups of students based on major, Jon would be the member of two groups.

3.1.1.14 Communicate group membership information: the IMS specification will includea format and protocol for communicating group memberships among IMS environments.

The University of Toronto biology dept. strikes a site license deal for biology students. TheUniversity of Toronto IMS will be able to differentiate biology students (eligible for the site license)from those who are not a member of the group (and are, consequently, not eligible for the sitelicense).

3.1.1.15 Enable anonymous participation: allow anonymous participation by any user atthe discretion of whoever is assuming the role of teacher(s).

3.1.1.16 Allow users to switch roles seamlessly.Frank switches between designer status and student status while creating his course in order to viewthings from his students’ perspective.

Kento enters the informal chat room under an alias but when he posts his assignments to thediscussion board, he chooses to use his name as an identifier.

3.1.1.17 Provide instructor status information: in an instructor-led offering, the instructorcan check status of static and dynamic information about the offering (e.g., coursedescription (static), number of students admitted (dynamic)).

3.1.1.18 Provide notification: IMS environment includes notification capabilitiesaccording to a default set of rules.

The University of Colorado IMS is configured to send all notices to users via e-mail and notices aregenerated when work is complete on an offering and when new containers are made available.



19

Washington State University IMS is configured to send notices to users via their personal web pages(i.e., the first page that shows up when a user logs on to the WSU IMS); notices are generated onlywhen new containers are made available.

3.1.1.19 Provide navigation capability: System will allow navigation within and amongcontainers according to whatever sequence has been established by a developer.

George is an instructor and developer. He selects a series of containers for an offering he’spreparing. He specifies a sequence for those containers. Alex is a student in George’s course. Whenhe logs into the IMS at his institution, the offering is presented in the order George specified.

3.1.1.20 Linear sequence default: the default sequence for use of the contents is theorder of the contents.

3.1.1.21 Enable individualized resequencing for progression through an offering:sequencing can be dynamic and individual. Instructor may be able to have a defaultsequence and also tailor sequences to particular learners[kab18].

3.1.2 Secondary Requirements

3.1.2.1 Enable notification: user can specify notification rules including input, criteria(conditions of IMS metadata, and action (notifying who and how)

Instructor Joe establishes a rule saying if the number of students in a class exceeds 15 the systemshould send him an e-mail indicating this status.

3.1.2.2 Enable triggered notifications: enable the existence of a specific state to trigger anotification or an event (such as an assessment or a branch).

Suzie takes a test and scores poorly. The instructor had set a flag for him to be notified if a student’sperformance drops below a certain level. IMS sends a notification to the instructor. The instructorcommunicates with Suzie and modifies some aspect of the course to better meet her needs.

3.1.3 Don’t Preclude

3.1.3.1 Enable non-linear sequences of containers: IMS containers specify how theirinternal containers will be opened in a nonlinear sequence.

3.2 PERSONAL PROFILE MANAGEMENTFeatures of the personal profile relate to how an individual user manages and maintainsrecords of his or her interactions and progress within an IMS environment and with IMScontent. The personal profile consists of user identification information, performancerecords, portfolio work, and preference information that may customize their IMSexperiences.



20


3.2.1.1 A user may have one or more IDs: user must have at least one ID and may havemultiple IDs.

3.2.1.2 Identify users consistently: every user in the system needs to be uniquelyidentifiable in a consistent format and the ID allocation must be scaleable and distributedacross multiple organizations (no single organization controls IDs).

3.2.1.3 IMS will allow a user to self-identify to an IMS system.

3.2.1.4 Track applications: the IMS will track and report information about learners andtheir status in the enrolling/application process.

3.2.1.5 Notify learners: the IMS specification will enable the provider to inform thelearner of the status of an application at each threshold (receipt, support documentcollection and admission decision).

3.2.1.6 Users have access to their own user records.Eric has completed a series of IMS offerings with UNC. He can review the records associated withthose offerings, as well as his general user profile (e.g., name, e-mail address, etc.) at any time.

3.2.1.7 Access to performance information: advisor must have access to the user’sperformance information.

An advisor reviews a student’s grades to determine if the student’s math skills are adequate to pursuestudies in physics.

3.2.1.8 Privacy of performance information: the privacy of performance informationmust be maintained.

A student grants access rights to a specific advisor to review only his mathematics course grades.

3.2.1.9 Enable access to advisory support materials: e.g. student records, universitycatalog, course records, IMS-compliant offerings.

3.2.1.10 Protect personal data: the transmission of personally identifiable information andcredentials must be secure

3.2.1.11 Accumulate user information: user information (profiles, portfolios, certificationrecords, etc.) should accumulate within an environment.

3.2.1.12 User records should be extensible: (e.g., as with metadata, you can add morefields). User data is packaged within a container’s contents.



21


3.2.2.1 Allow user to point to existing IMS profile: IMS will allow a user to specify thelocation of an existing IMS profile.

Arthur has an established IMS profile with UNC, but is interested in registering for a course with theIMS system at Cornell. When registering with Cornell, Arthur can specify the existence and locationof his UNC profile rather than create a profile from scratch.

Note:Arthur can specify the primary location for his records. Any secondary, tertiary, etc. locationsmust submit updates to the primary location. The primary location will update his records based onthe updates they submit. We may use the AACRAO EDI data format standards for transcripts.

3.2.2.2 Permit controlled access to user profiles: The environment will allow learneraccess to the roster/profile of other learners using the system, given permission of otherlearners.

Seventeen learners are enrolled in Physics Tutorial with ITP Learning Services. Among the 17 areWesley, Paul, and Suzanne. Suzanne is a private person and doesn’t want her peers to know that sheis participating in a tutorial; Wesley and Paul are happy to tell people what they’re up to. All threecan see that 17 learners are enrolled, and each can see the names and profiles of learners who havenot blocked their identities from their peers – i.e., all (including Suzanne) can see name and info onWesley and Paul; no learner can see Suzanne.

3.2.2.3 Support multiple locations for user data: when you register at an implementation,you specify a primary location where your user data are held or create a new record. Ifyou reference a primary location, updates to those data will be submitted by thesecondary, tertiary, etc. implementations; the primary location will update the records. (Alllocations will maintain records.)

Jeanne establishes her primary user record and takes an IMS course at the University of Chicago.She then enrolls at the Johns Hopkins IMS and specifies that U of C is her primary record holder. Allresults of her IMS work at Hopkins will be submitted to U of C and U of C will update her records; inaddition, Hopkins will maintain its own records.

3.2.2.4 Personal profiles can be copied by the user: user can keep a duplicate copy oftheir personal profile locally. This profile can be utilized to log on new IMS systems.

Jon has been enrolled in two IMS environments (UNC and CSU) and keeps a copy of his IMSpersonal profile on the hard drive in his Apple PowerBook. When Jon enrolls at University of Iowa,he can complete the application for enrollment process by uploading the data file from his harddrive. (In a case where Jon submits the personal profile to an IMS environment where he had alreadybeen enrolled, the server identifies him as a previous user, updates his records if necessary, and useshis server-based profile.

3.3 ACTIVITY MANAGEMENTActivity Management features facilitate how the user actually engages with the IMSenvironment. Whereas Group Management features establish the parameters of anabstract interaction, the Activity Management features manage the implementation orspecific instance of this interaction (i.e. the difference between the syllabus description andthe actual class session). The Activity Management features also address communicationand collaborative activities between users.



22


3.3.1.1 Seamless transitions between offerings and services: ability of one or more usersto move easily between various offerings and services in the IMS environment. A“seamless transition” implies the smooth transition of program behavior during transitionfrom one container to the next, or one procedure to the next. Seamless does not refer tothe appearance or behavior of the user interface.

A student has finished a module from Bear Publishing Company and clicks on the task bar to move tothe next module provided by Lunar Technologies. Each company’s logo identifies the module’ssource.

3.3.1.2 Enable dynamic resequencing.

3.3.1.3 Enable self-paced progression: allow learners to control their progress throughmaterials at paces they set within the limits set by the teacher.

3.3.1.4 Enable a log history of the user’s progress across containers: IMS environmentcan record event information to enable learners to review their path among containers(how they got where they are), completion state (how much of the offering they haveencountered), performance (assessment reports), and collaboration (evidence ofinteractions with other learners). Retracing the path among containers constitutesbackward navigation.

3.3.1.5 Enable system marks: enable the learner to mark where he or she wants to returnto within an IMS system . This enables learners to leave the system and return to the samepoint in the system (bookmark).

A learner closes down his or her computer having partially completed a list of questions on anassignment. When the learner logs back onto the IMS compliant environment, the user’s position inthe list is restored. Because the system also tracks and records the user’s progress, the answerscompleted thus far by the user are also presented.

3.3.1.6 Track usage in standard format: IMS implementation will track usage (i.e., # ofretrievals, person retrieving, date and time, transaction ID) of containers in a standardformat.

3.3.1.7 Enable the recording of advice.A learner accesses the record of an advising session to help recall strengths and weaknesses whendeciding an elective course to take.

An advisor accesses the record of a previous advising session in preparation for another meetingwith the same learner.

3.3.1.8 Enable teacher to track anonymous users: when a user has assumed anonymity,their activity may or may not be tracked at the discretion of the person assuming the roleof the teacher.

3.3.1.9 Enable rapid interactions between users within the IMS Environment: allow theadvisor and the advisee to exchange information quickly within the IMS environment.

An advisor assembles a note with electronic clippings from the course catalogue and information ona professor into a container which is sent to a student.



23

3.3.1.10 Support synchronous and asynchronous communication: IMS supports bothsynchronous and asynchronous interactions among individual users and groups (one-to-one, one-to-many).

Synchronous— Enable multiple learners to access a given container and interact with one anotherwithin a container at the same time. Users should be able to explore offerings together in asynchronous manner.

Asynchronous--- Multiple learners should be able to access a given container and interact with oneanother through asynchronous forms of communication such as bulletin boards, listservs, email, peerreview of each other’s work, etc.

3.3.1.11 Enable communications among users: learner needs ability to communicate withother learners, instructors, experts in the field and other collaborators.

A learner requests clarification of an assignment by a teacher. The teacher responds with acontainer which contains a message and an example.


3.3.2.1 Record event and path information within containers: an IMS compliantenvironment can record event and path information within containers.

3.4 ASSESSMENT AND CERTIFICATION MANAGEMENTThe management of assessment and certification entails tracking, reporting, and recordinginformation about a user’s progress and performance. Both assessment and certificationactivities may take place either within an IMS environment or outside an IMSenvironment. The requirements listed here address how assessment or certificationinformation travels within or between IMS environments.3.4.1 Essential Requirements

3.4.1.1 Enable storage and retrieval of assessment data: the individual performing theassessment should have the ability to record the assessment data. Assessment data can beof various types and of variable length (e.g. numeric, alpha-numeric, variable length text).

The performance of a learner on a normed test, or a written critique, or an evaluation form.

3.4.1.2 Enable storage and retrieval of learner’s progress: enable the storing andretrieving of learner’s progress across containers.

Professor Lopez can monitor her students progress, as individuals and as a group, via progressreports sent to her regarding participation/completion information of each module and the students’scores determined through various assessment instruments.

Professor June retrieves a learner’s progress record to see where they are in the course offering andhow much time they have spent doing various assignments. She uses this to evaluate areas ofdifficulty for the learner.

Kym takes a self-assessment test in an online course to determine what section of the course sheshould progress to next.

Students conduct a peer review of each other’s work on an assignment completed at the end of agroup project.



24

3.4.1.3 Enable containers to hold only assessment tools: enable creation and connectionof containers that hold only assessment tools.

The Educational Testing Service creates an IMS compliant pre-test for the SAT

A psychology professor creates a Learning Style self-test to help the learner identify strategies workbest for her.

3.4.1.4 Enable assessment tracking and reporting: track and report assessment for anindividual and/or a group.

The instructor or learner can print out a summary of the learner’s assessments for the course. Alearner or teacher can print out a summary of the assessments of the teacher in teaching this course.

3.4.1.5 Assessment may occur without IMS supported learning being involved.

3.4.1.6 Provide certification token format: the IMS specification will include a format fora certification token that will be appended to a user’s profile upon completion of anoffering.

Rob successfully completes an introductory French offering on the University of Iowa IMS. Uponcompletion, a “token” is added to his profile indicating that he has completed the offeringsuccessfully.


3.4.2.1 Enable reporting for institutional assessment: enable assessment tracking andreporting data to be aggregated in reports for institutional assessment (such as regionalaccreditation). Such data may include: Number and characteristics of people attemptingand completing an offering; Success ratings of completion; Time required for thosecompleting offering; Aggregation of offerings used in an institution as a list withdescriptions.

3.4.2.2 Provide consistent scaling of numerical data: IMS will provide consistent scalingfor numeric data by recording results within a range of 0-100. If the assessment value isrecorded numerically, the correlation among assessment tools is enabled[kab58].


3.4.3.1 Enable diagnostic assessment: enable pre-assessment measures to determine whatthe learner knows and what the learner needs to know (diagnostic assessment).

3.5 CONTENT MANAGEMENTContent Management features embody requirements for the creation and use of learningmaterials and tools for individuals and groups. The bulk of these requirements address theneed for metadata in order to label content and determine what a user may or may not dowith this requirement. In IMS terminology, content is wrapped in an IMS container; i.e.all of the elements within a container have some relationship to each other and are offeredas a whole.

Two important assumptions regarding the development of content is that users will be ableto create content with standard authoring tools and the ease in making this content IMS



25

compliant is an important consideration for the success of IMS. As for the evolution ofmetadata, the specification assumes that a base standardized vocabulary is important forinitial use, but these fields and values will be further refined as the market determines.


3.5.1.1 Provide functions to create/manipulate containers: IMS environment containscallable function to create a container, insert fields in a container, and set values within afield.

3.5.1.2 Permit multiple versions: IMS environments must allow multiple versions of thesame container to exist in the same implementation simultaneously.

An offering for introductory astronomy is available in time for the 1996 school year. In early 1997, anew version is released. The University of Michigan wants to make the new version available on itsIMS, but does not want to replace the 1996 version – since it may still be in use by some classes.

3.5.1.3 IMS container IDs are created by IMS implementations as needed: The creationand assignment of IMS IDs as metadata to a container is transparent to the user.

3.5.1.4 Containers are responsible for the sequencing of their contents: IMS containersspecify the order in which their internal containers will be opened.

The sequence of internal containers may be linear, random, or altered based on user input andprocedures with the container.

3.5.1.5 Non-IMS external references can be used: users are free to reference (link to)content and environments that are not IMS compliant. (e.g. could include a URL)

A user clicks on a reference within an IMS compliant application and links to a non-IMS compliantweb page.

Student is completing an on-line IMS course, he goes outside the course to research a topic. Whenhe identifies the best instances of additional information (e.g., on the web, digital library or a CD),he creates links or references in the IMS environment that he and other colleagues can use.

A user clicks on a button and runs a Hypercard application from the local hard disk.

3.5.1.6 Containers can be created without entering metadata values: A container mustcontain fields for metadata, but it can be made on the fly without any input of the metadatavalues. These containers are non-IMS compliant.

A developer is using an authoring tool to complete the second version of a working prototype of anapplication. She containerizes the prototype so she can test it “off line” without having to enter allthe metadata necessary to make it IMS compliant.

3.5.1.7 Provide packaging method: the IMS specification will establish a method forpackaging to enter at least the minimum required metadata and to make something IMScompliant.

3.5.1.8 Ensure uniqueness of identity for IMS compliant containers: IMS containersfrom various providers and organizations must be uniquely identifiable. While this mayrequire one or more Issuer ID Registries to register the IMS ID issuer component of the



26

composite IMS ID (cf. Ethernet hard address vendor registration), other solutions areencouraged [kab67] .

Omicron Registration Services along with 4 other companies have been selected by the IMS Projectto become IMS ID registry services. XYZ Corporation, who is developing an IMS environmentproduct, contacts Omicron and receives an IMS ID Issuer ID. XYZ uses their IMS Issuer ID alongwith a unique serial number as the complete IMS ID for each copy of their IMS environment that theysell.

3.5.1.9 Offering profile data is required.

3.5.1.10 Metadata is organized in fields: the user may search for IMS compliantcontainers by categories (keywords, objectives, subject, learning style) and criteria(timeinvolved, payment method, brand type of materials).

3.5.1.11 There is a minimum set of metadata fields for every metadata record.

3.5.1.12 Enable standardized and non-standardized terms for metadata: Indexingmaterials and services may occur through a standardized or non-standardized vocabulary.

3.5.1.13 All metadata is publicly accessible for browsing by non-proprietary searchengines: The user must be able to view all the public/browsable IMS metadata for acontainer.

3.5.1.14 Metadata format is public knowledge: enable access to information about anoffering through consistent formats.

3.5.1.15 Provide content descriptors: every container has a content descriptor (text) thatdescribes the content of the container. The content descriptor is part of the metadata.

3.5.1.16 All containers have a current version date.

3.5.1.17 Provide information for users’ special needs: offerings that accommodate users’special needs should indicate relevant information. Provide information about the deliveryof educational offerings that is of value for users with special needs.

A learner with limited sight may be searching for offerings with an audio mode or enlarged displaymode.

3.5.1.18 Indicate display requirements: metadata must include sufficient information toallow appropriate display of an element on the client machine given that the client hasappropriate software installed.

An offering includes a TIFF image as an element. The environment will communicate the presence ofthe TIFF to the client machine and, provided that a TIFF viewer is present on the client machine, theTIFF will be viewable.



27

3.5.1.19 Provide element lists: an IMS container can include a list of authentic or primaryelements (i.e. ones that are not containerized) with their associated copyrights andownership information.

3.5.1.20 Allow for extensibility of metadata: (e.g., additional metadata fields may beadded at a later date; the length of metadata fields may be extended at a later date).Publishers and institutions may have their own metadata fields that they wish to have.

3.5.1.21 Field content types are extensible: the field types are extensible and a method ofidentifying those field types will be defined in an extensible way (e.g., much as additionalMIME types can be added within a browser).

3.5.1.22 Enable the ability to search non-textual databases in an appropriate manner.Sylvia finds a picture of the Mona Lisa and submits it to her favorite search engine with the requestto “find more pictures like this.”

3.5.1.23 Enable the ability to search within a container: Enable the ability to searchwithin a container and/or to extract information from a container (e.g. searching byMIME type or by key words).

Dr. Shumaker purchases an offering for his students on pediatric anesthesiology. He searches thecontainer for relevant and important terms that he indexes and links to a glossary supplied by theAmerican Association of Pediatrics.

3.5.1.24 Enable the creation of run-time and design-time containers: Run-time containerswill have set properties and design-time containers with open properties.

3.5.1.25 Aggregation of containers: a container’s ability to be aggregated is determinedand specified by the developer (or owner) of the container. A container with theaggregation ability can be placed into another container.

Professor Xavier created a simulation container that allows students to conduct an archaeologicaldig. He has allowed the container to be aggregated (included) by anyone creating educationalcourses.

3.5.1.26 Disaggregation ability of containers: a container’s ability to be disaggregated isdetermined and specified by the developer (or owner) of the container. A container withthe disaggregation ability can be separated into different containers (generally for use inother containers).

Professor Xavier’s archaeological simulation container (see above) has several image containerswithin it. He has specified that these image containers cannot be disaggregated (used separately)from his entire simulation container.

3.5.1.27 Re-sequencing ability of containers: a container’s ability to be sequenced isdetermined and specified by the developer of the container. A container withresequencing ability allows its internal containers to be reordered and/or excluded.

Professor Xavier (see above) allows the user of his archaeological simulation container to determinein what order they will encounter various images.



28

3.5.1.28 Redistribution ability of containers: a container’s ability to be redistributed isdetermined and specified by the developer of the container. A container withredistribution ability may be taken by someone other than the developer and distributed toother developers.

Professor Xavier (see above) has disabled the redistribution feature of his archaeological simulationcontainer; therefore, other people can use and/or aggregate the simulation container, but theycannot redistribute it to other developers.


3.5.2.1 Enable preview function: IMS specification enables access (previewfunctionality) to the contents of the container. Owner may specify variable access to thepreview functionality.

An instructor who has a special pre-release agreement with a publishing company is able to browseofferings not available to the general public.

An instructor whose institution has a special licensing agreement with a provider can view differentpricing information about offerings than others.

3.5.2.2 Preview function controlled by provider: The content provider determinesresponse to a preview request.

User asks for a preview and gets a page of text and graphics explaining the offering in more detai, ora limited function version to try out, or a video about the offering.

3.5.2.3 Enable parental control tags: IMS will enable tagging of data to permit parentalcontrol of access (current and future standards for parental control standards.)

3.5.2.4 Permit copying of containers: a user may copy a container from one IMSenvironment to another as permitted by the owner of the container.

3.5.2.5 Enable developers to export any data in IMS compliant containers: Containerscan create their own IMS-compliant metadata containers that are extensible andunspecified by IMS.

ETS establishes an IMS container format for SAT results: date, ETS public key, score, location, etc.If ETS publishes the format, institutions might then query the container for the contents of the scorefield.

3.5.2.6 System must maintain a linkage between versions of the same container.A 1996 and 1997 version of an offering on how to prepare corporate income tax returns areavailable. It should be clear that these are two versions of an offering, rather than discrete andunrelated offerings

3.6 COMMERCE AND LICENSING MANAGEMENTCommerce and Licensing features are supported by requirements concerning thedistribution and use of content and/or the provision of services. The transactions that takeplace may result in costs for the user or the content/services may be free of charge. Therequirements below facilitate the consumer’s decision whether or not to engage in a



29

financial transaction and also facilitate the developer’s ability to track the usage ofcontent/services.

A core assumption of the requirements listed below is that educational organizations andcontent distribution companies have a large investment in their administrative systems thatsupport business transactions. Therefore, IMS implementations should provide aninterface for these systems in order to complete transactions.


3.6.1.1 IMS specification will allow for transfer of ownership of a container.

3.6.1.2 Only IMS compliant containers are distributable.Dr. Allen browses a collection of IMS containers. He retrieves a container and it is transferred intohis IMS environment where he can then begin working with it to incorporate into his course.

3.6.1.3 Transactions are not required to browse container metadata.XYZ Publishing maintains an IMS environment accessible via the public Internet and all visitors canbrowse through their offerings looking at title descriptions, etc. Orion Business Research Corp.maintains an IMS environment that only subscribers have access to. Orion subscribers pay foraccess to the Orion site where they can then browse without paying a fee.

3.6.1.4 Browsing can be done without an IMS user profile ID.

3.6.1.5 Support transactions for IMS compliant containers: only IMS compliantcontainers can be transacted within and between IMS environments.

IMS will not recognize a standalone web page or a standalone GIF image as something that can betransacted.

3.6.1.6 Specify transaction data formats: IMS will specify a data format for transactioninformation to and from a hosting organization.

3.6.1.7 Interface with back-office solutions: develop the IMS specification to interfacewith a gateway to existing back-office solutions (royalties, copyright, accounting, etc.)

3.6.1.8 Control financial behavior or container: Financial behavior of a container cannotbe changed by the aggregator or the user, but can be changed by the owner.

ITP owns a container which is aggregated into a larger offering by a another publishing company.The container from ITP that the second company aggregates retains the financial behavior (i.e., cost,payment rules, etc.) that they had previously. (NB: If the second company is looking for a containerwith different financial behavior, and can reach agreement with ITP, one could be createdspecifically.

3.6.1.9 The owner can specify the level of permitted aggregation/disaggregation.ITP can indicate that a container that it owns can or cannot be aggregated. ITP can also specifywhether a container that it owns can or cannot be disaggregated.



30

3.6.1.10 Provide a “time to live” capability: “time to live” metadata item of a containercan be overridden on a per transaction basis based on the terms of purchase between userand the hosting organization.

John buys an IMS offering for his Astronomy 101 course. The offering has a “time to live” settingthat will grant access for the current semester. The hosting organization can change the terms andgrant access for a different period of time – either longer or shorter.

3.6.1.11 Provide start/stop dates: Transactions may include start and/or stop dates thatdetermine a window of time during which a user can access to an offering.

3.6.1.12 Calculate aggregate costs: enable the aggregation of total cost for an offering(e.g., as a hosting organization assembles an offering, the environment will calculate thesum of the costs of each container in the offering; the hosting organization can use this asthe price for the offering, or set a different price).

3.6.1.13 Provide information about terms and conditions: IMS hosting organization willinform the user of payment, terms, and refund policy when the user makes the purchasedecision.

Philip buys an offering from the ITP IMS. At the time he makes his purchase decision, ITP willinform him of payment, terms, and refund policy.

3.6.1.14 Check if aggregation permitted: the IMS specification should allow aggregatorsto ascertain if the copyright holder permits aggregation.

3.6.1.15 Provide aggregation metadata elements: since the following information must besubmitted with an aggregation request, metadata elements for aggregation should include:what is the source project, author, publisher, title, ISBN, edition, exactly what material iswanted, which affiliations(s) will use the materials?, what is the maximum number ofcopies to be made available, period of time for use (term), what percentage does thisrepresent of the whole project.

3.6.1.16 Permit fee for service and/or fee for material: IMS specification will permit feesfor service (e.g., browsing) and fees for material (e.g., content).

Note: A hosting organization may choose to charge fees for service, fees for material, both, orneither

3.6.1.17 Handle different payment methods: multiple payment methods are stored in theuser profile. User can specify which payment method he/she wants to utilize with eachtransaction, though a default method of payment may be specified in an environment.

David’s profile includes a VISA credit card, national learning subsidies (learning stamps), financialaid, cash, and other payment methods. The hosting organization will determine which forms ofpayment are acceptable and will be handled by the institution in their normal manner.

3.6.1.18 Enable transactions at different points: Points of transaction (costs) may occurat either the use level, access level, or aggregation level.

Billy gets charged for the cost of all the nested containers because he access to the parent containerrather than getting charged individually as he uses them



31

Johnny only pays for the containers he actually opens within the course offering, because this is howthe offering has been packaged.

3.6.1.19 Enable affiliated and nonaffiliated electronic transactions.College of Bill and Mary pays for unlimited access for all its students to the offerings of EPCcorporation.

John pays for access to an offering that he wants to use on his own system at home.

3.6.1.20 Confirm transactions: user will be prompted to confirm or reject a transaction.A dialog box is displayed before a Jon’s account is charged for an offering asking him to confirm thetransaction.

3.6.1.21 Financial transactions can be canceled only while they are pending.Jennifer selects a writing offering from the ITP IMS and indicates that she would like to pay bycheck. Her transaction status is “pending” since payment has not yet been confirmed. She will havethe option of canceling the transaction until such time as it is confirmed. After the transaction hasbeen confirmed, any cancellation is subject to direct contact between Jennifer and ITP.

3.6.1.22 Access to content may be granted in any state of transaction: to be determinedby the content owner.

ITP is a company that offers its customers access to its offerings within an IMS environment onces/he indicates an interest in purchase (i.e., the transaction is pending) and, of course, after thetransaction has been confirmed; Faulkner Publishing (fictional) requires payment to be confirmedbefore access is granted to its offerings within an IMS environment.

3.6.1.23 Permit secure/insecure communications: any type of communications in the IMSsystem may be secure or may not be secure at the discretion of either party in thetransaction.

Jamie buys an offering from ITP. ITP specifies that the containers must be exchanged in anencrypted form.

Scott purchases an IMS offering from UNC using a credit card. Scott specifies that his credit cardnumber be transmitted in encrypted form.

Elizabeth chooses CSU as her IMS provider. She submits tuition payment information to CSU but isnot concerned about security.

3.6.1.24 Enable instantaneous/deferred transactions: IMS environment will supporttransactions that are processed instantaneously and those that are processed non-instantaneously (e.g., off-line approval aggregation process, paying by check).

3.6.1.25 Default price of a container is “free”.

3.6.1.26 Pricing may be static or dynamic. Professor White searches for online manuals for his course. He finds some materials from BrightLight Publishing that are listed at $20.00. At a separate publishers’ site, when he searches formaterials, he is asked to submit a form identifying his institution before a price is generated andreturned.



32


3.6.2.1 IMS will track and report information about transactions: (e.g., usage statistics,payment method). This information must be kept under access control.

3.6.2.2 Permit verification of licensing compliance: all transactions must be logged in away that will allow verification of compliance with agreements regarding licenses

3.6.2.3 Specify confirmation preference: User can specify whether or not they will beprompted to confirm or reject before a transaction. (e.g., dialog box).

3.6.2.4 Each transaction of a multi-party transaction is tracked separately.Kevin clicks on a link on a web page within the University of Delaware IMS, but the link is formaterial hosted by ITP. The transaction between U of D and ITP is tracked separately from thetransaction between U of D and Kevin.


3.6.3.1 Personal transaction history should be accessible by the user.

3.6.3.2 Automatically identify applicable discounts: The IMS data format for transactionswill include enough information such that the IMS hosting organization’s systems canautomatically determine any special discounts that may be valid for the user.

Kirsten, a biology student, is working on her class assignment on the Web. She clicks on a link thatrefers to a collection of biology web pages and Java applets on XYZ Publishing Corp.’s IMSenvironment. Because Kirsten’s biology department has a site license for the module in question,Kirsten is not charged individually for access to the module.

3.7 SECURITY MANAGEMENTThe security features of IMS are supported by requirements for identification,authentication, and authorization; i.e. the access controls (rights and privileges) for joiningan IMS environment or using IMS resources. The requirements for security pervade allthe other feature sets as well, but for organizational purposes, they have been listed hereas a separate group.3.7.1 Essential Requirements:

3.7.1.1 Secure synchronous and asynchronous communications: secure synchronous andasynchronous communications must be available.

A teacher advises a student in a text message. The message can only be accessed by the student.

3.7.1.2 Enable control for varied data access: allow the owner of information todetermine who has access to how much of this information and what can be done with thisinformation by whom.

John is applying for a job and is concerned that he may be viewed as over qualified. John makesonly a subset of his certifications viewable by the company to which he is applying.



33

3.7.1.3 Support multiple container access rules: support multiple rules of containeraccess (browse, modify, read, create, copy, and destroy) based on user.

A learner can only use a container, and cannot modify it.

3.7.1.4 Access rights for metadata and the contents of containers are separate.XYZ Publishing allows browsing descriptive information of all of its IMS-compliant offerings, butrestricts users ability to get copies of the offerings to those that have subscribed to their service.

3.7.1.5 Access control for data items: Data items will be under read and write accesscontrol through an IMS environment programmatic interface.

3.7.1.6 IMS will adhere to accessing rules set within the system.Within the University of Maryland IMS, Jonathan (a student) has access to offerings only for hiscoursework. Mary, an instructor at Maryland, has access to all offerings.

3.7.1.7 Provide authorization and authentication: IMS will enable authorization andauthentication for both individuals and for group membership .

A provider of offerings ensures that a learner requesting an offering is who he or she says he or sheis, and that the learner is authorized to use the offering as a student affiliated with a particularuniversity.

3.7.1.8 Support bi-directional authentication: the system will support mutualauthentication between sender and receiver.

3.7.1.9 Maintain authentication state: the IMS specification will allow the user tonavigate among containers within an environment without being re-prompted forauthentication information.

Geoff works through an IMS offering composed of multiple containers within a single IMSenvironment. He is prompted for user ID and password when he first connects to the system, but he isnot prompted for user ID and password when moving from one container to another. (Theenvironment may force a timeout period after which Geoff would be re-prompted).


3.7.2.1 Support extensible rules of container access: enable the creation and use of rules,simple to complex conditions, to be used in determining if a user can access a container.

Professor Jones establishes an access rule that allows only students who have progressed through50% of the course material and have a better than 80% average on their assessment results to accessa collection of advanced materials.

3.8 TECHNICAL ADMINISTRATION MANAGEMENTThe Technical Management features are supported by requirements that address theoverall infrastructure or architecture of IMS environments and content. Similar to therequirements for Security, the requirements listed here pervade all of the feature sets ofIMS.



34

3.8.1 Essential Requirements:

3.8.1.1 Support Existing Standards: the IMS specification will incorporate existingindustry and formal standards, when applicable.

3.8.1.2 Internet Standards: the IMS Specification will be based on Internet protocols,standards, and formats, where applicable[kab133].

3.8.1.3 Internet protocols between IMS environment and clients: use standard Internetprotocols for data transfer between IMS environment and clients.

3.8.1.4 IMS defined protocols between IMS environments: IMS will define a protocolfor data transfer between IMS environments; this protocol or protocols may be differentfrom those used for data transfer between IMS environments and clients.

3.8.1.5 IMS protocol to make metadata readable: IMS will establish a protocol formaking the metadata on containers readable (and therefore searchable) in ASCII by searchengines.

John uses AltaVista to search the web for learning resources. IMS containers containing metadatamatching his search criteria that reside on public web servers are included in the results set.

3.8.1.6 Enable Data Storage Interface: the IMS Specification will enable implementationsto define how they perform data storage and retrieval[kab137].

3.8.1.7 Allow for varied computing models: the IMS Specification will allow for IMScommunication to occur irrespective of a particular computing model [kab138].

Two IMS-compliant containers may communicate with each other on a client and then transmit databack to a server. An IMS environment may distribute part of its functionality to client machines andto intervening systems for load balancing.

3.8.1.8 Enable local host implementations: IMS specification enables local host (i.e., onecomputer acts as both environment and client) implementations of environments.

3.8.1.9 Allow intranet-based implementations: IMS specification enables intranet-based(i.e., not Internet connected) implementations of environments.

3.8.1.10 Containers can contain any type of data: developers of IMS containers canincorporate any data or executable as the contents of a container, including applicationsfrom legacy software that may or may not require additional software on a user’s system.The metadata for such containers must identify the type of data.

If an author were to use a Quicktime movie in a container, then the metadata would includeinformation to enable a user’s Web browser (for example) to launch an appropriate helperapplication or plug-in.



35

3.8.1.11 Enable scaleable implementations: the IMS Specification will enable scaleableimplementations. Scaleability implies but is not limited to avoiding centralized repositoriesfor critical elements required for IMS compliance. However, a registry for ID issuer ispresumed (see other requirements in this section [kab142]).

3.8.1.12 Facilitate creation of IMS certification services .The IMS Project works with Software Testing Services, Inc. to establish a certification service thatprovides for 3rd party certification of IMS environments and containers.

3.8.1.13 Multilingual Implementations: the design of the IMS specification will enable thedevelopment of multilingual IMS environment implementations.

3.8.1.14 Each IMS environment will have its own ID: each IMS environment ID iscomposed of the Issuer ID and some issuer designated value (e.g., a Serial Number).

3.8.1.15 Allow alphanumeric name associations with IMS environment ID: IMSimplementations can be named and the name can be different from the unique environmentID (e.g. DNS system for IP addresses)

3.8.1.16 Provide consistent ID format: every entity in the system needs to be identified ina consistent format and the ID allocation must be scaleable and distributed across multipleorganizations (no single organization controls IDs).

3.8.1.17 Provide unique IDs: there will be a standard composite ID format that willcreate a globally unique IMS ID for people, containers, organizations, etc.

3.8.1.18 Use composite IDs to ensure uniqueness: the composite nature of all IMS IDsreflects a method of assigning a unique ID and does not necessarily reflect any meaning(e.g. location, organization, etc.)

3.8.1.19 Define standard error messages: IMS specification will define a minimum set oferror codes and associated messages.

3.8.1.20 Provide error-handling/propagation capability: IMS specification will include amessage protocol for modules to communicate errors which can be handled by themodules themselves. If the message is not understood by the module, it is passed up as avalue and text to the next container level(s) and ultimately the environment level.

3.8.1.21 Display error messages: IMS environment will display error messages passed toit from containers; a default will be displayed if no text message is available.

An error code is received by the environment that is unknown to the environment; a generic error isdisplayed.



36


3.8.2.1 Develop a set of procedures that describe how to test for IMS compliance. TheIMS specification itself will be the basis for determining IMS compliance in the absence offormal test procedures. Test procedures would be developed after the initial release of thespecification; a tool to automate the test procedures may be developed at a later date.

3.9 SUMMARY OF REQUIREMENTSThe organization of requirements by feature sets was motivated by two objectives: 1) toplace the requirements in the overall context of a functional learning system, and 2) tojuxtapose like requirements in order to draw out the nuances of each requirement while, atthe same time, contributing to a general understanding of the feature set’s intendedfunctionality.

Like most systems of classification, however, the requirements and the implied features donot fall cleanly into separate and discrete categories. In fact, there is considerable overlapand dependencies among the different requirements. The diagram below attempts tooutline some of the most important connections between the requirements of the differentfeature sets.

FIGURE 11: INTER-RELATED REQUIREMENTS

The above diagram depicts three important points regarding the inter-relationship betweenthe feature sets used to organize the requirements. First of all, the technical requirementsact as a framework or infrastructure for holding all the requirements together. Technicaladministration management requirements, such as using existing protocols or supportingmultiple data types, affect all of the requirements. The second important point from the



37

diagram is the centrality of the Group management requirements. This centrality is adesign principle that will be discussed more in the next section. Finally, the depiction ofthe feature sets as modular parts reiterates the scalability and interoperability of IMScompliant resources.

IMS Project Requirements Implementation and Design Rationale


38

4. Implementation and Design RationaleThe requirements from the previous section represent a type of “wish list” generated byusers and developers of online learning resources. These requirements will serve as anoutline of the functionality the IMS specification must enable. The requirements and theresulting specification are guidelines for making resources that are IMS compliant. IMScompliance ensures a level of interoperability and a level of support for essential learninginterchanges.

The IMS specification, however, only defines formats and protocols for interchanges thatoccur within or interface with an IMS environment. The specification does not prescribehow developers must implement the base functionality that is required. This opennessleaves room for innovation and the creation of additional requirements that will add valueto the basic IMS framework.

The IMS project recognizes the need to implement its requirements and specification inorder to refine the specification as well as provide a real-world example of thespecification in action. The IMS prototype is not the definitive way to implement thespecification but will embody best-practice approaches in technical development andpedagogical design.

The diagram below depicts how the IMS requirements feed into the specification which inturn result in an implementation. The IMS prototype is one implementation and itscreation will elicit more requirements as well as refine the specification.

FIGURE 12: PROJECT DEVELOPMENT

4.1 RECOMMENDED REQUIREMENTSThe IMS prototype is one implementation of the IMS specification and requirements.Other developers and providers may implement the IMS specification in completelydifferent ways and add more functionality through additional features. As long as animplementation supports the base level of functionality prescribed in the specification, itwill be an IMS implementation.



39

During the IMS requirements formulation meeting and during subsequent focus groupmeeings, a number of requirements were articulated that were considered importantfeatures of learning resources. These requirements were identified as desirablecomponents, but not necessarily essential core components, for IMS offerings andenvironments. This is not a conclusive list but suggests some of the features that will addvalue to the online learning experience. For this reason, they are recommendedrequirements for IMS implementations and will most likely be addressed by the IMSprototype.

4.1.1 GROUP MANAGEMENT

4.1.1.1 Support web-based enrollment.

4.1.1.2 Enable on the fly customization of group tools, content, and membership.

4.1.2 PERSONAL PROFILE MANAGEMENT

4.1.2.1 The IMS specification will require modules to read user profile information fromthe environment.

4.1.2.2 Search arguments might be stored (for example in a profile) by intelligent searchengines.

4.1.2.3 Enable browsing based on another person’s profile with their permissionReference librarian searching for a patron

Job counselor searching for a customer.

4.1.3 ACTIVITY MANAGEMENT

4.1.3.1 An IMS environment will avoid redundant data entry. If information has beenentered into the system, the system will use this information as a default value.

In the University of Michigan’s IMS environment, students identify themselves by their personal IDnumber and password. The individual course material is now personalized based on theirregistration records.

4.1.4 ASSESSMENT AND CERTIFICATION MANAGEMENT

4.1.4.1 Course evaluations can be sent to the teacher, or institution, or whomever.

4.1.5 CONTENT MANAGEMENT

4.1.5.1 Develop a tool to apply IMS metadata and package the container or containers asan offering.

An IMS metadata tool or content packaging tool may allow a content developer to answer a series ofquestions, specifying the values for metadata fields, and then package the offering.



40

4.1.5.2 Users should be able to view the name of both the content creator and contentprovider.

4.1.5.3 An IMS offering should be able to provide information about references (links) toother offerings.

4.1.6 COMMERCE AND LICENSING MANAGEMENT

4.1.6.1 Modules may have different payment schemes from different providers and fordifferent users or group of users.

4.1.6.2 The system must enable transaction rules that enable and differentiate byaffiliated, unaffiliated, and individual and group entities.

4.1.6.3 There will be a standard templates for charging/licensing models.

4.1.6.4 Containers can be offered from multiple entities each with their own transactionschedule.

4.1.6.5 Containers hold a reference to an entity that contains transaction schedules forthat object.

4.1.6.6 The IMS specification will enable institutions and content providers to establish aset of site license agreements for modules. The hosting organization is responsible formaintaining its customer relationships and using that information within the IMStransaction process.

Columbia University purchases a site license for an American history offering from a contentprovider. Under the terms of the license, Columbia can make the offering available at no additionalcost to any user of its IMS environment.

4.1.7 SECURITY MANAGEMENT

4.1.7.1 Enable single log-in.

4.1.8 TECHNICAL ADMINISTRATION MANAGEMENT

4.1.8.1 Develop a tool to automatically test for IMS compliance.

4.1.8.2 Develop a tool to test the compliance of gateways and ensure that data isexchanged between IMS environments and other systems effectively.

4.2 ISSUES AND APPROACHES

As the development team of the IMS project began translating the IMS requirements intospecifications and began implementing these specifications in the shape of a prototype, anumber of issues arose. These issues will most likely need to be addressed by anydeveloper of IMS materials and environments. Therefore, we will identify some of therecurring issues or questions and possible strategies or rationale for addressing them.



41

GENERAL

The IMS Specification is being developed based on a conceptual object model. In order tosupport a distributed system of interoperable parts, the object modelprovides the most flexibility and extensibility. Many existing systems, however,such asregistrar systems, are not built on an object model. Therefore, the specificationwill be sensitive to both the existing and evolving context and needs of online learningresources.

The IMS Specification is language independent. The IMS Prototype is being writtenprimarily in Java. However, some utilities that enhance interoperability are beingdeveloped in C++. In addition, the IMS Specification will include guidance and samplesfor utilizing IMS features in a pure HTML browser environment.

Any developer who uses the IMS Specifications for directing the development of learningresources can claim IMS-compliance. Certification of IMS-compliance,however, is granted by an outside party. The National Institute of Standards andTechnology (NIST)will identify the vendors who can provide certification services.

IMS member organizations have committed to the use and/or development of IMS-compliant products. In addition, the IMS project has a developers' networkprogram that continues to add more members interested in creating and servicing IMS-compliant tools, systems, and content. Some organizations, including thosenot formally in the developer program, have already begun to use one aspect of the IMSspecification by adding the appropriate IMS metadata to their learningresources.

IMS INTERFACESIn order to begin addressing all the feature sets and their respective requirements (seeprevious chapter), the IMS technical development team has broken down the specificationand prototype work into five inter-related parts represented by the diagram below. Theseparts represent groups of interfaces and the resulting functionality that the specificationwill enable.



42

FIGURE 13: INTEGRATED IMS INTERFACES

The feature sets used to organize the requirements in the preceding chapter do not mapdirectly into the five interface categories of metadata, content, management, profiles, andexternal interfaces. Rather, the implementation of different features is supported byvarious combinations of these interfaces. Each of these interfaces is discussed below andissues raised regarding their implementation. This is not an exhaustive discussion of all therelevant issues, but merely highlights those issues that have been raised repeatedly by IMSpartners, developers, and/or other interested parties.

4.2.1 Metadata

DescriptionMetadata is descriptive information about learning resources for the purpose of finding,managing, and using these resources more effectively. The IMS metadata dictionary,currently available at http://www.imsproject.org/metadata/mddictionary.html, identifiesthe fields and their corresponding values necessary for creating IMS compliant resources.IssuesIn order to be useful across a wide community of users, there needs to be a standard corevocabulary for the fields and values used to describe learning resources. The IMS projectmetadata is derived from existing efforts to define these fields and values appropriately foreducational materials. In particular, the IMS metadata is based on the work from theDublin Core metadata initiative. The IMS project will continue to work with variousorganizations pursuing a metadata standard in order to create a common specification forlearning resources.

Although standardization across terms is necessary for breadth of applicability, it is alsoimportant to allow individual communities to create descriptors that are specific andsensitive to the communities’ unique needs. Therefore, in order to be responsive to thechanging needs of different user communities, the IMS project is working with theNational Institute of Standards and Technology (NIST) to develop a process forautonomous use of metadata and also for the evolution of the core IMS metadata set.

As for development issues, one of the core objectives of the IMS project is to reduce thedevelopment time needed for creating learningware. If adding the requisite metadatabecomes too burdensome, then we have defeated this objective. In order to facilitate thecreation of metadata, a number of strategies have been employed. First of all, several ofthe metadata values may be entered automatically by the users’ system. Secondly, whencontrolled vocabularies are used, the user may simply pick metadata values from a seriesof drop-down lists. Finally, we are looking into the application of different tools forautomating the creation of metadata (e.g. by storing templates of common values or byusing an engine designed to scan the learning resources and determine the appropriatemetadata).

http://www.imsproject.org/metadata/mddictionary.html



43

4.2.2 User Profile

DescriptionUser profiles are mobile, user-controlled collections of personal and educational data (e.g.personal information, performance information, and preference information). This datarepresents a rich resource that a user can draw on to facilitate, customize, and manage hisor her learning experience(s).IssuesUser's maintain their own user profiles and have complete access and privileges to theinformation. It should be noted that performance information collected about astudent by an organization or school does not necessarily have to be stored in the IMSProfile. In this way, the organization can control the information it keeps onthe student. However, it is expected that organizations will place information traditionallyfound in a transcript into the user's IMS Profile. Utilizing digital signaturetechnology, the IMS Profile will protect against user's assigning themselves certificationsfor which they have not been certified.

The user profile will be accessible like a server. Programs will be able to access it, and youwill be able to access it via a web browser. The records will be indistributed databases. It is not the intent of the IMS to establish a single IMS Profiledatabase. Our presumption is that there will be services offered by companiesand educational institutions that will host IMS Profiles for their customers and students.

Initially, a person will have a single IMS Profile. In future versions of the Specifications,the IMS Profile will support distribution and synchronization such that auser's profile records may be spread across multiple IMS Profile servers. Future versionsof the Specification will also detail the process of extending Profileinformation.4.2.3 Content

DescriptionThe IMS content interfaces define the actions and responses that IMS compliant contentmay perform. These include functions such as assessment, reporting, sequencing,notification, bookmarking, activation, aggregation/diaggregation, simulation, and the basicmessage channel by which content communicates with other content and tools.IssuesIMS content can be "created" with most any authoring tool that are on the market today.IMS-compliant courseware management system products will allow you,without any programming involved, to group together education resources into sequencesappropriate for students or employees.

In order to make existing content IMS compliant, a metaphorical IMS wrapper will bedefined. For Web pages, you need to support IMS metadata tags in yourhtml code. IMS is working with the World Wide Web Consortium to finalize how tocorrectly represent IMS metadata tags according to an evolving metadata



44

infrastructure standard from W3. IMS will release Specifications for learning objects andCGI interfaces in the Jan-Feb time frame.4.2.4 Management

DescriptionThe management interfaces form the skeleton of instructional management systems.These functions include access control, session management, tracking students’ progress,installation of learning resources, control over the virtual learning environment,storage/retrieval of learning contents, and security.IssuesOne can envision potential issues of scalability when examining the requirements for theamount of information tracked and transferred within and between IMSenvironments. The management load will be dependent on a variety of factors includingthe amount of information generated by content, the type of information thatthe instructor wishes to be tracked. Generally, the IMS management system that facilitatesa student's learning process will store the information. However, aninstructor or the student may install additional utilities that store, analyze, and report thedata for different purposes.

Many of the scalability issues for management systems are similar to those of any object-based system. The software industry is addressing these issues throughvarious proprietary and standards-based efforts. The emerging solutions will be draftedinto the IMS Specification.4.2.5 External

DescriptionExternal interfaces provide a means by which IMS compliant content and managementsoftware can leverage external systems that are likely to be found in an online learningenvironment. These include electronic commerce, backoffice administrative systems, full-text indexing systems, digital library services, and other content or information databases.IssuesBecause organizations have already made large investments in administrative, commerce,and other systems, such as security, these services are being addressedthrough external interfaces. IMS compliant content and management systems willcommunicate through interfaces to leverage these external infrastructures.

For example, security can be provided by an organization's existing security infrastructure,thus requiring users to login only to the network (and not requiring anadditional login to an IMS management system). In cases where an organization has littleor no security, it is expected that IMS management system vendors willinclude a security module that will provide login services within the context of theirmanagement system.

The IMS Meta-data Specification

Overview

The IMS Meta-data Specification is derived from extensive collaborations, requirements meetings, focus groups and research related to the development of meta-data specifications to support online learning. Groups included in the requirements process included teachers, instructional designers, cognitive psychologists, digital library experts, administrators of educational institutions, software developers, content developers, and meta-data experts.

Goals and Characteristics

The basic goals of the specification are to support the following:

• Effective discovery via the Internet of high quality materials for aparticular educational or training purpose.

• Management of materials, including intellectual property rights,commerce, and customization of learning experiences.

• Reuse of educational resources at micro and macro levels.

In order to meet the goals above, the specification must have certain characteristics. First of all, it must be stable. The specification starts with a lean set of commonly accepted terms for describing learning resources. Stability is also fostered by including the ability to authenticate and secure meta-data that has been added to a resource. A second characteristic of meta-data is its extensibility. Whereas a common set of meta-data fields and values provides for stability, localization, or the ability to extend this base set, allows for customization in order to address a specific learning community's needs. Finally, the specification must have widespread and effective use in order to be successful. Therefore, the specification builds off of existing national and market-based meta-data standards. In addition, meta-data tools are being developed to facilitate the creation of compliant meta-data tags.

The Specification

The IMS Meta-data Specification includes two parts: a dictionary of fields and values and the organization of these fields and values into groups, or sets, descriptive of different types of learning resources. The combination of these two parts makes up the IMS Meta-data schema. To review the IMS Meta-data schema, follow the links below:

IMS Meta-data Dictionary IMS Meta-data Sets

Meta-data Representation

IMS Meta-data will be represented in XML/RDF format. See www.w3.org for details of XML and RDF. Examples will be posted on this site at a later date.

In order to add meta-data to web pages (and resources displayed within web pages), IMS recommends embedding inline the Meta-data as XML/RDF. For backward compatibility with browsers that do not support XML/RDF, IMS recommends using the HTML link tag as suggested by the World Wide Web Consortium in Section B.3 of http://www.w3.org/TR/WD-rdf-syntax/. i.e. '<link rel="meta" href="mydocMeta-data">'.

The IMS Meta-data Specification will define meta-data object interface descriptions for RMI, Corba, and DCOM in Q2 1998.

IMS Meta-data Sets v. 1.1.0 Page 1 of 3

file:C:\WINNT\Profiles\Administrator\Desktop\CBTv1n1Source\IMS\IMSMDset.html 5/3/98

IMS Meta-data SetsThere are currently four defined sets of meta-data in the IMS Meta-data Specification. These sets are comprised of fields and values defined in the IMS Meta-data Dictionary. Only one set, the IMS Base Set is required for all IMS learning resources. A learning resource is considered IMS compliant if it includes all of the requisite meta-data fields in the IMS Base Set. It is recommended to use additional defined sets of meta-data in order to extend the Base set and provide more educational value.

The four defined sets of meta-data are: Base, Item, Tool, and Module. The meta-data fields of the Base set identify the learning resource in an objective generic manner whereas the Item, Tool, and Module meta-data sets add more subjective and specific information about the educational nature and use of the learning resource. An additional category Set of Objectives has been proposed to describe a learning resource whose content itself is the articulation of an educational or training objective. Recommended fields for this meta-data set have not yet been identified.

The fields for each of the defined IMS Meta-data Sets are described below. Some of the fields have structured values consisting of sub-fields, identified in the following sections as bracketed fields below the field they describe. For a more complete description of all of the fields, please see the IMS Meta-data Dictionary.

*Starred items are fields that were adopted from the Dublin Core.

The IMS Base Set

As mentioned above, the IMS Base Set identifies the terms that are required for IMS compliant resources. As the name implies, the Base Set provides the minimum descripton of a learning resource, but provides the foundation for the addition of more meta-data sets. It is expected that the Base set will not be used primarily by itself but in conjunction with either the Item, Tool, or Module Set.

Description* Content Version Format* Publisher* Resource Identifier* Title* Subject* [Description, Keywords] Meta-Meta-data [Meta-data Scheme, Author, Creation Date, Last Modified, Container Type, Validator] Date* [Content Expiration, Availability Date, and Publication Date]

The IMS Item Set

The IMS Item Set is intended to describe a single element such as a picture, an audio clip, a video clip, a text block, or HTML file. An Item can contain more than one file (e.g. multiple images), but it



is not intended to hold contents of a complete education nature. The fields in the IMS Item Set are recommended for learning resources that match the description of an Item. These fields are considered extensions to the required IMS Base Set.

Author or Creator* Price Code Rights Management* [Agent, Use Rights]

The IMS Tool Set

The IMS Tool Set of meta-data describes a learning resource that provides a function for the user. Examples of a tool include a wordprocessor, calculator, statistical analysis package, or composition guide. A tool may be domain or task specific or the tool may serve a general purpose. The IMS Tool Set of meta-data fields are considered recommended extensions to the required IMS Base Set.

Language* User Support Learning Level Prerequisites Price Code Rights Management* [Agent, Use Rights] Platform [Required Software, Required Hardware]

The IMS Module Set

The IMS Module Set of meta-data describes learning resources with a particular educational value or purpose. A module may consist of a single or multiple elementsor learning resources. Examples of a module include a course, a topic, anassessment, an assignment, or an activity. The IMS Module Set of meta-data fields areconsidered recommended extentions to the required IMS Base Set.

Author or Creator* Language* Resource Type* Educational Objectives Granularity Learning Level Organization Pedagogy Prerequisites Presentation User Support Use Time Price Code



Rights Management* [Agent, Use Rights] Platform [Required Software, Required Hardware]

Additional Fields

The sets of meta-data describe above are not exclusive. A learning resource may have additional fields to the required Base and recommended extentions. Additional fields may be found in the IMS Meta-data Dictionary or unique fields may be created by different learning communities. Fields drawn from the IMS Dictionary will have a broader base of recognition whereas fields in use by a community of practice allow for local customization.

IMS Meta-data DictionaryVersion: 3.3March 27, 1998

The IMS Meta-data Dictionary defines all of the standard fields andtheir values forIMS resources. The IMS Meta-data Dictionary incorporates the Dublin Coremeta-data fields.Starred fields represent fields drawn from the Dublin Core. TheDictionary is a dynamicdocument maintained in a repository by the IMS Project.Additions and/or revisions to thedictionary should be submitted to theForum.

Field DescriptionsEach field below is described with the following attributes in accordance with ISOStandard 11179:

Name: the name of the field.

Definition:

a description of what the field represents. Obligation:

an indication of whether or not the field must have a valid value. A"mandatory" obligation means that the field must have a value; a"conditional" obligation means that the presence of a value depends uponthe context; an "optional" obligation means that the field does not need tohave a value. If the obligation is "mandatory" then a default value must beindicated. *NOTE: The obligation attribute refers to the obligation of thefield's value not to the field itself. Obligation in this dictionary refers to thebase type meta-data set.

Datatype:

a description of the digital format in which the field value is stored (e.g.string, alphanumeric, etc.). Some fields may have structured datatypes.

Length:

number of characters or bytes Default:

the field value to be used if the meta-data cataloger enters no value. Permitted values:

a description of the values that are consistent with the field definition andthe datatype. Some fields will include a defined vocabulary list of permittedvalues. The vocabulary list will be given here. This attribute also indicatesif there can be more than one value for a given field.

1 of 37 5/3/98 10:00 PM

IMS Meta-data Dictionary: Rev. 3.3 file:///C|/WINNT/Profiles/Administr...ktop/CBTv1n1Source/IMS/TxtDict.html

Comment:

Helpful explanation of the field and its values may be optionally provided.This may include the purpose of the field's value. Examples of the field maybe provided here.

The fields in this dictionary are described with the above terms. The use ofUnicode(16-bit wide characters) in the meta-data has not yet been resolved.

List of Meta-data Fields Author or Creator* Coverage* Date* Description* Format* Language* Other Contributors* Publisher* Relation* Resource Identifier* Resource Type* Rights Management* Source* Subject* (note: DC refers to this as Subject and Keywords) Title* AgentAvailabilityDate Concepts Container Type ExpirationDate Granularity Interactivity Level Keywords LastModifiedDate Learning Level Location Meta-Meta-data Objectives Pedagogy Platform Prerequisites Presentation Price Code PublicationDate Role Scheme

2 of 37 5/3/98 10:00 PM


SizeOf Structure Use Rights Use Time User Support Version

Definitions of IMS Meta-data Fields

AgentName:

Agent

Definition: The entity responsible for managing an aspect of a container.

Obligation:

Optional

Data Type:

Length: Minimum: 3 Chars. Maximum: 256 characters max.

Default:

Anonymous Permitted values:

Alphanumeric or GUID. Comment (e.g., an example):

For exmple, an agent controls the use rights to the offering orcontainer. Negotiating the use of a container (i.e., to use it for itsintended purpose) is accomplished with the rights agent. Typically asub-field of Rights Management.

AvailabilityDateName:

3 of 37 5/3/98 10:00 PM


AvailabilityDate Definition:

Availability Date is the date upon which the container is madeavailable for use.

Obligation:

Optional Datatype:

See Date. Length:

See Date. Default:

Permitted values:

Comment (e.g., an example):

Author or Creator *Name:

Creator Definition:

The author or creator denotes the person(s) or organization(s)responsible for the creation of the work. The person or organizationprimarily responsible for creating the intellectual content of theresource. For example, authors in the case of written documents,artists, photographers, or illustrators in the case of visual resources.

Obligation:

Optional Datatype:

Strings. My be multiple in ordered list. Length:

No max. Default:

Anonymous

4 of 37 5/3/98 10:00 PM


Permitted values:

Name: FirstName LastName or organization's Main name or acronym.There may be multiple values, separated in some defined manner(e.g., tab). The name may also be a GUID(s) that points to anestablished, potentially accessible profile(s).


The values may be supplied automatically from the author's profile,selection from a list, or direct entry. There may be multiple authors orcreators. Additional credits can be defined via an optional OtherContributors field.

ConceptsName:

Concepts Definition:

The concepts embodied in the containers content. A concept issomething conceived in the mind. An abstract or generic ideageneralized from particular instances.

Obligation:

Optional Datatype:

String pairs, multiple. Length:

128 Char. per pair. Default:

None Permitted values:

Concept and Language the concept field is written in. Comment (e.g., an example):

This field permits description of containers for which the field"subject" is inadequate because the content is applicable across manydifferent subjects, for example "dramatic structure," "metastability,"and "energy conversion" are concepts that may span across multipledomains. Concept navigation and concept mapping are powerfuleducational tools that could utilize the concept field.

5 of 37 5/3/98 10:00 PM


Container TypeName:

Container Type Definition:

The Container Type specifies the type of learning resource in thebroadest terms. Each Container Type has a defined list of meta-datafields. These are specified in the Meta-data Sets document. The term"Container Type" may change, but denotes a single object orstructure.

Obligation:

Mandatory Datatype:

Alphanumeric Length:

32 characters Default:

IMS Base Permitted values:

Only one value is permitted. Vocabulary list (see IMS Meta-data Sets for descriptions of thesevalues):

IMS Base Item Module Tool

Comment (e.g., an example): The container Type is usually a sub-field of the Meta-meta-data field.The minimum Container Type is an IMS Base type. The IMS Base typehas the lowest common denominator meta-data set of all ContainerTypes. The author may select the Container Type designator, but itcan easily be implemented within the authoring tool, and hence betransparent to the user. The set of allowable values may be extendedin the future, but should not be extended by the author. The type ofcontainer specifies the meta-data fields that will be used. See the IMSMeta-data Sets document to see how the container type correlateswith the sets of meta-data fields for the different learning resources.

6 of 37 5/3/98 10:01 PM


Coverage *Name:

Coverage Definition:

From the Dublin Core definition: "The spatial or temporalcharacteristics of the intellectual content of the resource. Spatialcoverage refers to a physical region (e.g., celestial sector); usecoordinates (e.g., longitude and latitude) or place names that are froma controlled list or are fully spelled out. Temporal coverage refers towhat the resource is about rather than when it was created or madeavailable (the latter belonging in the Date element); use the samedate/time format (often a range) [Date and Time Formats (based onISO8601), W3C Technical Note,http://www.w3.org/TR/NOTE-datetime] as recommended for the Dateelement or time periods that are from a controlled list or are fullyspelled out. "

Obligation:

Optional Datatype:

Alphanumeric Length:

32 characters Default: Permitted values: Comment:

"Users and developers should understand that use of this element iscurrently considered to be experimental."

Other Contributors *Name:

Contributors Definition:

"A person or organization not specified in a Creator element who hasmade significant intellectual contributions to the resource but whosecontribution is secondary to any person or organization specified in aCreator element (for example, editor, transcriber, and illustrator)."

7 of 37 5/3/98 10:01 PM


Obligation:

Optional Datatype:

Strings, multiple values, structured format. Length:

256 Chars./role. (to accommodate GUID) Default:


Pairs of role and name or email address. Comment (e.g., an example):

Allows extension of the author category to include graphics designer,editor, programmer, music, etc.Example: programmer:[email protected]

Date *Name:

Date Definition:

Dates relating to the container. "A date associated with the creation oravailability of the resource. Such a date is not to be confused with onebelonging in the Coverage element, which would be associated withthe resource only insofar as the intellectual content is somehow aboutthat date. Recommended best practice is defined in a profile of ISO8601 [Date and Time Formats (based on ISO8601), W3C TechnicalNote, http://www.w3.org/TR/NOTE-datetime] that includes (amongothers) dates of the forms YYYY and YYYY-MM-DD. In this scheme, forexample, the date 1994-11-05 corresponds to November 5, 1994."

Obligation:

Mandatory Datatype:

Integer Length:

10 characters per date unless time is added

8 of 37 5/3/98 10:01 PM


Default: 1998-00-00

Permitted values:

Alphanumeric specifying dates. YYYY-MM-DD, e.g., 1998-01-28http://www.w3.org/TR/NOTE-datetime using ISO 8601, theInternational Standard for the representation of dates and times. Thisformat standard has been adopted by the Dublin Core, and caninclude time. This field may contain several types of dates as subfields:

PublicationDate: ExpirationDate: AvailabilityDate:

Comment (e.g., an example): 01 August 1997 as 1997-08-01.

Description *Name:

Description Definition:

"A textual description of the content of the resource, includingabstracts in the case of document-like objects or content descriptionsin the case of visual resources." A good description using a fullvocabulary and standard grammar.

Obligation:

Mandatory Datatype:

String. May be a structured datatype per RDF for multiple languages. Length (per language):

Minimum: 3 Chars. Maximum: 2K Characters

Default:

Title. Default language is en-US. Permitted values:

A language character set defined by locale. The author or catalogerenters an alphanumeric description. May have spaces. There may bemultiple values, each of a different language. Each value will be a pairof Description and Language. Language is to be defined in the same

9 of 37 5/3/98 10:01 PM


http://www.w3.org/TR/NOTE-datetime

manner as in Language . Comment (e.g., an example):

Full text searches may be done on the abstract.

Format *Name:

Format Definition:

"The data format of the resource, used to identify the software andpossibly hardware that might be needed to display or operate theresource." Format is the technically defined format of the container orlearning object. For instance, the digital format(e.g., MIME type).Format may also define a non-digital format, such as a book orvideotape.

Obligation:

Mandatory Datatype:

String Length:

Unknown Default:

HTML Permitted values:

Use Mime types if digital format. Otherwise, use language terms ofBook, Video, Picture, etc.


To determine if client or environment have the necessary support forthe format. .txt, .doc, .jpg, .gif, etc.

ExpirationDateName:

ExpirationDate Definition:

10 of 37 5/3/98 10:01 PM


Content Expiration Date. The date upon which the contents may nolonger be valid, for instance, a list of US presidents becomes invalidwithin four years. Expiration does not include licensing expiration,which is managed external to the container.

Obligation:

Optional Datatype:

See Date. Length:

See Date. Default:

Permitted values:


GranularityName:

Granularity Definition:

Granular level is a relative size, for instance the level of curricularscope.

Obligation:

Optional Datatype:

String Length:

256 bytes Default:

NA Permitted values:

Suggested vocabulary

11 of 37 5/3/98 10:01 PM


Curriculum Course Unit Topic Lesson Fragment NA (Not applicable)

Comment (e.g., an example): Other values, such as levels of assessment (e.g., exam, test, quiz,problem set, assignment, question) and certification (e.g., degree,course, assessment) can be used.

Interactivity levelName:

Interactivity level Definition:

The level of interaction between the user and the container.Interactivity is the degree to which the user can influence the courseof action or the behavior of that materials.

Obligation:

Optional Datatype:

String Length:

128 Characters Default:

Low Permitted values:

Extensible suggested vocabulary list (note: this is an extensible list;the meta-data cataloger may enter a term or phase not on thesuggested vocabulary list):

low medium high

Comment (e.g., an example): This field helps to describe the experience for the user. Interactivity isa major feature of Internet and multimedia materials. There is as yet

12 of 37 5/3/98 10:01 PM


no clear manner of codifying interactivity. This field suggests terms,but it is expected that the vocabulary will evolve.

KeywordsName:

Keywords Definition:

one or more words exemplifying the meaning or value Obligation:

Optional Datatype:

Text Length:

256 Char. Default:

Container Permitted values:

Text Comment (e.g., an example):

Recommended that keywords be in order of importance

Language Name:

Language Definition:

"The language of the intellectual content of the resource." Humanlanguage the work is presented in as defined by a locale. A locale is alanguage and a country. Language alone may be used.

Obligation:

Mandatory Datatype:

String, may be multiple.

13 of 37 5/3/98 10:01 PM


Length:

Minimum: 2 char./locale Maximum: 5 char./locale

Default:

en-US (US English) Permitted values:

Use standard codes (xx-YY). The standard code for W3C for locales(http://www.w3.org/TR/PR-xml-971208) uses two lower case lettersfor language and two upper case letters for country. The two areseparated by a hyphen: en-US (English, United States)

The language codes are lower-case, two-letter codes defined byISO-639 (e.g.,http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt). Thecountry codes are upper-case, two-letter codes defined by ISO-3166(such as:http://www.chemie.fu-berlin.de/diverse/doc/ISO_3166.html). Thefield may have more than one value.


The code is generated by the creator or creator profile. The creatormay select from a list. en-US.

LastModifiedDateName:

LastModifiedDate Definition:

Obligation:

Optional Datatype:

See Date. Length:

See Date. Default:

14 of 37 5/3/98 10:01 PM


http://www.w3.org/TR/PR-xml-971208

http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt

http://www.chemie.fu-berlin.de/diverse/doc/ISO_3166.html

Permitted values:


Learning LevelName:

Learning Level Definition:

This field describes the difficulty of the materials. This field defines thetarget audience in terms of academic grade and skill level at thatgrade. The structure of the field terms reflects the fact that what iseasy at a high academic grade is more difficult at a lower one. Specificcapabilities required, such as reading proficiency in a particularlanguage, are described in the Prerequisites field.

Obligation:

Optional Datatype:

Integer pairs. Multiple pairs allowed. Length:

32 characters per pair. Default:

0:0 (Not Applicable, Not Applicable). If either value is omitted in a pair,the default of 0 or 0 is substituted, as appropriate by place.

Permitted values:

The field permits multiple pairs. Age and Skill are paired (doubles).Multiple pairs may be used. Each pair is structured for Age: Skill,where Age can have a value of 0-99 (0= not applicable) and Skill canhave a numerical value from 0 to 5 with 1 as the easiest. (0 = notapplicable, default is 0).


This field is used to discover materials that are appropriate for theskill level of the learner. Age is subsumed into grade. A picture may becategorized as N:0. An offering with the value of 8-9:3, 10-11:1would be judged to require moderate (3) skill level for ages 8-9 (USgrades 3-4) and a low (1) skill level for ages 10-11(grades 5-6).

15 of 37 5/3/98 10:01 PM


LocationName:

Location Definition:

This is typically the URL(s) through which the container can beretrieved, either directly or through an index. Other addressingschemes can accomplish this objective. The URL is only an example.

Obligation:

Optional Datatype:

URL or GUID. May be multiple. Length:

256 Char. Default:

Derived from GUID Permitted values:

URL or GUID. Comment (e.g., an example):

A URL implies the mechanism for retrieving the offering. Containerlocation(s) (URL) is (are) normally automatically entered uponpublishing. Values may be changed with proper permission, e.g., toreflect change of stewardship.

Meta-Meta-dataName:

Meta-Meta-data Definition:

Information about the meta-data. Obligation:

Mandatory Datatype:

String pairs, Multiple Length:

16 of 37 5/3/98 10:01 PM


128 Bytes per pair Default:

Permitted values:

Four sub-fields: Author:

Source of the meta-data scheme or vocabulary. ContainerType:

Container Type. Base. LastModifiedDate:

Date the meta-data was last edited. Scheme:

A designation of the IMS Meta-data Scheme Version.


ObjectivesName:

Objectives Definition:

Learning objectives met by the container. Obligation:

Optional Datatype:

String pairs, Multiple Length:

128 Bytes per pair Default:

Exposure, en-US Permitted values:

For each pair, the first term is the educational objective, the second isthe reference. The second term of the pair, reference, is optional.Reference may be the entity that provides the term or, if the taxonomyis not derived from a standard source, may be the language.


May designate enterprise, corporate, local, state and/or federallyrequired objectives met by the container or learning object.

17 of 37 5/3/98 10:01 PM


Example: Factoring binomial equations, AMA

A source implies a language. If there is not a defined source for theterm, a language locale may be used.

Pedagogy (Teaching Method)Name:

Pedagogy Definition:

Pedagogy is the teaching method used in the container. Obligation:

Optional Datatype:

String, May be a structured datatype per RDF for multiple languages. Length:

Minimum: 3 Char. Maximum: 256 Char.

Default:

Expository. Permitted values:

Suggested vocabulary list:

Expository (an explicit presentation of materials andconcepts; generally explicit and inductive) Discovery (materials are presented to lead a student toa conclusion; generally implicit and deductive)

Comment (e.g., an example): The Pedagogy (teaching method) field allows a learner and/or teacherto select the style of pedagogy that is appropriate to the learner'sneeds or the teacher's purpose. The vocabulary is intentionally smallat this time, but will be expanded.

PlatformName:

Platform

18 of 37 5/3/98 10:01 PM


Definition:

Required software, hardware to use the container. Obligation:

Optional Datatype:

String Length:

1024 Char. Default:


Alphanumeric, structured into 2 subfields each with 3sub-sub-fields:

Required Software

Description States the minimum required software.Names the software, including theversion needed, and the operatingsystem.

Purpose Defines the software required on theclient end to use to container'scontents. These may be plug-ins for abrowser.

Values May contain more than onealphanumeric value. Entered by thecreator or by the authoring profile in anauthoring tool. May be a list selection ifadditional software is required. Mayuse "None" as a default, meaning thecontainer's contents will work with astandard browser.

Required Hardware

Description States the minimum requiredhardware.

Purpose If special hardware is required by the

19 of 37 5/3/98 10:01 PM


client (e.g., video system) to use thecontainer, it is specified here.

Values Name, version of hardware andperipherals. Can have more than onevalue. Can be entered from a list,automatically from an authoring profileor from an automated scan of thecontents. May use "Normal" as adefault, meaning a platform adequatefor a normal browser.

Comment (e.g., an example): Platforms will change faster than a standardized vocabulary couldkeep pace with.

PrerequisitesName:

Prerequisites Definition:

Course and/or capabilities required to use the material. Obligation:

Optional Datatype:

String. May be a structured datatype per XML-RDF for multiplelanguages.

Length:

1024 characters per block Default:


Alphanumeric pairs: Prerequisite, Language. Language refers to thelanguage in which the field term is written.


French 101, en-US, Francais 101, fr_FR. May include minimum usercapabilities description. For example a mathematics module mayinclude "Reads English at a 12-year old native English speaker's levelor better."

20 of 37 5/3/98 10:01 PM


PresentationName:

Presentation Definition:

Presentation describes how the materialsare presented at the user'sworkspace. It is a technical description. What is the dominant mode?Images? Text?

Obligation:

Optional Datatype:

Strings, multiple, ordered list Length:


Default:

Text Permitted values:

Multiple values permitted. If multiple values are used, order issignificant. The terms are ranked in order, with the first mostsignificant. Suggested Vocabulary List:

Images Verbal Sound Multi-User

Comment (e.g., an example): A learner or teacher searching for materials that are attuned tocognitive styles can use these terms effectively. These terms addresssome of Howard Gardner's learning styles. It may be that Multi-Useris defined with subtypes to indicate how many users can participatesimultaneously.

Price CodeName:

21 of 37 5/3/98 10:01 PM


Price Code Definition:

The price of using a particular offering, which may be free. It may alsoindicate that price is negotiated. Price Code defines the price ormechanism relative to the Use Rights. The Price Code defines the pricefor the common-denominator user. A common denominator user hasno defined role or status with no privileged access right.

Obligation:

Conditional. If the Use Rights are anything other than Restricted (+ or-) then there must be a value for the price code.

Datatype:

Integer, in cents or smallest denomination of currently. May includecountry code in a structured datatype.

Length:

Integer (2 bytes) plus optional country code. Default:

0, US (US cents) [Note: may need to adjust for micro pricing of items.] Permitted values:

-1, Positive values. 0 up. -1 means Contact Publisher for pricing.. Comment (e.g., an example):

Enables searching for free materials, and to find materials withinpredetermined price guidelines.

Publisher *Name:

Publisher Definition:

"The entity responsible for making the resource available in itspresent form, such as a publishing house, a university department, ora corporate entity." The Publisher is defined as the agent with thelegal authority to negotiate business arrangements such as licensingand sale of the container. Typically this is the publisher. It may be theauthor.

Obligation:

Mandatory

22 of 37 5/3/98 10:01 PM


Datatype: Strings: Alphanumeric or GUID. May be a structured datatype perRDF.

Length:

Minimum: 3 Chars. Maximum: 256 characters max. per role.

Default:

Anonymous, all roles Permitted values:

For each role, Alphanumeric or GUIDs. An ordered list. The presentpublisher is the last in the ordered list. Values (publishers or GUIDs)can be added to the list, but not deleted. Publisher may be astructured datatype per RDF to designate different stewardships ofdifferent aspects of the object A value of Anonymous implies freerights to container.


The Publisher field provides the primary point of contact for businessarrangements relative to the container. The named publisher isresponsible for negotiations including other, partial, owners. In theevent a container's stewardship is transferred, the new steward(publisher)is appended to the end of the ordered list, providing arecord of stewardship. The GUID of the container publisher(s) may besupplied automatically by the IMS environment or may beentered/selected by the author (creator).

Relation *Name:

Relation Definition:

"An identifier of a second resource and its relationship to the presentresource. This element permits links between related resources andresource descriptions to be indicated.

Obligation:

Optional Datatype:

String, multiple Length:

256 Char. per block

23 of 37 5/3/98 10:01 PM


Default:


Alphanumeric, multiples Comment (e.g., an example):

The facilitate linking to other containers or URLs for reviews, datasets,and so forth. May indicate ancillary physical objects such as texts orvideo. Examples include an edition of a work (IsVersionOf), atranslation of a work (IsBasedOn), a chapter of a book (IsPartOf), anda mechanical transformation of a dataset into an image (IsFormatOf)."Association with another container (e.g., GUID), URL, or physicalobject. From the Dublin Core definition: "The relationship of thisresource to other resources. The intent of this element is to provide ameans to express relationships among resources that have formalrelationships to others, but exist as discrete resources themselves.For example, images in a document, chapters in a book, or items in acollection. Formal specification of relation is currently underdevelopment. Users and developers should understand that use ofthis element is currently considered to be experimental."

Resource Identifier *Name:

Identifier Definition:

"A string or number used to uniquely identify the resource. Examplesfor networked resources include URLs and URNs (when implemented).Other globally-unique identifiers, such as International StandardBook Numbers (ISBN) or other formal names are also candidates forthis element." Each container must have a unique identification. Theidentifier may not be human readable.

Obligation:

Mandatory Datatype:

String Length:

128 Chars. Default:

None

24 of 37 5/3/98 10:01 PM


Permitted values:

Alphanumeric, an ID and an ID type (e.g., URN) Comment (e.g., an example):

Internal designation by provider. May include the Resource Identifierand the source, e.g., 123-45678-90123:DOI Resource locations maybe indicated in the Location field, if used.

Resource Type *Name:

Type Definition:

"The category of the resource, such as home page, novel, poem,working paper, technical report, essay, dictionary." Resource Type is adescription of the manner in which the content is presented. Forinstance, is it a simulation? A tutorial?

Obligation:

Optional Datatype:

Strings, Ordered list Length:

Minimum: 3 Characters Maximum: 1024 Characters

Default:

Base Permitted values:

English strings. Multiple values permitted. If multiple values are used,order is significant. The terms are ranked in order, with the first mostsignificant. Suggested Vocabulary List:

Advertisement Assessment Base (undifferentiated) Collection Dataset Document Example Exercise

25 of 37 5/3/98 10:01 PM


Media Resource Message Misc (ellaneous) Reference Schedule Simulation Tool Tutorial

Comment (e.g., an example): The vocabulary list will be maintained and verified by an IMSenvironment. An author or publisher will select terms from the list.The default of base is undifferentiated. It has no declared form.Resource Type is not the same as genre. A poem is a genre. The IMSMeta-data does not include genre as a separate field at this time. It isexpected that genre will become a subtype of Resource Type through astructured field, e.g., RDF. See Using IMS Meta-data for additionalinformation.

Rights Management *Name:

Rights Definition:

"A rights management statement, an identifier that links to a rightsmanagement statement, or an identifier that links to a serviceproviding information about rights management for the resource.Rights Management is defined as the agent with the legal authority tonegotiate access to the container and the rights of usage. It mayinclude a link to a copyright notice or a rights managementstatement. The Use Rights are the common denominator rights for anindividual abiding by the Price Code requirements. Rights may be astructured datatype per RDF to designate different agents'responsibilities for different aspects of the object and to specify therights of usage.

Obligation:

Optional

Datatype: Strings: Alphanumeric or GUID. May be a structured datatype perRDF for multiple roles.

Length:

Default:

26 of 37 5/3/98 10:01 PM


Permitted Values: There are two subfields at this time: Agent

The container's rights agent determines the rights to the offering.Use Rights

What a user can do with an offering; permissioning rules. Comments:

PublicationDateName:

PublicationDate Definition:

Publication Date. The default of the Date field. Obligation:

Optional Datatype:

See Date. Length:

See Date. Default:

Permitted values:


RoleName:

Role Definition:

The role of the entity serving as the learning resource. As examples, aperson may have the role of learner or teacher and an enterprise may

27 of 37 5/3/98 10:01 PM


have the role of university or publisher. Obligation:

Optional Datatype:

Strings, ordered list Length:

Multiple alphanumeric blocks Default:


The entity described may be a person, a group or an enterprise. Suggested Vocabulary List:

None Administrator Association Class Community College Consultant College Coordinator Group Learner Provider School Student Teacher Tutor University

Comment (e.g., an example): The intent of this field is to define the type of entity described by thecontainer, typically in a profile. Coupled with a subject, this mayfacilitate the use of people, groups and institutions as searchableresources in an IMS.

SchemeName:

Scheme Definition:

28 of 37 5/3/98 10:01 PM


One or more descriptions of information structures or locations ofinformation structures describing an aspect of a learning resource.

Obligation:

Mandatory (under Meta-meta-data) Datatype:

One or more strings Length:

256 characters for each string Default:

null Permitted values:

LINK, URL or a description of a scheme structure, e.g., in XML. Comment (e.g., an example):

In many cases, the scheme will be designated by a URL (location). AScheme is a sub-field of the Meta-meta-data. For instance, one ormore locations of meta-data schemes describing the meta-data for acontainer. resource.

SizeOfName:

SizeOf Definition:

Size of the container in bytes. Obligation:

Optional Datatype:

Long integer Default:

0 (not applicable or not known) Permitted values:

Size in bytes, Long integer Comment (e.g., an example):

This is a good candidate for automated entry.

29 of 37 5/3/98 10:01 PM


Source *Name:

Source Definition:

Source of the content, if not original in this LearningObject/Container. "Information about a second resource from whichthe present resource is derived. While it is generally recommendedthat elements contain information about the present resource only,this element may contain a date, creator, format, identifier, or othermeta-data for the second resource when it is considered important fordiscovery of the present resource; recommended best practice is touse the Relation element instead. For example, it is possible to use aSource date of 1603 in a description of a 1996 film adaptation of aShakespearean play, but it is preferred instead to use Relation"IsBasedOn" with a reference to a separate resource whose descriptioncontains a Date of 1603. Source is not applicable if the presentresource is in its original form."

Obligation:

Optional Datatype:

String Length:

256 Characters Default:


Alphanumeric Comment (e.g., an example):

Example: Adapted from "Sniffy the Virtual Rat".

StructureName:

Structure

30 of 37 5/3/98 10:01 PM


Definition: Structure is a technical description of how the material is organizedwith respect to ordering. This field addresses the underlyingorganizational structure material. Linear materials, such as a textbook, may include internal links, but are inherently linear in order.

Obligation:

Optional Datatype:

Strings, Multiple Length:


Default:

Ordered Permitted values:

Multiple terms can be used and the order of the terms chosen issignificant.Suggested Vocabulary

Linear Hyperdimensional Branched Parceled Null

Linear A sequential structure of materials. Linear materialhas an inherent order, from front to back, such as atext book. The user may be able to navigate throughlinks between parts of the book, but there is anunderlying linear structure. Linear materials have oneinherent dimension, front to back. Kolb's Divergersand Assimilators may be more comfortable with thistype of material. This may be useful for someConvergers.

Hyperdimensional Hyperdimensional means merely many dimensions,usually implying higher numbers of dimensions.Hyperdimensional materials have no inherent front,back, top or bottom. The Web is inherentlyhyperdimensional. If we think of each segment as asquare plate, then one plate may communicate withanother plate along a common edge. Each plate musthave an edge in common, or touching, another plate in

31 of 37 5/3/98 10:01 PM


order to link to it. In order for lots of plates to touchlots of other plates, the structure can be consideredhyperdimensional.

Kolb's Accommodators and Convergers may respondwell to hyperdimensional materials. The termhyperdimensional is used instead of hyperlinkedbecause the latter is already associated with Internetlinks, rather than solely with links within acontainer.

Branched Hierarchical or tree structure.

Parceled Divided into regions or subdomains: miniworlds androoms.

Null Atomic.

Comment (e.g., an example): Although material may use both, there will be one dominantorganization.

Subject *Name:

Subject (note: the DC refers to this field as Subject and Keywords) Definition:

"The topic of the resource. Typically, subject will be expressed askeywords or phrases that describe the subject or content of theresource. The use of controlled vocabularies and formal classificationschemes is encouraged."The subject is the knowledge domain. The use of terminology fromstandard sources is encouraged. May also included a subjectdescription. Use of a structured field with standard vocabularies isencouraged.

Obligation:

Mandatory Datatype:

Strings. May be a structured datatype per RDF for multiple languagesand multiple sources of terminology (taxonomies).

Length:

256 Chars/per block, multiple blocks.

32 of 37 5/3/98 10:01 PM


Default:

General, en-US. If the second term is not used in a pair, en-US is thedefault.

Permitted values:

Two subfields: Description

Text describing the subject. Keywords:

Words and phases which may be from standardtaxonomies. Keywords may be a structured sub-field.If there are no defined sub-fields, keywords isassumed. Subject descriptors will be pairs (doubles) of term andsource of the term, e.g., Colonial, Sears. Multiple pairsacceptable. The source term can be null. Sources ofterms also imply the language, hence locale andsource will not both be needed. Locale may be used if astandard source taxonomy is not used.

Comment (e.g., an example): Users can search for materials with commonly used terms describingthe knowledge domain of the content. Sources of subject descriptorsinclude: NIFL Literacy Thesaurus (NIFL-ALT), Thesaurus of ERICDescriptors (ERIC), Library of Congress Subject Headings (LCSH), andSears Subject Headings (Sears) and professional disciplines. It isexpected that over time subject domain specialists will createstandard taxonomies in RDF.

Title *Name:

Title Definition:

The main label of the offering. Obligation:

Mandatory Datatype:

String. May be a structured datatype per RDF for multiple languages. Length:

Minimum: 3 Chars.

33 of 37 5/3/98 10:01 PM


Maximum: 1024 characters max. per language. Default:

GUID. Default language is en-US. Permitted values:

A language character set defined by locale. The author orrepresentative enters an alphanumeric title with no fixed length. Mayhave spaces. There may be multiple values, each of a different humanlanguage. Each value will be a pair of Title and Language. Language isto be defined in the same manner as in Language .


Describes the container in a single phrase.

Use RightsDefinition:

What a user can do with an offering; permissioning rules. A sub-fieldof Rights Management.

Obligation:

Optional Datatype:

String, Structured datatype permitted, multiple values Length:

Minimum: 3 Chars. Maximum: 1024 Chars.

Default:

Restricted - (means unrestricted) Permitted values:

Alphanumerics with + or -, Multiples allowed. "+" means Allowed, "-"means Not Allowed. Suggested Vocabulary List:

Restricted +/- Use +/- (this means use it for the intended purpose) Aggregatable +/- (can be included in anothercontainer) Disaggregatable +/- (can be taken apart) Distributable +/- Editable +/-

34 of 37 5/3/98 10:01 PM


Comment (e.g., an example): Each value is presumed to be allowed (+) unless specificallydisallowed (-). In a simple form, a simple list of uses is acceptable. Thestructured datatype allows multiple values, and values that may bedifferentiated by some other factor, such as payment or access right.To foster best use of materials. Owners may distribute materials forfree usage, but prohibit re-packaging for sale, for example. This fieldpromotes both free and commercial products. As an example,Restricted - means that there are no restrictions on the use of thecontainer, including the right to Use, Aggregate, Disaggregate, Editand Redistribute the container. Restricted + means that thecontainer cannot be used, aggregated, desegregated, edited ordistributed. This designation would be used to transport a containeracross a communications system. An organization may use thisdesignation internally for pre-release work. Restricted supercedes allother Use Rights values.

Use TimeName:

Use Time Definition:

Use Time is an estimate of the time a normal learner/user would beexpected to spend using the container. This is an approximation, andis intended to provide relative scale information. The values list willserve to provide meaningful increments.

Obligation:

Optional Datatype:

Positive Integer Length:

Integer (two bytes) Default:

0 (Not Applicable) Permitted values:

The Use Time field will use minutes in integer for values. Suggested Vocabulary List:

0 (Not Applicable) 2 (min.)

35 of 37 5/3/98 10:01 PM


6 (min.) 20 (min.) 60 (min., 1 hr.) 180 (min., 3 hrs.) 600 (min., 10 hrs.)

Comment (e.g., an example): The value selected will be the shortest time that includes the timeestimated for a typical user for whom the learning object wasdesigned. Thus, a learning object with an estimated use time of 45minutes can have a Use Time value of 1 hr. This means that theestimated use time is between 20 min. and 1 hr. The actual storedmeta-data field value would be 60. The list of values (vocabulary) canbe extended to any time in minutes. The search or user interfaceprogram(s) can translate between minutes and hours as needed. TheUse Time field has three main applications: Discovery, Selection andPlanning.

User SupportName:

User Support Definition:

Indication that direct user support is available from the provider. Thismay include telephone support and email. The type of support is notspecified in the meta-data. The provider may specify support specificsin the contents.

Obligation:

Optional Datatype:

Boolean Length:

1 Byte Default:

No Permitted values:

Yes, No Comment (e.g., an example):

To allow potential users to search for materials that may offer somedirect support if needed.

36 of 37 5/3/98 10:01 PM


VersionName:

Version Definition:

A numeric indicator of the version or edition. Obligation:

Mandatory Datatype:

Float, positive. Length:

0.00 to 1000.00 Default:

1.00 Permitted values:

Only one value is permitted: 0.00 to 1000.00 Comment (e.g., an example):

A numeric indicator that this content has changed in relation toanother version of the same content: the edition number of theoffering. The creator or publisher enters this number.

37 of 37 5/3/98 10:01 PM


EDUCOM/NLII Instructional Management Systems Project 1

Copyright ©1998 Educom Draft 0.5 April 29, 1998

EDUCOM/NLII Instructional Management SystemsSpecifications Document

Version 0.5Date: April 29, 1998

1 OVERVIEW....................................................................................................................5

1.1 STRUCTURE OF DOCUMENT ............................................................................................51.2 STATUS OF DOCUMENT .................................................................................................5

2 INTRODUCTION............................................................................................................5

2.1 STATEMENT OF NEED ...................................................................................................62.2 THE INSTRUCTIONAL MANAGEMENT SYSTEMS PROJECT......................................................62.3 IMS STAKEHOLDERS....................................................................................................72.4 BACKGROUND.............................................................................................................72.5 DESIGN ASSUMPTIONS...................................................................................................8

2.5.1 Content needs to be granular; systems need to be scalable...........................................92.5.2 Desire for interoperability....................................................................................102.5.3 Desire for customization and extensibility...............................................................102.5.4 Importance of collaboration..................................................................................11

3 TECHNICAL CONTENT...............................................................................................11

3.1 ASSUMPTIONS............................................................................................................113.1.1 Multiple object models will continue to exist............................................................113.1.2 CORBA and DCOM bridging capabilities will increase.............................................113.1.3 Use of software agents will increase......................................................................123.1.4 Use of virtual reality and immersive environments for online learning will increase.......123.1.5 Large instructional management systems will face problems similar to large transaction-based systems..................................................................................................................123.1.6 HTML remains the most cross-platform format........................................................123.1.7 Distributing objects to users will increase...............................................................123.1.8 XML will become a dominant standard...................................................................123.1.9 Industry support for offline work will increase.........................................................123.1.10 Innovation requires broad areas within which producers in a marketplace can compete..13

3.2 REQUIREMENTS .........................................................................................................133.2.1 Enable innovation...............................................................................................133.2.2 Support Extensibility...........................................................................................133.2.3 Utilize XML.......................................................................................................133.2.4 Suppport dynamic generation of content and dynamic interaction with content..............133.2.5 Seed critical data types required to increase interoperability......................................133.2.6 Be implementable................................................................................................133.2.7 Enable integrated environments............................................................................143.2.8 Support offline learning and training.....................................................................143.2.9 Reuse existing standards......................................................................................143.2.10 Enable scalable implementations...........................................................................153.2.11 Enable loosely coupled systems.............................................................................153.2.12 Enable the de-coupling of content and delivery systems..............................................15

3.3 DESIGN ....................................................................................................................153.3.1 Architecture.......................................................................................................153.3.2 System Model.....................................................................................................173.3.3 High Level Service Organization............................................................................17

3.4 DEFINITIONS .............................................................................................................19



3.4.1 Containers.........................................................................................................193.4.2 Meta-data..........................................................................................................193.4.3 Profiles.............................................................................................................193.4.4 Aggregation.......................................................................................................193.4.5 Sequence............................................................................................................203.4.6 Management Software..........................................................................................203.4.7 Notification.......................................................................................................203.4.8 Signposts...........................................................................................................203.4.9 more…..............................................................................................................20

3.5 CONFORMANCE .........................................................................................................203.5.1 Content.............................................................................................................203.5.2 Management Systems...........................................................................................21

3.6 SERVICES .................................................................................................................213.6.1 Groups/Users/Profiles.........................................................................................213.6.2 Sessions............................................................................................................223.6.3 Messages...........................................................................................................233.6.4 Relationship.......................................................................................................333.6.5 Property............................................................................................................433.6.6 Security.............................................................................................................443.6.7 Persistence.........................................................................................................473.6.8 Digital Commerce...............................................................................................48

4 PROOF OF CONCEPT IMPLEMENTATION.................................................................48

4.1 INTRODUCTION..........................................................................................................484.1.1 Scope and Status of Prototype...............................................................................484.1.2 Platform requirements.........................................................................................48

4.2 USER INTERFACE........................................................................................................484.2.1 Logging In.........................................................................................................494.2.2 Groups..............................................................................................................494.2.3 Resources..........................................................................................................494.2.4 Members............................................................................................................494.2.5 Communications.................................................................................................494.2.6 Backpack...........................................................................................................494.2.7 Control Panel....................................................................................................50

4.3 OVERVIEW OF PROTOTYPE ARCHITECTURE .....................................................................504.3.1 Management.......................................................................................................504.3.2 Messaging.........................................................................................................504.3.3 Content.............................................................................................................514.3.4 Content Server....................................................................................................514.3.5 Profile Server.....................................................................................................52

4.4 PROTOTYPE API REFERENCE........................................................................................534.4.1 user class..........................................................................................................534.4.2 Group Class......................................................................................................544.4.3 UserProfile Class...............................................................................................554.4.4 Resource Class...................................................................................................554.4.5 SignPost Class...................................................................................................56

4.5 RMI SERVERS............................................................................................................574.5.1 Coordinator RMI Interface...................................................................................574.5.2 Channel Manager RMI Interface............................................................................58

4.6 USEFUL CLASSES........................................................................................................594.6.1 Message Class....................................................................................................594.6.2 Messenger Class.................................................................................................594.6.3 Resource Agent...................................................................................................604.6.4 CGI_MessageRouter............................................................................................61

4.7 PROTOTYPE UTILITY APPLICATIONS ..............................................................................614.7.1 Chat.................................................................................................................614.7.2 Message Board...................................................................................................614.7.3 Message Service..................................................................................................62



4.7.4 Channel Spy.......................................................................................................624.8 RESOURCE DEMOS......................................................................................................62

4.8.1 History Test.......................................................................................................624.8.2 Collaborative Graph and Monitor.........................................................................62

4.9 COMMUNICATING WITH THE SERVER: A BRIEF TUTORIAL ................................................624.9.1 Posting HTML Form data to a Message Channel.....................................................624.9.2 Monitoring the Message Channel...........................................................................634.9.3 Creating Signposts..............................................................................................64

5 REFERENCE SCHEMA.................................................................................................66

5.1 META-DATA .............................................................................................................665.1.1 Module..............................................................................................................665.1.2 Item..................................................................................................................665.1.3 Tool.................................................................................................................665.1.4 Course Catalog..................................................................................................66

5.2 SCHEMAS FOR ASSESSMENT..........................................................................................665.3 SCHEMAS FOR PERFORMANCE DATA ..............................................................................685.4 SCHEMAS FOR NOTIFICATIONS ......................................................................................695.5 SCHEMAS FOR NAVIGATION .........................................................................................70

6 REFERENCE DATA CLASSES......................................................................................70

6.1 PERFORMANCE DATA..................................................................................................706.2 NOTIFICATIONS .........................................................................................................70

7 REFERENCES..............................................................................................................70

7.1 DUBLIN CORE ...........................................................................................................707.2 OMG.......................................................................................................................707.3 ODMG....................................................................................................................707.4 W3 RDF AND XML...................................................................................................707.5 NIST RBAC............................................................................................................71

8 CONTRIBUTORS..........................................................................................................71

9 THANKS.......................................................................................................................71

10 SPECIAL THANKS....................................................................................................71

11 APPENDIX A: INTERFACE DESCRIPTIONS.............................................................72

11.1 GROUP SERVICE INTERFACES........................................................................................7211.2 SESSION SERVICE INTERFACES......................................................................................7511.3 MESSAGING SERVICE INTERFACES.................................................................................75

11.3.1 Origin of Interfaces.............................................................................................7511.3.2 Interface Descriptions..........................................................................................7611.3.3 CORBA IDL......................................................................................................12811.3.4 DCOM IDL.......................................................................................................147

11.4 RELATIONSHIP SERVICE INTERFACES ............................................................................14711.4.1 Origin of Interfaces............................................................................................14711.4.2 The Base Relationship Model...............................................................................14711.4.3 9.4 Graphs of Related Objects..............................................................................15811.4.4 Specific Relationships.........................................................................................16611.4.5 References.........................................................................................................16911.4.6 CORBA IDL......................................................................................................16911.4.7 DCOM IDL.......................................................................................................175

11.5 PROPERTY SERVICE INTERFACE....................................................................................17511.5.1 Origin of Interfaces............................................................................................17511.5.2 Interface Descriptions.........................................................................................17511.5.3 CORBA IDL......................................................................................................18711.5.4...........................................................................................................................205



11.5.5 DCOM IDL.......................................................................................................20511.6 SECURITY SERVICE INTERFACES...................................................................................205

11.6.1 Origin of Interfaces............................................................................................20511.6.2 Interface Descriptions.........................................................................................20511.6.3...........................................................................................................................21011.6.4 CORBA IDL......................................................................................................21011.6.5 DCOM IDL.......................................................................................................210

11.7 COMMERCE SERVICE INTERFACES.................................................................................21011.7.1 Interface Descriptions.........................................................................................21011.7.2 CORBA IDL......................................................................................................21111.7.3 DCOM IDL.......................................................................................................211

12 APPENDIX B: THE ROLE OF RMI..........................................................................211

12.1.1 Interface Descriptions.........................................................................................21212.1.2 CORBA IDL......................................................................................................21212.1.3 DCOM IDL.......................................................................................................212

1



Overview

1.1 Structure of DocumentThe IMS Specifications document is divided into 3 primary sections. The first part is an introduction tothe impetus behind the project and an overview of the project goals, the requirements and designassumptions. The second section of this document begins an introduction to the technical designdecisions, rationale, and issues that have been addressed in the technical framework. Interspersed throughthis section is information about conformance. The final section is a series of Appendices that include theIMS Specification API; information, tutorials, and API reference about the prototype software developed todemonstrate IMS design concepts; and example data models for performance results, navigation events, andother types of information likely to be exchanged in an IMS conforming system.

1.2 Status of DocumentThis document is in draft form and is available for public comment until August 15, 1998. Commentsshould be directed to [email protected]. This document can be found at:

http://www.imsproject.org/specs.html

2 Introduction

"00011101010001100011000010101010010" --- W. Shakespeare (?)

Information in the digital world is broken down into bits and pieces represented in computer language as0's and 1's. The above line could be the opening string of Shakespeare's Macbeth or it could be therepresentation of Mona Lisa's left eye in her famous portrait.

However random the combination of 0's and 1's might be, the abstraction of information into coded parts ismeaningful when translated into some human understandable form, such as text or images. To say we livein an information society, though a cliché, is not an exaggeration. The proliferation of informationavailable at any given time is staggering. All of this information, from Einstein's theory of relativity to lastnight's basketball scores, can be reduced to 0's and 1's.

The power of computers for retaining and processing information, and the greater capacity for representingvarious types of information in digital form has created what has been called information overload. With allthe information that can be readily available at any time and any place, two challenges arise: how to makesense of all this information and what to do with this information. In the first challenge, if the overload ofinformation obscures any meaning, then the information may just as well retain its form as 0's and 1's. Inthe second challenge, information is not in itself powerful, but what can be done with the information is.When information can be leveraged appropriately, interactions can be richer and more productive.

In the information society, the challenges of making sense of information and using this informationeffectively has been described as the challenge of turning information into knowledge. This is a challengefelt in all areas where computers are being used as information processing and/or communication tools. Itis a challenge of special interest to the education and training communities. The question many differentlearning communities face is how to support the interchange of information between students and mentors,between peers, and between individuals and the materials of the learning environment in meaningful ways.In other words, how to take the 0's and 1's, the bits and pieces, of the enormous amounts of informationthat can be generated, archived, reviewed, processed, shared, etc. and use this information towardsupporting a more effective learning process.



2.1 Statement of Need

Using computers for education is not a new prospect although most efforts have been directed toward standalone, context specific applications. The rise of networks, and in particular the Internet, has increased theinterest in the use of computers as a channel as well as an environment for learning. Networked computersenable the learning experience to be a more collaborative experience than just a single student interactingwith information on the computer. The Internet is heralded as a global, and most importantly, platform-independent network for supporting education through the creation, sharing, and distribution ofinformation.

Schools, universities, corporations, and other organizations interested in promoting learning environmentshave recognized the potential of the Internet and are rapidly building, or have already built, a networkinfrastructure in order to capitalize on the world of resources. The next obvious step is to find and acquirevaluable information. Many college campuses, for example, boast network connections in every room (bothinstructional and residential). But, a large majority of the content available serves primarily leisure ratherthan educational activities. To put it bluntly, the millions of dollars spent to connect students to theInternet are often put to use supporting online gaming or surfing for trivial facts and gossip.

In sum, although the technology for supporting learning environments has progressed, the proliferation oflearning materials has often lagged behind. The development of computer based learning programs andcontent is an expensive prospect, both in terms of time and money, and the investment is often platformdependent. Furthermore, the power of leveraging information between different parts of the learningenvironment has not been fully tapped or explored. For example, on a college campus, student informationsystems, online library systems, learning platforms, all tend to be separate entities generating their owninformation in isolation from the others.

One of the main problems with learning materials on the Internet, more specifically on the World WideWeb, is the amount of noise that must be waded through before finding something of interest and relevance.Discovering effective learning materials on the web is a difficult process because there is no inherentstructure or standards for describing the available content. The sheer volume of indexed pages limits theutility of full-text search engines for finding desired learning materials.

In addition, the extent of interactivity on the Web was initially limited to clicking through documents orfilling out simple forms. As more interactive technologies have been developed to augment standardHTML, such as JAVA, ActiveX, JavaBeans, Javascript, and dynamic HTML, platform dependence has re-emerged as a problem. Online learning environments are utilizing these technologies to provide some levelof interactive experience; however, the interactive content from one site can not easily be used on anothersite without significant expertise or time. Due to platform dependencies and lack of electronic commercesolutions, there are few incentives for developing and sharing interactive content.

In sum, there are three main obstacles for providing effective online materials and learning environments:• Lack of support for the collaborative and dynamic nature of learning• Lack of standards for locating and operating interactive platform-independent materials• Lack of incentives and structure for developing and sharing content

2.2 The Instructional Management Systems ProjectIn an effort to mitigate the obstacles mentioned above, the Instructional Management Systems (IMS)Project was created by Educom's National Learning Infrastructure Initiative. The project is an investmentmembership of academic, commercial and government organizations dedicated to facilitating the growth andviability of distributed learning on the Internet. The overall goal of the IMS Project is to Enable an Open Architecture for Learning. To this end, the IMS will release a technical specification and a proof of conceptimplementation that will enable the creation of quality learning environments and materials.

By creating a technical specification for learning materials and systems, the IMS provides a commonframework for generating and leveraging information integral to the process of learning. A contentdeveloper may create materials that can be highly customized to unique learners' needs; a teacher may pull



content from a variety of sources and integrate them into one system; a learner may be able to track theirown progress and chart a personalized course through a training program. With a common base line, thedifferent IMS Stakeholders can find innovative ways to add value to the learning environment.

As stated above, the directive of the document that unfolds in subsequent chapters is to provide an openarchitecture for learning. With this goal as the target, developers and consumers of online learningcontent, tools, and systems stand to accrue the following benefits:

• Lower costs for the development and deployment of “learningware”• Improved quality of online learning materials and environments• Greater access to learning opportunities• More customized/flexible learning experiences

2.3 IMS StakeholdersThere are several stakeholders who will be affected by the IMS. We have defined these stakeholders interms of the different roles involved in the process of learning. These roles are often performed by the samestakeholder: someone who is a teacher may also play the role of a learner and vice versa; similarly, acontent provider may also engage in activities associated with the role of a teacher. These stakeholders inthe learning process participate in a number of different communities: universities, community colleges,primary and secondary schools, training programs, testing certification agencies, and enrichment programs,to name a few.

One important phenomenon the IMS recognizes is the dynamic interplay between roles in the learningenvironment. We identify the main stakeholders, and some of their characteristics and activities, below:

• Learners : will range in age, skill level, learning style, and motivation; may or may not beaffiliated with a specific institution or organization; may learn as an individual or as a member of agroup

• Teachers : will possess a range of different teaching styles; may or may not be affiliated with aspecific institution or organization; may teach as an individual or as a member of a group

• Coordinators : may be an academic, professional, community, or private organization; may providecredit for the learning experience; may provide additional services for managing courses andcurricula

• Providers : may be an individual or a group; may or may not be affiliated with a specificprofessional organization or institution; may provide content and/or services; content providedmay be original works (more specific role of an author) or may be aggregated works of others (e.g.publisher role); the provision of content and/or services will vary in terms of the mode of deliveryand contracting arrangements

The IMS Investment Members, as a collective of educational and business organizations, are the architectsof the system requirements for enabling online learning. In order to design a system that accommodates thevarious stakeholders’ needs, the IMS Partnership consists of representatives who play all the stakeholders’roles.

2.4 Background

Although the audience for this document is intended as the technical development community, multipleuser communities have played a part in the development of the IMS Specification. The first step towardgathering the information presented here involved a month long intensive requirements gathering processinvolving representatives of all the different stakeholder groups: developers, administrators and end users ofonline resources and environments. The result of this process was a set of core assumptions andrequirements related to online learning systems and content. These assumptions and requirements havecontinued to be refined and evaluated through focus group meetings, conferences, and other interactionswith end-users of the IMS Specification and conforming IMS materials and environments.



The interest from the end user community (namely, teachers, learners, and administrators of educationalsystems) in the IMS Specification revolved around the Specification's influence on the production ofmaterials and systems that would be easy to use, interoperable, and customizable. Teachers want to beable to find materials easily, manage copyright restrictions, have more powerful tools for responding tolearners needs, and have a greater quantity of excellent content and systems from which to create acustomized environment. Learners want to have more authentic learning experiences and personal controlover their learning process with multiple paths for gaining the skills and experience they seek.Administrators want to provide richer opportunities for their constituents, reach more students, lowerdeployment costs, and leverage the time and money already invested in various technologies.

In addition to interactions with the end-user community, the Specification has also been shaped bydialogues with the technical development community. Many of the investment members and thedevelopment network members who have also invested in the IMS Project have played a critical role indetermining the direction and scope of the specification. Shortly after the requirements gathering process, aseries of technical meetings with the investment members were organized around various areas of thespecification. These meetings pulled from industry experts to explore various strategies and solutions forrepresenting the user requirements in a technical specification and proof of concept prototype.

These technical meetings have continued throughout the development process of the Specification in orderto create something that is sensitive to the current needs and trends in the industry while. At the sametime, however, the Specification needs to be forward thinking and encourage rather than stifle innovation.From the development community, we were charged to create a Specification that built on top of existingstandards, did not require excessive re-engineering of current tools or products, would be scalable androbust enough to grow with the industry, and would allow room for adding value to the base requirements.

2.5 Design Assumptions

From these exchanges with the user community, a conceptual model of online learning has evolved.Online learning is an additional medium for creating environments that are learner focused and driven.Learning online can be used for a range of purposes: from simply delivering content to remote places toparticipating in engaging interactive worlds. Therefore, the conceptual model of online learning that hasdriven the development of this specification is a multi-faceted evolving model.

One of the only constant characteristics of online learning is the constant state of change. People move inand out of different roles from teacher to student to author to publisher to administrator. Styles and theoriesof learning adapt to and shape the use of new technologies. Technology itself is constantly changing and ata very rapid pace. The predominant view of online learning now is one that is web-based, but this willgrow to encompass a myriad of network and intermittent network configurations. The Specification,therefore, needs to account for legacy systems, of technology and processes. In addition, the Specificationmust not preclude but enable innovation.

Despite the inability to articulate one general picture or practice of online learning, at the core of ourconceptual model is the recognition that learning, in all its various forms and mediums, revolves aroundinterchanges in the form of communication or interaction. The main groups identified as IMS Stakeholders(learners, teachers, providers, and coordinators) form a tetrahedron of interchanges that occur throughout thelearning process. There are two basic types of interchanges: between different stakeholders and within eachstakeholder group itself. For example, there are peer to peer interactions among learners, as well asinteractions between learners and teachers, providers, and/or coordinators. What passes between partiesinvolved in an interchange is information, whether in the form of dialogue, a textbook, or a computerprogram. The IMS Specification focuses on providing a standard way for delivering and managing theinformation common in these learning interchanges.



Learning Interchanges

The above diagram depicts the variety of interchanges involved in a learning process.

2.5.1 Content needs to be granular; systems need to be scalable

An understanding of the learning process and environment as a system of interchanges suggests a model ofinterrelated parts. The idea that parts of the learning process and learning materials may be modularizedsupports the shift to a more diversified and learner driven environment where content may be reorganizedfluidly across different learning contexts.

One example of modularization is the popularity of the course packet with specifically selected readings orexercises, over the static and standardized text book. This translates easily to a web environment whereteachers or learners are free to pick content from the myriad of sources available. Another example ofmodularization in the learning process is the ability to offer a certification test at the beginning of a coursethat either passes the student or creates an individualized set of materials and exercises to reach certification.Learning programs do not need to be thought of only at the level of a four year plus degree or even a 16week course. Learning programs may also be thought of as a collection of independent learning unitsallowing different combinations for different contexts and different learners.

The ability to break content down into modular parts and build it back up again within a managementsystem will facilitate increased production of quality learning materials. Development of software tools forteaching and learning and their integration into the learning environment have historically been hamperedby the lack of a commonly accepted specification that would permit them to be readily shared amonginstitutions and across a wide range of technical environments. By supporting a development process thatencourages the reuse of existing materials, development costs will decrease and the incentives for investingin content production with a longer life span will increase.

In addition to benefiting teachers, learners, and developers of online learning resources, the modular natureof these resources also benefits administrators of learning environments. For cost reasons and for comfortreasons, administrators may want to deploy a learning system at a very granular level and then scale up to aorganization wide system. Many schools, training programs, and other educational organizations have



already spent thousands or even millions of dollars to support the technical infrastructure upon which alearning environment can be built. Building this environment in pieces can help defray costs, as long asthere is assurance that the various pieces being built will be compatible. Modularity can also helpmoderate human resource costs, such as technology anxiety or need for retraining. Most likely, onlinelearning materials and systems will be championed by a small sub-set of early adopters withinorganizations. As others become more comfortable with the technology and as the technology andavailable materials improve, more people will be drawn to use the online environment and resources.

2.5.2 Desire for interoperability

A system of modular parts is not as desirable as a system of interoperable modular parts. Being able tobreak materials down into stand-alone pieces is useful, but being able to build these pieces into somethingnew is more valuable. It is the interoperability of modular parts that allows developers to leverage theirexisting work and cut their development costs. Multiple authoring tools may be used to develop contentthat can then be pieced together. Furthermore, interoperability grants a sense of assurance that a tool builtto work within one learning environment will work across multiple environments.

Ultimately, it is the end users of learning materials and environments who stand to gain from aSpecification that promotes interoperability. Teachers and administrators of online environments can investin new resources with a level of assurance that the tools and materials can be used by the widest populationpossible and across multiple contexts. Furthermore, interoperability expands the market which increasesthe quantity of available products. With more competition, producers are required to differentiatethemselves based on quality. Finally, interoperable materials and environments leads to a more integratedand richer learning experience for teachers and learners. A communication tool, for example, can leverageinformation already collected about a group or an individual to allow for personalized experiences.

We should note, however, that although a goal of the Specification is to promote interoperability, this willnot eliminate the potential for incompatible technologies or applications. The degree to which externalapplications (e.g. plug-ins or helper applications) are needed to run content is within the creator’sdiscretion (although the Meta-data Specification will help users identify what content requires additionalhardware or software).

2.5.3 Desire for customization and extensibility

The desire for customization is both complementary to the desire for interoperability and at odds with it.On the one hand, a customized system is permissible through the unique combination of interoperableparts. On the other hand, interoperability requires a level of commonality and standard procedures thatlimits the extent of total customization.

Overall, however, the Specification is being written so as to allow for customization in implementation.The Specification is descriptive rather than prescriptive so that developers are ultimately restrained only bythe needs of their user communities. The core requirements and features of the IMS Specification can beimplemented in multiple ways and developers can further add customized features to increase the value oftheir products. The amount of customizability these products have in the end-users hands is generallydetermined by the market and provided by the content and system developers.

A guiding principle in developing the Specification is that the requirements for online learningenvironments will evolve as the way people learn shapes the technology and the technology shapes the waypeople learn. Furthermore, as indicated previously, there will always be multiple learning styles andneeds. Therefore, the Specification aims to provide a common base from which different learningcommunities can develop their own requirements, policies, and specifications. The Meta-dataSpecification, for example, seeks to articulate a base set of common descriptive terms for locating andmanaging learning resources. This commonality allows for communication across learning communitiesand contexts. We fully expect, however, that different communities of practice will extend the Meta-data



Specification to include terms unique for their own community. Best practices with Meta-data and withother aspects of the Specification may eventually amend the general Specification.

2.5.4 Importance of collaboration

The non-prescriptive nature of the Specification precludes orienting the technical support toward any onepedagogical style or teaching method. However, we have conscientiously included support forcommunication and collaboration. The educators in our requirements gathering process and focus groupsessions all stressed the importance of communication for the learning process. The learning interchangesmentioned above could be considered interchanges of a conversation. The conversation occurs between thelearner and the environment consisting of people and other resources.

Even self-directed learning programs have some type of interaction between the learner and the body ofknowledge or skill sets the learner is trying to acquire. In the workplace, where learning is beingconsidered more of on-the-job performance support versus out-of-the-office training, the rise of groupwaretools speaks to the importance of collaboration for ongoing learning. Many existing instructionalmanagement systems may be considered an extension or applied use of groupware technology.

In traditional classroom environments, the high potential for interaction between peers and mentors is onereason why many have looked upon online learning with concern. The need for supporting richinteractions and exchanges is viewed as an essential aspect of the learning process. Therefore, theSpecification provides explicit support for synchronous and asynchronous communication and the use ofshared artifacts and tools for collaboration.

3 Technical Content

3.1 AssumptionsThe following assumptions about the current and future state of the technical environment in which IMSimplementations will operate have shaped the development of the IMS specifications.

3.1.1 Multiple object models will continue to exist

Currently two Distributed Object Models dominate in the marketplace: Microsoft's Component ObjectModel (COM) and the Object Management Group's (OMG) Common Object Resource Broker Architecture(CORBA). Both of these Models support Java and CORBA will support Java/RMI. Each of these ObjectModels supports a Component Model: ActiveX in COM and JavaBeans in CORBA

3.1.2 CORBA and DCOM bridging capabilities will increase

The computer industry is demanding of OMG and MS interoperability of COM and CORBA-basedobjects. Bridges already exist and MS's active participation via agreements with IONA and other CORBAvendors will increase the capabilities of these bridge products. The existence of these bridges will allowIMS to be technologically neutral thereby allowing developers of component-based content to choosewhichever component model that is appropriate for their target audience.



3.1.3 Use of software agents will increaseSoftware applications that act on the behalf of a user to accomplish some educational or training purposewill increase. Intelligent tutors that augment the role human mentors or authors play in creating andfacilitating an educational experience can be viewed as Software Agents.

3.1.4 Use of virtual reality and immersive environments for online learningwill increase

Currently the Web browser is the window onto Internet content. With the advent of higher bandwidthnetworks, improved standards in network-based multimedia architectures, and ubiquitous higherperformance graphics capability in desktop and laptop computers, the use of immersive environments withhigh quality virtual reality will be used increasingly in online education and training.

3.1.5 Large instructional management systems will face problems similarto large transaction-based systems.

Large management systems with tens of thousands of learners and very large numbers of granular contentwill face technical scaling challenges similar to those of large transactional systems.

3.1.6 HTML remains the most cross-platform formatRendering content in HTML is the most cross platform solution available today. However, it's lack ofinteractivity limits its utility in creating compelling online teaching and learning contexts.

3.1.7 Distributing objects to users will increase

Sending object-based content to the user's desktop computer is problematic due to Java virtual machinedifferences in Netscape and MS web browsers. Network bandwidth, firewalls, and varying performance ofmachines also contributes to difficulties in deploying object-based technology to the desktop. However,these problems will be resolved over time in a broad Internet content and in some situations, such ascompany Intranets, the object deployment problems may be very minor and therefore feasible.

3.1.8 XML will become a dominant standardXML will have a significant impact on the computing marketplace and will be the standard interoperablesyntax for expressing data. XML will also be used to represent collections of objects for transmittal viaubiquitous protocols such as SMTP and HTTP.

3.1.9 Industry support for offline work will increaseLearning and training with network-based resources in an intermittently connected environment will becommonplace. Business travelers, students with laptops, and users with per minute communication tariffs,such as is common in Europe, all have practical and financial reasons to work in an offline mode, thenreconnect to continue their learning. The asynchronicity of this behavior is not limited to learning andtraining. Various industry-wide technical organizations are addressing the technical infrastructure requiredto support intermittent connections. For example, W3C is addressing standardized caching solutions forweb browsers. OMG and Microsoft are working towards support for Asynchronous Method Invocations, anecessary component required for object-based software to work in an offline mode. These new services willbecome transparent through their incorporation in network services layers, operating systems, and webbrowsers.



3.1.10Innovation requires broad areas within which producers in amarketplace can compete.

A vibrant, standards-based marketplace in online learning and training requires that developers of content,services, and management systems have very broad areas within which to innovate and compete. The useof the Internet in training and learning is so new that it is reasonable to assume that the future of onlinelearning and training will be very different than what we can predict today.

3.2 Requirements

3.2.1 Enable innovationThe IMS Specifications are silent on issues of user interface, quality, and teaching/training processes inorder that brisk competition in the marketplace will produce high quality, affordable content, effective userinterfaces and instructionally sound learning processes.

3.2.2 Support ExtensibilitySyntax, semantics, structure, and functions should be extensible allowing for specialization by differentgroups, vendors, and knowledge domains. This applies primarily to meta-data, structured data, andprogrammatic interfaces.

3.2.3 Utilize XMLIMS Specifications will use XML as the serialization syntax for data and objects.

3.2.4 Support dynamic generation of content and dynamic interaction withcontent.

Content developers and publishers will increase their use of technologies that support dynamic generationof content in lieu of unmanageable collections of static web pages. The use of interactive content on theclient will increase. Correspondingly, Web-based content, such as HTML content that requires a round-trip post and response approach with a Web server will decrease in relation to more interactive content.IMS should support this trend through runtime interfaces that allow for client side and client-servertransactions of varying levels of granularity and complexity.

3.2.5 Seed critical data types required to increase interoperabilityExtensibility is the ability of people to provide specializations. As specializations increases,interoperability decreases.

Extensibility is primarily a technical issue that is either present or not in a specification. Interoperabilityis part technology but equally or more so driven by the conformance a community of best practice followsin their reuse of the group's specializations in the development of new content.

The IMS Specification should facilitate interoperability in the context of extensibility by providing bestpractice starting points, such as schemas for content meta-data drawn from collaboration with experts andusers.

3.2.6 Be implementable

Define technical specification that allows a marketplace of online learning to thrive through the activeparticipation by developers representing a broad range of authoring skill levels. The range of programming



skills will vary from document construction, with word processors, spreadsheets, and presentationprograms; visual construction; scripting; and low-level programming in languages such as C++ and Java.

3.2.7 Enable integrated environmentsEnable an IMS environment made up of people, service organizations, tools, content, and data aboutlearners all linked together via the Internet through permanent or sporadic connections. See Figure 1.

Figure 1

People include students, employees, and mentors (i.e. teachers). Mentors might also be smart software,such as intelligent tutors.

Tools include applications for collaboration, general-purpose content analysis or generations, such as aspreadsheet or graphing tool, administrative, and authoring.

Service organizations include schools, training departments, publishers, associations that act as buyingclubs for content for their members, digital libraries, content collection companies that provide reviews andanalysis of content, internet search engine sites that allow for searches of learning content, and datarepository companies that provide hosting of learner data. The types of service organizations will expandas the online marketplace grows.

Learner data is data information about the student learner including preferences, such as learning styles,personal information, such as name and email, performance information, such as what grades and degreesthe student has received, and portfolio information, such as links to content the learner may have created inpast learning processes. The types of information tracked about a student is expected to increase.

Content is the learning materials that a learner uses. The materials can be online, such as web pages andobjects, or they can be online references to physical resources, such as textbooks, audio tapes, etc.

3.2.8 Support offline learning and trainingThe specification should, were possible, address offline work. Efforts of the industry should be leveragedwhere possible.

3.2.9 Reuse existing standards

The IMS specification will reuse relevant industry standards to achieve its design goals and will do so inways that allow for freedom of implementation. That is to say, the IMS Specifications will not pickwinners or align itself with anyone technology camp. If an existing standard supports IMS requirementsand the standard provides sufficient detail to facilitate implementations, then it will be used, perhaps withsome changes to make it implementable in the prevailing industry technologies.



3.2.10Enable scalable implementationsThe specification will avoid creating architectural bottlenecks or impediments to building and deployingscalable implementations.

3.2.11Enable loosely coupled systems

Loosely coupled technical architectures can evolve more easily as individual pieces can be changed withoutbreaking other pieces. The IMS specifications are loosely coupled in order to support evolution withoutcreating significant update burdens on developers of IMS-conforming content and management systems.

3.2.12Enable the de-coupling of content and delivery systems

Figure 2

Enable content from multiple authors to work with multiple management systems without recoding.

3.3 Design

3.3.1 ArchitectureThe following diagram illustrates the overall organization of an IMS System. It shows how an IMSServer interacts with authoring tools, search engines, content servers and profile servers to create apersonalized and powerful learning, teaching, and authoring environment.



The connections between various parts of the Model represent the various types of data exchange andcommunication in the IMS system.

1. A Search Engine may use meta-data information to query a Content Server for specific kinds of learningmaterial.2. A Search Engine may query a Profile Server to find persons with desired skill certifications.3. An authoring tool may query a Profile Server for preference and performance data to customize itspresentation.4. A Search Engine can obtain course meta-data from a Content Server at an organization hosting an IMSserver.5. Authoring tools may exchange content with an IMS Management System.6. Authoring tools may interact with content servers to find or provide content and content meta-data.7. A content server may provide content material to an IMS Management System.8. There will be many content servers reachable by search engines.

The second diagram presents a more detailed view of the IMS Server System showing how it interactswith user clients and organizations through a standard set of IMS interfaces. These interfaces allow clientsto access IMS services through HTTP, RMI, DCOM or CORBA bindings. In the case of HTTP a CGIproxy is provided to mediate communications with the Management System from web pages usingHTML POST commands.



3.3.2 System Model

3.3.3 High Level Service OrganizationThe conceptual design of the IMS Specifications addresses the following five aspects of the online learningmarketplace.

3.3.3.1 Meta-Data

Meta-data are fields and associated values that describe a physical or electronic resource. IMS has definedan extensible collection of meta-data for educational and training resources including, content, performanceitems, performance results, personal information, and certification information.

Dictionary and TypesFor content meta-data, IMS has defined a dictionary and a collection of required and recommended terms forclassifying different types of learning resources.

Meta-data Information SiteThe IMS has developed, with the National Institute of Standards and Technology (NIST), a repository ofmeta-data terms that will be a resource to the broad community of content developers, users, and serviceproviders to facilitate the identification and reuse of common meta-data terms. Common terms simplify theprocess of tagging and discovering learning resources via Internet-based tools. Common terms also enablethe development of technologies that can enhance an online learning experience through automated andintelligent processes (i.e. smart agents, intelligent tutors).



The IMS Meta-data Information Site (temporary url: http://sdct-sunsrv1.ncsl.nist.gov/~boland/ims.html )also includes collections of additional terms that are specialized from the core IMS sets by industry andknowledge domain groups.

The site describes the collections of meta-data terms in both XML and in a variety of object bindings.IMS specifies that content meta-data, when referring to web pages, be stored in a separate file in XMLformat until browsers include support for inline XML.

Relation to ServicesProgrammatic access to meta-data is accomplished through the Property Service, described in the Servicessection of this document and Appendix A..

3.3.3.2 Content

Content interfaces define the actions and responses that IMS-conforming content may perform. In somecases, such as with static HTML content, the content's support of the actions/responses associated with aparticular interface may be inferred by meta-data values and mediated by an IMS-conforming managementsystem.

Content can be an educational objectives or aggregations of objectives. It can be an educational module oraggregations of modules that have an educational or training intent. On the other hand, content can besomething as simple as a word or a picture.

Curriculum GranularityA meta-data field is provided for authors to designate the scope of content within a curriculum. E.g.Course, lesson, topic, etc.

Execution Environment and TechnologyContent can run on the client or on the server. Content can be implemented in whatever technology anauthor desires. E.g. html pages, ActiveX controls, Javabeans, Javascript, executable applications requiringplug-ins, etc. For html-based content, conforming IMS management systems will search and replace IMStokens to dynamically localize html content for that specific management system's CGI URL and thestudent's group and session.

Relation to ServicesContent can makes use of all of the services described in the Services section of this document andAppendix A. The Relationship service is used to represent containment of content within other contentand the sequencing between content.

3.3.3.3 Management Systems

The management interfaces support interoperability and deployment of any IMS-conforming content to anyIMS-conforming management system. Management interfaces will form the skeleton of instructionalmanagement system products that conform to the IMS specification for management software. The IMSspecifications for management software do not specify user interface requirements. It is expected thatmanagement software will be developed with user interfaces appropriate for the market that the developerwishes to address.

Relation to ServicesThe management system implements the IMS Service Specifications that IMS conforming content use.

3.3.3.4 Profiles



Profiles are mobile, user-controlled collections of personal and educational data. Portfolio information maybe stored or referenced within the profile. Preference information such as learning styles, default meta-dataselections may be included. An IMS Profile for a user may include both learner-specific and author-specificinformation since an individual can be both a teacher in one context and a learner in another. Thegranularity of the educational or skill certifications stored in the profile is not specified. Skill certificationscan be digitally signed or not.

Relation to ServicesProfiles are part of Groups/Users/Profiles service. Manipulation of the profile server data is via theProperty Service.

3.3.3.5 External

External interfaces provide a means by which IMS-conforming content and management software canleverage external systems that are likely to be found in an online learning environment such as studentinformation systems, registration systems, electronic commerce systems, and libraries.

IMS is developing a back office implementation guide as a reference for IMS management systemdevelopers to understand the nature of back office systems, with respect to latency of transactions etc., andwhich parts of the IMS object model are affected. See http://www.imsproject.org/specs/backoffice.doc

3.4 Definitions

3.4.1 Containers

Containers encapsulate a given amount of content. Content may consist of primary elements (text,graphics, movies, tools) and/or additional containers. In this way, containers may be added together, oraggregated, within a larger container. In order to facilitate the location, storage, and retrieval of containers,each container will have a set of meta-data fields.

3.4.2 Meta-data

Meta-data is data about data. More specifically, it is descriptive information about a learning resource forthe purpose of finding, using, and/or managing this resource.

3.4.3 Profiles

User profiles are mobile, user-controlled collections of personal and educational data including personalinformation, performance information, and preference information. This data represents a rich resource that auser can draw on to facilitate, customize, and manage his or her learning experience(s).

3.4.4 Aggregation

Combining learning resources or elements together so as to create a new learning resource is consideredAggregation. Whether or not a learning resource may be aggregated with other resources depends upon itsuse rights determined by its creator and/or user rights agent. The opposite of Aggregation isDisaggregation which entails breaking down a learning resource into multiple learning resources.



3.4.5 Sequence

Sequences for learning resources can be defined at two levels. Within a learning resource, the creator mayspecify a sequence between the different elements that make up the learning resource. Between learningresources, for example the resources gathered for a group, the group administrator may also define asequence for navigating through the resources.

3.4.6 Management Software

Management software is a collection of programs to manage the session, resources, tools, and members of agroup.

3.4.7 Notification

A notification message is sent from an application to an event channel when a user has reached an enabledsignpost or triggered an event that another user has requested to be notified of.

3.4.8 Signposts

A signpost is an object associated with a marked point in an application. When the marked point isreached by a user, the signpost is consulted to determine how the notification should be sent and to whom.

3.4.9 more….

3.5 Conformance

A conforming implementation will support the interface methods and properties described in thisspecification. Conformance tests and a testing process are underdevelopment in collaboration with theNational Institute of Standards and Technology (NIST).

Testing will include a combination of self-testing and strict conformance testing. Strict conformance testswill be developed for areas where the underlying technology is not changing rapidly, e.g. meta-data. Self-testing and interoperability guarantees will be recommended for areas where significant industry change isexpected, e.g. distributed object services.

The use of an official IMS logo, designating conformance, will be made available to those products thathave successfully completed conformance testing.

Except for self-testing, conformance testing will be done initially by the IMS Project, but will transition tointernationally sanctioned testing laboratories. The IMS Organization will issue certificates for productsthat have successfully passed conformance testing. A control board will be established for conformancetesting dispute resolution.

3.5.1 Content



Content developers may choose to support whichever IMS interface bindings are appropriate for theirintended market.

3.5.2 Management Systems

Developers of IMS-conforming Management Systems must support one or both of the following sets ofinterface bindings. This is termed the "two-island" approach. Existing and emerging component bridgingproducts will allow management system developers to support both.

3.5.2.1 Island AHTTPCOM

3.5.2.2 Island BHTTPCORBARMI

3.6 Services

3.6.1 Groups/Users/Profiles

3.6.1.1 Group Service Description

3.6.1.1.1 Key Features

The IMS is about creating virtual learning environments. The types envisioned range from on-lineversions of traditional classrooms with twenty or thirty students participating that is augmenting instructorled classroom experience, just-in-time classrooms of one pupil that are created for on-the-job learningscenarios, immersive simulation environments, and many others. The challenge to the IMS is to come upwith a programmatic interface that will allow sufficient generalization for third party tools to be createdwhile leaving wide latitude to implementations. These implementations will be targeting specific marketsand providing competitive differentiation. By far the most prevalent metaphor for managing the interactionof people, content, and tools in the market is the nestable Folder, or Room in the Multi-user ObjectOriented ( MOO ) world. The IMS chose this abstraction since it allows a direct mapping to many, manyproducts in the marketplace, and because it provides a straightforward way of envisioning the types oflearning environments asked for in the requirements.

In the IMS, as in many groupware products today, users participate in a group in the context of a particularrole. For example, in the Biology 101 group, Mary Clark may be playing the role of a student. In thisrespect, she will only have access to those items that are granted to students. In addition, students are anidentifiable group of people, so the teacher can send an e-mail to all of the students without having toaddress them one-by-one. In the Biology Study Group contained in the Biology 101 group, Mary playsthe role of Group Leader. As such, she is able to invite new users into the group, add resources to thegroup, and otherwise manage the group.

The Security Service, in the form of IRole, provides the roles that we are describing here. The roleassignment system takes advantage of the inheritance of roles to make the assignment of privileges asgeneric as possible while allowing access control to be maintained at a fine grained level. For example, anadministrator of an IMS system will create an object supporting IRole for Group Leader. Group Leaderwill be given certain permissions, such as adding users and resources to groups. When assigning aparticular user to a role in a group, the user actually is assigned to an inherited version of the role. In ourstudy group example, Mary Clark plays the role of BiologyStudyGroup::GroupLeader. This way, within



the Biology Study Group she does everything a Group Leader can do. However, within any other Group,her role is not given any permissions.

3.6.1.2 Group Service Structure

3.6.1.2.1 Levels of service

The group service requires all of the interfaces to be implemented except for ICertification.

3.6.1.2.2 Interface Summary

Interface

3.6.1.2.2.1.1 PURPOSE 3.6.1.2.2.1.2 PRIMARY

CLIENTS

IMSGroup::ICertification

Define the behavior of a self-managing certification, forexample, a registration for the baror a medical license.

Clients which must validate a user’scertification before allowing themto proceed.

IGroup Defines the abstract behavior of avirtual classroom or other onlinecollaboration area.

IMS client programs.

IUser Defines the abstract behavior of aperson registered in an IMS system.

IMS Security managers andresources which specialize the userexperience based on the specificuser.

IResourceCoordinator Supports the creation of a virtualschool. Contains operations forcreating and registering users.

IMS client programs.

IMessageChannelManager Supports the creation andmanagement of messages channelsfor the group. These channels areintegrated into the security of thegroup.

Resources and Tools within a groupwhich must emit or consumeinformation via messages.

3.6.2 Sessions

3.6.2.1 Session Service Description


Ensuring a rich, consistent user experience is a goal of the IMS. The IMS is not interested in definingwhat that user experience is, though. We want programs that provide the user experience to have theability to present groups and content from multiple IMS locations and vendors in one consistent view.This view may be via a web browser, or a specialized client program for desktop PCs, or even a specializedtraining interface for an embedded system, such as the display screen on a Global Positioning System (GPS ) receiver. In order to do this, all user interface elements, as well as housekeeping activities such aslogin and preference storage, must be allowed to happen outside of the context of any one IMS managementsystem.

DIAGRAM OF DIFFERENT USER EXPERIENCES

The IMS Session service is designed to allow this de-coupling of user experience from IMS contentsystems. The session service utilizes a Session object to either present the user with a single logon, orcoordinates with the user’s operating system to obtain the user credentials that the user acquired when he orshe logged into the computer ( such as in Window NT or the MIT Kerberos environment ). The Sessionobject then steps through the list of IMS content servers that the user has configured, attaching to each onein turn so that the user can browse them.



An important aspect of a consistent user experience is the resumption of a user’s session after they havesuspended it. This can be because of taking a break, or of moving from home to school. In addition, theuser may resume their session using a different user interface device, such as moving from a desktopcomputer at home to a Personal Digital Assistant at school. Many existing collaboration systems providethis level of consistent user experience. The Microsoft Messaging API ( MAPI ) allows users of MicrosoftOutlook ( a MAPI Client ) to connect and browse in a unified manner Microsoft Exchanges folders, FaxService Folders, Voicemail Folders, and Workflow Folders ( each of these are MAPI Message StoreProviders ).

3.6.2.1.2 Session Service Vs other options

A major decision facing the IMS was whether or not to de-couple the user experience, or session,management from any single IMS server. The two choices available to us are examplified in the groupwaremarketplace today. Most web servers implement session management inside the web server. Webbrowsers make some of this transparent to the user by the use of cookies and certificates. However, there isno session-oriented collaboration between a browser and the web servers to which it has connected. On theother hand, Microsoft Exchange and other Messaging API ( MAPI ) compliant products move the role ofsession management squarely in the camp of the client program, such as Microsoft Outlook. On startup,such a program retrieves a user’s security information and then tries to connect to the message stores thatthe user has configured. It then usually provides a unified User Interface for the user to browse through thedisparate message stores. This later model is the one chosen by the IMS.

It is expected that many web-oriented IMS products will likely have a single web server proxy for thissession management, possibly even providing a common User Interface for disparate IMS systems that auser is connected to. In time, we expect both these server-side products as well as integrated desktops andimmersive worlds to be de-coupled from the content sources that they allow a user to navigate.

3.6.2.1.3 Resolution of technical issues

3.6.2.2 Session Service Structure


There is only a single level of service in the Session service. This service is completely contained in theISession interface.


InterfaceIMSSess ion: : 3.6.2.2.2.1.1 PURPOSE 3.6.2.2.2.1.2 PRIMARY

CLIENTS

ISession Represents a program managing aclient’s user experience in the IMS.

Client programs such as browsers orintegrated desktop environments.

3.6.3 Messages

3.6.3.1 Origin of InterfacesThe following information is based entirely on the Object Management Group’s proposed specification ofthe Common Object Services Notification Service. The only changes that have been made, other than theaddition of IMS context information, is the harmonization of interface signatures with the rest of the IMSand the possible removal of some low level CORBA dependencies.

3.6.3.2 Message Service Description




The IMS Messaging Service provides the communications backbone that allows for dynamic collaborationsbetween learning content, learners, and facilitators. The key elements of a messaging service are channels,managers, quality, and transactions. Message channels are like TV channels in that they allow for thebroadcasting of information to multiple people without the originator having to link up separately witheach person. Event managers keep track of the different message channels that are active and the kinds ofinformation being carried on each channel. They help sources and users of message information to connectto the appropriate channel. Quality is information that tells a channel about how to treat a particularmessage, such as ‘This message should last for two days before being deleted’ or ‘This message must getto all possible recipients’. Transactions are bounded activities that must happen as a unit. Such abounded activity might be the messages that transmit a student’s grades on different sections of a test. It isimportant that the grades for sections 1 and 2 both get to any evaluators. The two messages can be boundup in a transaction so that the publisher of this information can be confident that both parts will reachanyone who is evaluating the grades.

Learning materials need to communicate with one another in order to provide a rich environment to learnersand teachers. For example, a teacher may be facilitating thirty students’ progress through an on-linetutorial. Since the students are distributed by geography and possibly time, the teacher cannot directlyobserve the students’ terminals to assess how the student is doing and provide feedback. It is necessary forthe tutorial to communicate pertinent information about how a student is doing. Such information mightbe that a student has started the tutorial, the student has passed a milestone in the tutorial, or that thestudent is repeating a difficult section of the tutorial and may need help. This type of information theauthor of the tutorial can predict. How that information is used and by whom it is used, however, isunpredictable when the author is creating the tutorial. This is where events, or messages, can come to therescue.

In an event model, an event source such as our tutorial emits some information. It is up to event users toactually do something with an event. Let’s use our example in more detail to show the picture. Let’s saythat our tutorial wants to tell the world about various types of of navigation a student is performing in thetutorial. Those navigation types are Start, Stop, Section Complete, and Section repeat. We can representthese by the following structure:

NavigationEvent{

EventSource ( in our case Tutorial )EventType ( in our case Navigation )EventAction ( either Stop, Start, Section Complete, etc )EventUser ( a student, say Mary )EventComments ( Some descriptive information )

}The Tutorial now has a well-known way to tell the world about what is going on inside of it. In an IMSsystem, the Tutorial program tells the world about this information this way:PSUEDOCODE INSERTION FOR BASIC TYPED PUBLISHThis information allows some third party to create a program that will make use of the event. Let’s taketwo: a class participation program that tracks every student’s activity inside the virtual classroom. Thisprogram gives the teach a rough idea of who is participating and who is not. The second program is anextra help watcher that the teacher uses to notify her of student’s having trouble.

The first program wants to register for all Navigation events that happen in a virtual classroom. It thentakes these events and puts their information into a log that the teach can review later.

PSUEDOCODE INSERTION FOR REGISTER BASIC TYPED SUBCRIBE

The second program also wants to register for Navigation events, however, it is really only interested inNavigation events that have an EventAction of ‘Section Repeat’ so that it can notify the teacher. It can dothis two ways. The first way is to register for all navigation events and then as it receives them, it canlook at the EventAction field and only pay attention to those events with an EventAction of ‘SectionRepeat’.



PSUEDOCODE INSERTION FOR A HANDLER BASED FILTER

If there are a bunch of programs listening to Navigation events and are only interested in ‘Section Repeat’actions, having each one filter the events separately is rather inefficient. Instead the program send a filteralong with its registration for events allows whoever is managing the broadcasting of events to apply thefilter and only send events to the people who are really interested in those events.

PSUEDOCODE INSERTION FOR REGISTER TYPED SUBSCRIBE WITH FILTERING

3.6.3.2.2 Implementation Scenarios

3.6.3.2.2.1 Integrating Collaboration ToolsAlthough there are no explicity recognized Tool objects in the IMS Design specifications, it will becommon to find specialized Resources such as notebooks, schedules, discussion lists, chat spaces,calculators, and other such objects that serve users in this capacity. Tools, like all Resources, operate inthe context of the Group to which they have been added. As a Resource object, they contain references totwo other important objects: their user's current Group and Session. Using the Group reference, tools canacquire a complete list of group members, lists of other resources available to the group, the names of thegroup leaders, the group's private message channels, and much more. By querying their user's Sessionobject they can determine the user's profile, email address and preferences. With this specialized knowledgeIMS tools can configure their options and operations to provide optimal service to their users.

A chat tool, for example, might use one of the group's existing message channels to support itscommunication protocol, and it might use a member's browsing preferences to present either a text or avatarbased interface. A collaborative, multi-user frog dissection program might use one of the group channels fordata exchange or create its notification channel for sending participation notices and session logs to thegroup leader. Discussion lists will use their knowledge of group membership to control what messages arelisted. Tools may also grant or deny use privileges based on their ability to ascertain a user's role in thecurrent group context.

To demonstrate how all this might work, let's imagine that Sally is using a Chat Tool in the context ofher Biology group. After some moments of interacting with the tool and talking to other members of herclass, let's suppose that she asks the Chat Tool to email her a transcript of the discussion she has just had.Here, in pseudocode, are the steps a Chat Tool might take. First, the tool might use the Session object tohelp ascertain Sally's email address:

session = this.getSession();user = session.getUser();email = user.getPreferences().getEmail();

Then the Chat Tool might construct a Notification message adding this address to the Filterable portionof the message body. (See following sections for further discussion of structured event messages.)

message = new Notification();message.setEmailTo(email);message.setBody(transcript);

Then the Chat Tool might find the name of the Biology group's Notification channel.

group = session.getGroup();chan= group.getNChannel();

Finally the Chat Tool might open the notification channel and post the message.

channelmanager = group.getChannelManager();connection = channelmanager.openChannel(chan);channelmanager.send(connection, message);



The message sent to the group's Notification channel might, in this example, be picked up by anappropriate emailing program that is filtering notification messages looking for "EmailTo" fields.

3.6.3.2.2.2 Tracking and NotificationA central requirement for the IMS Management System is that it support asynchronous messaging,notifications, and data exchange between collaborating resource applications. To achieve this goal eachIMS group is required to have access to a Message Channel Manager capable of registering applications tosend or receive structured event messages of well known types. Although applications are permitted toopen channels and exchange information in proprietary ways, it is expected that the greatest degree ofinteroperability between resource applications and the management system will result from the shared use ofconventional message types, either as structured events or as full blown message objects.

Here is a diagram of a generic structured event message. It contains a header and a body. The body maycontain content of any kind. The header is only required to supply the name of an event type and anidentifier for the specific message event. Optional headers permit the inclusion of time stamps, priorityindicators, level of persistence, network routing paths and other name value pairs specified in the referenceAPI. The filterable section of the body provides properties and values that allow receiving applications tofilter out messages in which they have no interest.

Here is an example ofa special kind of IMSStructured EventMessage, theNotification EventMessage. It is astraightforwardmessage TO someonein particular FROMsome application orresource. The eventtype is "Notification"and the event name isa unique identifier forthe message. Thecontent of themessage body isunspecified and couldbe anything.



Messages in the IMS system are organized into an Event Type inheritance hierarchy. Part of this hierarchyis illustrated in the example below showing how Navigational event messages extend, or inherit from, thesimpler Notification event message type. This example is for illustration purposes only, the exacthierarchical structure is still work in progess.

3.6.3.2.2.2.1

USINGSTRUCTUREDEVENTSMESSAGES

Sending andreceivingstructured eventmessages in an

IMS environment will be done by using a set of Message objects. Each of these objects correspond to oneof the IMS recognized event types, such as Notification, Navigation, Assessment, Performance,Collaboration and Administration. These Message objects are similarly arranged in an inheritancehierarchy descending from the root Message object. Objects further down the hierarchy will have additionalmethods for setting and reading specific header values, filter values, and body values.

3.6.3.2.2.2.2 AN EXAMPLE

Let's suppose that a student in a Biology class reaches a certain point in a Frog Dissection resourceapplication marked by an internal signpost and that the application wishes to notify the group leader of thisevent. This event is a special kind of Notification event called a Navigation event. The application firstcreates a NavigationMessage object and gives it a name for future reference and possible acknowledgmentreturn messages.

message = new NavigationMessage("SignPost-4496");

This kind of message automatically includes a TimeStamp field set to the time the message is sent and adelivery priority set to a default of 10. (The highest priority is 0, the lowest is approximately 64,000).The application decides to reset the priority and assigns values to the Filterable data fields.



message.setPriority(5);message.setTo(GRP-LDR); // Message is for the Group Leadermessage.setFrom("R-4337"); // Resource Identifiermessage.setRe("SIGNPOST"); // Contents of Body

Let's assume that the Frog Dissection Resource is communicating with the IMS Management System overthe general Notification channel for the Biology 101 group. In order to send the constructed Navigationmessage to this channel, the application will need to create an IMS ResourceAgent object. TheResourceAgent object is a convenient way for Resources to communicate with the Management System.The ResourceAgent object is not, at this time, part of the standard IMS interfaces. It is only a suggestedsimplification for clients. It contains methods for querying the system to determine information about theresource's group and user and provides an interface to the group's Message Channel Manager. Theapplication can create a new agent and use it to get a reference to the group notification channel.

agent = new ResourceAgent(this.name, this.group);nchannel = agent.getNotificationChannel();

The application then sends the message to this channel.

agent.sendMessage(nchannel, message);

On the receiving end we can imagine that the message is picked up by some application that is expresslyinterested in processing sign post information from this particular resource. This application, let's call itthe "Sign Post Monitor", has registered with the Biology 101 group's Message Channel Manager to listensolely for Navigation events. The monitor employs a further filter to select only those navigation eventsthat constitute signposts and come from resource "R-4337". It does this by checking the name and valuefields in the filterable part of the message body. Finally, because it knows that this message is about signposts it knows to look in the content part of the body to discover WHO reached the particular sign post.

3.6.3.2.3 Message Service Vs other options

The IMS needs a message service that will allow simple and complex exchanges of messages over thenetwork. These exchanges should be secure, atomic, and durable. There are many event models in place intoday’s applications. COM and Java both utilize a form of event delegation. Sources of events simplyworry about emitting the event information. Subscribers of the event information actually implementfeatures that handle the event.

This is what we want, however, the models usually involve a direct connection between the event producerand the users. Both environments, however, lend themselves to the creation of adapters. The conceptualmodel of adapters presented here is taken from Client/Server Programming using Java and CORBA byRobert Orfali and Dan Harkey, Second Edition, 1998. Adapters intersperse themselves between an eventproducer and its consumers via the message channels discussed above. Generic adapters allow messages tobe mapped onto method invocations on the target program instead of simple event handlers. Wiringadapters are a specialization of this that allow visual tool builders to create dynamic invocations betweentwo components by dragging a ‘wire’ connection between them. Distributed adapters allow methodinvocations on remote objects to be mapped to a particular message. In addition, Filtering adapters allowmessages to be pre-filtered before being delivered to targets. This filtering cuts down on the message traffic.In our example above, filters are very important if, in addition to Start and Stop, there were simulation-based tutorials that transmit the spatial location of every user every five seconds. In this case, the ClassParticipation program is interested in the Start and Stop of the simulation, but has no desire to receive thespatial updates. In this scenario, providing filtering adapters could reduce the message traffic by well over99%.

In addition to adapters that allow the message channels to de-couple producers and consumers of messages,it is important to allow for separating in time the production and consumption of a message. Returning toour Tutorial example from above, many of the students may be performing the tutorial at night. Theteacher will not connect up the Class Participation and Extra Help programs until the morning. In thiscase, the message channel needs to be able to save the Navigation messages that were produced the nightbefore until the teacher’s programs have a chance to retrieve them.



These requirements have led us to a distributed messaging queue architecture that supports channels,managers, quality, durability, and transactions. Many of the users of these channels will utilize themthrough the existing event or messaging frameworks that their authoring environment gives them. Forexample, simulations whose navigation and other multi-player information is based on Microsoft’sDirectPlay interfaces will continue to do so. An IMS implementation could provide an implementation ofa DirectPlay provider, moving the simulation information across message channels in a manner transparentto the author of a game.


The current state of the art in distributed message queue architectures is not quite up to providing all ofthese services. The implementation of the messaging interfaces in products is likely to be incremental.The following factors will influence the degree of interoperability provided by message channels as well asthe richness of functionality that those channels can provide:

• Rate of implementation of forthcoming message queue standards. The forthcoming CORBANotification Service provides all of the features that are outlined here. However, all implementations ofthe CORBA Event Service, upon which the Notification Service builds, are still in their infancy.

• Advancement of the capabilities of the Microsoft Message Queue Server interfaces. Currently, theseinterfaces do not have facilities for multi-casting messages or managing the quality attributes ofmessages, especially in the area of message lifecycle. On the other hand, the Message Queue Serverhas extensive support for offline queues, transactions, connectors to existing messaging products, andsecurity. These capabilities should allow it to be built up to the capabilities described in the IMSMessaging interfaces fairly quickly.

• Offline activity on message queues to support offline learning is an area that needs to be understood ingreater detail. The computing industry is making great strides in providing easy to use messagingproducts which provide offline support. However, how this translates into effective informationexchanges between learning resources is another matter.

3.6.3.3 Messaging Service Structure


Since the industry has not delivered messaging solutions that encompass the entire breadth of functionalitydefined by these interfaces, it is likely that organizations will implement the messaging capabilitiesdescribed here in stages. In order for content authors to be able to write content today that will beupwardly compatible in the future, the IMS suggests the following levels of service:

• Level 1: Unstructured messages over non-secure, non-transacted channels. This is the absoluteminimum. Using these features, authors can create messages in which the message body contains anXML or any other text stream. These streams can be based on standard schemas described elsewherein this document. Receiving programs can decode these messages by parsing the text stream andinterpreting the semantics of the information. If an author requires secured communications, themessage body can be encrypted with a digital certificate just as e-mail is encrypted today.

• Level 2: Typed and structured messages, with the possibility of atomic and securable channels. Typedmessages are actual objects, such as the Navigation message defined above. A structured message isone that has the structure, or semantics, of the message declared in the message header, rather thanembedded into the body of the message. Both of these message types lend themselves to being filteredby clients without having to parse or decode the body of the message.

• Level 3: Filterable message channels and publish/subscribe capabilities. Filtering allows clients topush the filtering tasks upstream onto the channel. The allows the channel to optimize the filteringprocess by combining common filter constraints from multiple clients into one filter. Publishing andsubscribing capabilities allow message sources and message consumers to fine-tune their usage of themessage channels. For example, a message source can determine if any clients subscribe to themessages that it produces. If no clients are subscribed, it can refrain from producing the event toincrease performance.




The following interfaces are reproductions of the Object Management Group’s proposed NotificationService. The interface signatures have been harmonized with the other IMS signatures, and elements thatrely on low level CORBA elements have been changed to allow implementations on multiple objectsystems.InterfaceIMSNot i f i cat ion

Purpose Primary Clients

IQoSAdmin Defines operations to manipulatequality of service properties.

Clients manipulating eventchannels

IAdminPropertiesAdmin Defines operations to manipulateadministrative properties of anevent channel.

Clients manipulating eventchannels

IMSNotifyComm::

INotifyPublish Allows suppliers of notifications topublish the names of the types ofmessages it will be supplying.

Resources and Tools which emitinformation via messages ( i.e.,handler implemented by theconsumer, methods called by thesupplier )

INotifySubscribe Allows consumers of notificationsto ask for, or subscribe, toparticular types of notifications.

Resources and Tools which consumeinformation via messages ( i.e.,handler implemented by thesupplier, methods called by theconsumer )

ITxnPushConsumer Defines a push consumer that isunder transactional control andsupports publishing.

Resources and Tools which emitinformation via messages

ITxnPullSupplier Defines a pull supplier that is undertransactional control and supportssubscriptions.

Resources and Tools which consumeinformation via messages

IStructuredPushConsumer Defines a push consumer thatreceives structured events.


ITxnStructuredPushConsumer Extends anIStructuredPushConsumer to includetransactional control.


IStructuredPullConsumer Defines a pull consumer thatreceives structured events.


IStructuredPullSupplier Defines a pull supplier that supportssubscriptions and structured events.

Resources and Tools which consumeinformation via messages

ITxnStructuredPullSupplier Defines a structured pull supplierthat supports transactional control

Resources and Tools which consumeinformation via messages.

IStructuredPushSupplier Defines a push supplier thatsupports subscriptions andstructured events.


ISequencePushConsumer Defines a push consumer whichreceives sequences of structuredevents and supports publishing

Resources and Tools which emitinformation via messages.

ITxnSequencePushConsumer Defines a sequence push consumerunder transactional control


ISequencePullConsumer Defines a pull consumer thatreceives sequences of structuredevents and supports publishing.


ISequencePullSupplier Defines a pull supplier which sendssequences of structured events andsupports subscriptions


ITxnSequencePullSupplier Defines a sequence pull supplierunder transactional control


ISequencePushSupplier Defines a push supplier which sends Resources and Tools which consume



sequences of structured events andsupports subscriptions

information via messages.

IMSNotifyChannelAdmin::

IProxyConsumer Abstract definitions common to allproxy consumers, including QoSadministration and filteradministration.

Implementations of proxyconsumers, such asIStructuredPushConsumer.

IProxySupplier Abstract definitions common to allproxy suppliers, including QoSadministration and filteradministration

Implementations of proxy supplierssuch as IStructuredPushSupplier.

IProxyPushConsumer Supports connections to channelsby suppliers who will push untypedevents onto the channel.


ITxnProxyPushConsumer A proxy push consumer undertransactional control


IStructuredProxyPushConsumer Supports connections to channelsby suppliers who will pushstructured events onto the channel


ITxnStructuredProxyPushConsumer A structured proxy push consumerunder transactional control


ISequenceProxyPushConsumer Supports connections to channelsby suppliers who will pushsequences of structured events ontothe channel.


ITxnSequenceProxyPushConsumer A sequence proxy push consumerunder transactional control


IProxyPullSupplier Supports connections to a channelby consumers who will pull untypedevents from the channel.


ITxnProxyPullSupplier A proxy pull supplier undertransactional control


IStructuredProxyPullSupplier Supports connections to a channelby consumers who will pullstructured events from the channel.


ITxnStructuredProxyPullSupplier A structured proxy pull supplierunder transactional control


ISequenceProxyPullSupplier Supports connections to a channelby consumers who will pullsequences of structured events fromthe channel


ITxnSequenceProxyPullSupplier A sequence proxy pull supplierunder transactional control.


IProxyPullConsumer Supports connections to a channelby suppliers who will make untypedevents available for pulling.


IStructuredProxyPullConsumer Supports connections to a channelby suppliers who will makestructured events available forpulling.


ISequenceProxyPullConsumer Supports connections to a channelby suppliers who will makesequences of structured eventsavailable for pulling.


IProxyPushSupplier Supports connections to a channelby consumers who will be pushed




untyped events.

IStructuredProxyPushSupplier Supports connections to a channelby consumers who will be pushedstructured events.


ISequenceProxyPushSupplier Supports connections to a channelby consumers who will be pushedsequences of structured events.


IConsumerAdmin Defines the behavior for objectsthat create and manage lists ofproxy supplier objects within anevent channel.


ISupplierAdmin Defines the behavior for objectsthat create and manage lists ofproxy consumer objects within anevent channel.


IEventChannel Defines the behaviors of a messagechannel.

Proxy objects, message suppliersand message consumers.

IEventChannelFactory Supports the creation of eventchannels.

Message channel managers.

IMSNoti fyFi l ter: :

IFilter Defines behaviors for objects whichencapsulate message filters

Proxy objects which supportfiltering of messages.

IMappingFilter Allows a filter to map its filtercriteria to different content datathan it was originally written for.

Proxy objects which supportfiltering of messages.

IFilterFactory Defines operations for creatingfilter objects.

Proxy object which supportfiltering of messages.

IFilterAdmin Supports controlling the behaviorand characteristics of filter objects

Proxy objects which supportfiltering of messages

IMSTypedNotifyChannelAdmin: :ITypedProxyPushConsumer Supports connections to channels

by suppliers who will push typedevents onto the channel


ITypedProxyPullSupplier Supports connections to channelsby consumers who will pull typedevents from a channel


ITypedProxyPullConsumer Supports connections to channelsby suppliers who will make typedevents available to a channel.


ITypedProxyPushSupplier Supports connections to channelsby consumers who will be pushedtyped events from a channel.


ITypedConsumerAdmin Defines the behavior for objectswhich create and manage lists ofproxy supplier objects within anevent channel


ITypedSupplierAdmin Defines the behavior for objectswhich create and manage lists ofproxy consumer objects within anevent channel


ITypedEventChannel Defines the behaviors of a messagechannel capable of carrying typedmessages.

Proxy objects and messageconsumers and suppliers.

ITypedEventChannelFactory Supports the creation of typedmessage channels.

Message channel managers.



3.6.4 Relationship

3.6.4.1 Origin of InterfacesThe following information is based entirely on the Object Management Group’s specification of theCommon Object Services Relationship Service. The actual IMS content model objects are modeled withderived versions of Nodes, Relationships, and Graph Traversals. The only changes that have been made,other than the addition of IMS context information, is the harmonization of interface signatures with the restof the IMS and the possible removal of some low level CORBA dependencies.

3.6.4.2 Key FeaturesIn coming up with a content representation model, the IMS was posed with a challenge. The IMSrequirements called for arbitrary aggregation of content that is tied in with an author’s ability to controlsuch aggregation. The content that is part of an aggregation can be a mix of ActiveX, JavaBeans, HTML,and custom executables. The requirements also call for content that can have an arbitrarily complexsequence in which its parts are presented to a learner. This sequence can apply for all instances of alearning resource, instances in a particular virtual classroom, or specialized to a particular learner or smallgroup of learners. In addition, the content and the machines serving up the content to be interacted withwill be distributed across the Internet. The content model must support the creation of curriculums, orobjectives, which can be disseminated as templates to IMS users to fill in with particular learningmaterials. The tools the IMS user has at their disposal should be able to assist the user by locating onlymaterials that satisfy the requirements of the curriculum. Lastly, the content should be combined withpowerful meta-data tagging to allow search and retrieval tools to find and then move the content into avariety of IMS based environments.

In deciding on a content aggregation and sequencing model, the IMS did not want to impose any particularimplementation, instead allowing implementations to be tailored to different run-time requirements. Thereare equally valid IMS implementations that may involve simple aggregations of Web pages to complexaggregations created automatically by applying a curriculum template with fine-grained learning resourcesin a relational database. The IMS system will combine the curriculum template, the learner’s goals andexisting skills, and the content in its repository to create a dynamic learning resource targeted at a particularUser Interface medium. Our goal is to expose such aggregations and sequences to tools via open, powerfulinterfaces that can be mapped onto environment specific implementations.

We have chosen to start from the interfaces of the CORBA Relationship Service. These interfaces allow thefollowing key features of IMS content to be exposed in an interoperable way• Learning information, such as curriculum objectives and learning resources, and the relationships

between such information can be explicitly expressed and navigated• Relationships of arbitrary degree can be defined. This includes the complex relationships between

learner goals, curriculum objectives, and learning materials.• Type and cardinality constraints can be expressed and checked. This allows the rules constraining the

fulfillment of goals and objectives to be expressed to third party tools.• The relationships involved in content aggregation and sequencing can be traversed without activating

the content involved. This allows third-party curriculum and lesson building tools to representvisually the entire scope of material involved without having to have the ability to activate suchmaterial locally inside the authoring tool. This support is critical for de-coupling the construction ofcurriculums and learning experiences from the construction of the content that makes these up.

• Third party tools can create and apply the rules governing the traversal of a sequence of learningresources downstream from the original creation of the content. Thus, the exact sequence a particularstudent experiences can be controlled by a script created by the student’s teacher based on the student’sneeds. The teacher could use any tool capable of creating a CORBA, Java, or ActiveX objectsupporting these interfaces. Such tools range from general tools like Visual Basic and Java Studio tospecialized course creation tools which have a highly visual interface built around the objects of anIMS system.

The following information is reproduced from the Object Management Group’s specification of theCommon Object Services Relationship Service. The end of this section contains the actual IMS contentmodel objects, which are derived versions of Nodes, Relationships, and Graph Traversals.



Distributed objects are frequently used to model entities in the real world. As such, distributed objects donot exist in isolation. They are related to other objects. Consider some examples of real world entities andrelationships:

• A person owns cars; a car is owned by one or more persons.• A company employs one or more persons; a person is employed by one or more companies.• A document contains figures; a figure is contained in a document.• A document references a book; a book is referenced by one or more documents.• A person checks out books from libraries. A library checks out books to people. A book is checked out bya person from a library.

These examples demonstrate several relationships:• Ownership relationships between people and cars• Employment relationships between companies and people• Containment relationships between documents and figures• Reference relationships between books and documents• Check out relationships between people, books and libraries.

Such relationships can be characterized along a number of dimensions:

3.6.4.2.1 Type

Related entities and the relationships themselves are typed. In the examples, employment is an relationshipdefined between people and companies. The type of the relationship constrains the types of entities in therelationship; a company cannot employ a monkey since a monkey is not a person. Furthermore,employment is distinct from other relationships between people and companies.

3.6.4.2.2 The roles of entities in relationships

A relationship is defined by a set of roles that entities have. In an employment relationship, a companyplays an employer role and a person plays an employee role.

A single entity can have different roles in distinct relationships. Notice that a person can play the ownerrole in an ownership relationship and the employee role in an employment relationship.

3.6.4.2.3 Degree

Degree refers to the number of required roles in a relationship. The check out relationship is a ternaryrelationship; it has three roles: the borrower role, the lender role and the material role. A person plays theborrower role, a library plays the lender role and a book plays the material role. Ownership, employment,containment and reference, on the other hand, are of degree 2, or binary relationships.

3.6.4.2.4 Cardinality

For each role in a relationship type, the maximum cardinality specifies the maximum number ofrelationships that may involve that role. The containment relationship is a many-to-one relationship; adocument contains many figures; a figure is contained in exactly one document. A many-to-manyrelationship is between two sets of entities. The ownership example is a many-to-many relationship; aperson can own multiple cars; a car can have multiple owners. The check out relationship is a many-to-one-to-many relationship. A person can check out many books from many libraries. One person from onelibrary checks out a book and a library can loan many books to many people.

3.6.4.2.5 Relationship Semantics

Relationships often have relationship-specific semantics; that is they define operations and attributes. Forexample, job title is an attribute of the employment relationship, while it is not an attribute of anownership relationship. Similarly, due date is an attribute of the check out relationship.

3.6.4.2.6 Key Features of the Relationship Service



• The Relationship Service allows entities and relationships to be explicitly represented. Entities arerepresented as CORBA objects. The service defines two new kinds of objects: relationships and roles. Arole represents a CORBA object in an relationship. Passing a set of roles to a relationship factory creates arelationship.

• Relationships of arbitrary degree can be defined.• Type and cardinality constraints can be expressed and checked. Exceptions are raised when cardinalityand type constraints are violated. The Relationship Service does not define a new type system. Instead, theIDL type system is used to represent relationship and role types. This allows the service to leverageCORBA solutions for type federation.• The Relationship interface can be extended to add relationship specific attributes and operations.Similarly, the Role interface can be extended to add role specific attributes and operations.• The Relationship Service defines three levels of service: base, graph, and specific.• The base level defines relationships and roles.• when objects are related, they form graphs of related objects. The graph level extends the base levelservice with nodes and traversal objects. Traversal objects iterate through the edges of a graph. Traversalsare useful in implementing compound operations on graphs, among other things.• the third level defines specific relationships.A conforming Relationship Service implementation must implement level 1 or levels 1 and 2 or levels 1, 2and 3.• The Relationship Service requires a notion of object identify. As such, it defines a simple, efficientmechanism for supporting object identity in a heterogeneous, CORBA-based environment. We believe themechanism to be of general utility for other services.• Distributed implementations of the Relationship Service can have navigation performance and availabilitysimilar to CORBA object references; role objects can be collocated with their objects and need not dependon a centralized repository of relationship information. As such, navigating a relationship can be a localoperation.• The Relationship Service allows so-called immutable objects to be related. There are no requiredinterfaces that objects being related must support. As such, objects whose state and implementation weredefined prior to the definition of the Relationship Service can be related objects.• The Relationship Service allows graphs of related objects to be traversed without activating relatedobjects.• The Relationship Service is extensible. Programmers can define additional relationships.

3.6.4.2.7 The Relationship Service vs. CORBA Object References

(IMS NOTE: Both JavaBeans and ActiveX Documents and Controls use an embedded object referencemodel for depicting containment relationships. This discussion is roughly applicable to thoseenvironments as well. The IMS is investigating how the Relationship Service compares to the W3CResource Description Format (RDF) model for depicting relationship semantics in a sufficiently powerfulway.)

CORBA: Common Object Request Broker Architecture and Specification defines object references thatclients use to issue requests on objects. Object references can be stored persistently. When is it appropriateto use object references and when is it appropriate to use the Relationship Service? The RelationshipService is appropriate to use when an application needs any of the following capabilities that are notavailable with CORBA object references:

3.6.4.2.7.1 Relationships that Are MultidirectionalWhen objects are related using the Relationship Service, the relationship can be navigated from any role toany other role. The service maintains the relationship between related objects. CORBA object references,on the other hand, are unidirectional. Objects that posses CORBA object references to each other can onlydo so in an ad hoc fashion; there is no way to maintain and manipulate the relationship between theobjects.

3.6.4.2.7.2 Relationships that Allow Third Party Manipulation



Since roles and relationships are themselves CORBA objects, they can be exported to third parties. Thisallows third parties to manipulate the relationship. For example a third party could create, destroy ornavigate the relationship. Third parties cannot manipulate object references.

3.6.4.2.7.3 Traversals that Are Supported for Graphs of Related ObjectsWhen objects are related using the Relationship Service, they form graphs of related objects. Interfaces aredefined by the Relationship Service to support traversing the graph.

3.6.4.2.7.4 Relationships and Roles that Can Be Extended with Attributes and BehaviorRelationships have relationship-specific semantics. For example, the employment relationship has a jobtitle attribute. Since relationships and roles are objects with well-defined OMG IDL interfaces, they can beextended through OMG IDL inheritance to add such relationship-specific attributes and operations.

3.6.4.2.8 Resolution of Technical Issues

3.6.4.2.8.1 Modeling and Relationship SemanticsAn application designer models a problem as a set of objects and the relationships between those objects.Using OMG IDL, the application designer directly represents the objects of the model. Using theRelationship Service, the application designer directly represents the roles and relationships of the model.The Relationship and Role interfaces can be extended using OMG IDL inheritance to add relationship androle specific attributes and operations. For example, a designer might define the employment relationship tohave an operation returning a job title.

3.6.4.2.8.2 Managing RelationshipsThe IRelationshipFactory interface defines an operation to create a relationship, given a set of roles. TheRole and Relationship interfaces define operations to delete and navigate relationships between objects.

3.6.4.2.8.3 Constraining Relationships

Type, cardinality and degree constraints on relationships are expressed in the interfaces. TheIRoleFactory::CreateRole operation can raise a RelatedObjectTypeError exception.This allows implementations of the Role interface to place further constraints on the type of the relatedobjects. For example, an EmployedByRole can ensure related objects are people. An attempt to have itrepresent a monkey would raise a RelatedObjectTypeError exception.

Similarly, the IRelationshipFactory::Create operation can raise a RoleTypeErrorexception. This allows implementations of the Relationship interface to put constraints on the type of theroles. For example an Employment relationship can ensure there is an EmployerRole and anEmployeeRole.The IRelationshipFactory::Create operation can also raise a DegreeError exception. Thisensures that there are the correct number of roles.

The role objects themselves enforce maximum cardinality constraints. A role can raise aMaxCardinalityExceeded exception and refuse to participate in a relationship if its maximumcardinality would be exceeded. Roles define an operation to ask if their minimum cardinality constraint isbeing met.

3.6.4.2.8.4 Referential Integrity

If the Relationship Service is used in an environment supporting transactions, strict referential integrity isachieved. That is, if an related object refers to another (via a relationship), then the other related object willalso refer to it. Without transactions, strict referential integrity cannot be achieved since a failure duringexecution of the relationship construction protocol could cause a dangling reference.

3.6.4.2.8.5 Relationships and Roles as First Class Objects



Our design defines both relationships and roles as first class objects. This is extremely important because itencapsulates and abstracts the state to represent the relationship, allows third party manipulation of therelationship and allows the roles and relationships themselves to support operations and attributes.

3.6.4.2.8.6 Different Models for Navigating and Constructing Relationships

The Relationship Service defines interfaces for constructing and navigating relationships component-by-component. These building block operations can be used by a higher-level service, such as a query service.

3.6.4.2.8.7 Efficiency Considerations

Our design has several features that allow for highly optimized implementations. Performanceoptimizations are achieved by clustering and/or caching of connection information.

Clients can cluster related objects and their roles by their selection of factories. Our design defines thecontainment relationship logically. It does not imply physical clustering of state or execution, However, itserves as a good hint to implementations for clustering. An environment can choose to cluster containersand contained objects. The GetOtherRelatedObject operation can be implemented to cache remoterelated objects. The cached information is immutable; once a relationship is established, the roles and relatedobjects will not change.

3.6.4.2.8.8 Use of Object References for Managing GroupsCurrently, the IMS specification provides that the hierarchy of Groups within an IMS management systemis maintained via object references to a Group’s parent Group and its child Groups. There is no theoreticalreason why the Group structure of an IMS cannot be modeled with relationships as the content structure ishere. The IMS will revisit this issue during the comment period of the specifications.

3.6.4.3 Implementation Scenarios

3.6.4.3.1 Aggregating Materials

An IMS Resource Object extends a node in a Relationship Graph (not to be confused with nodes in anXML document ). By virtue of being a node in such a graph it can participate in many roles with otherResource objects. It can, for example, contain other resources, refer to other resources or be contained by orreferenced by other resources. In the following example we see an IMS Resource named Frog Dissectionthat aggregates two other resources, a Lesson and a Test. The Lesson Resource in turn contains the IntroResource, and it refers to the Lab Resource. Note that Resources can support many roles at the same time.The Lesson resource in this example supports a ContainedInRole ( it is contained in the Frog DissectionResource), a ContainsRole (it contains the Intro), and a ReferencesRole ( it refers to the Lab resource).

The Containment and Relationship roles are the primary relationship types used to satisfy the aggregationrequirements for IMS content.



Let's walk through the steps of creating the Frog Dissection Resource (FDR). We will assume that thisresource is aggregating two already existing resources, the Lesson and the Test which have associated rolesC and F already defined (see diagram). Examining the graph above, we see that the FDR node supportstwo roles, a ContainsRole(A) and a ReferencesRole (D). We will illustrate the creation of the FDR nodeand these two roles using the following pseudo-code.

fdr = new Resource("Frog Dissection"); // create the root node A = fdr.addRole(ContainsRole); D = fdr.addRole(ReferencesRole);

Then we create the Containment and Reference relationships and create links to the Lesson and TestResources.

B = IMSRelationship.create(ContainmentType); E = IMSRelationship.create(ReferenceType); B.addroles(A, C); E.addroles(D, F);

3.6.4.3.2 Higher Level Learning Objects and Objectives

The Relationship graph is capable of representing all levels of learning objects and any learning orperformance objectives that may be associated with them. The diagram below illustrates how a Biologycurriculum might be related to a set of courses.



3.6.4.3.3 Disaggregating and Repurposing Materials

Resources which are represented as Nodes in a Relationship graph are easily repurposed by performingaggregation and disaggregation manipulations on the graph itself without having to alter the content of thematerial itself in any way. Let's imagine that the Test used by the Frog Dissection Resource is, in fact, atest over standard dissection practices that could be used by any resource wishing to assess learners onthese skills. The fact that the Test supports a ReferencedByRole means that it might also be referenced byany number of other resources. In the graph below we show two resources sharing the same dissection test.

3.6.4.3.4 Creating a Sequence through Content

For the Frog Dissection Resource described in the previous section we may wish to control thesequence in which the aggregate parts are visited by a learner, that is, we might wish to insure that theINTRO and LAB are completed before the TEST is taken. Sequence control is managed through the useof the IMS Traversal Interface. This interface is used to traverse graphs of related resource objectsaccording to some traversal criteria which functions as a programmable iterator to determine which node is"next" to be visited from a given node.

There are several built in traversal criteria that can be used for simple cases of tree structuredcontainment such as exist in our example. In our case we can insure that the Resources INTRO, LAB andTEST appear in the correct sequence by using the supplied Depth First Traversal criteria. In morecomplex cases of aggregated Resources developers will use tools to customize and edit the traversal criteriaaccording to previous performance and information culled from a student's profile and personalpreferences.

3.6.4.4 Relationship Service StructureThis section provides information about the levels of service; the specification is organized around theselevels. It also describes the hierarchy of Relationship Service interfaces and explains the main purpose ofeach interface.

3.6.4.4.1 Levels of Service

The Relationship Service defines three levels of service: base relationships, graphs of related objects, andspecific relationships. The specification is organized around these levels.

3.6.4.4.1.1 Level One: Base Relationships



The Relationship and Role interfaces define the base Relationship Service. Figure 9-1 illustrates twoinstances of the containment relationship. The document plays the container role; the figure and the logoplay the containee role. The diamond is an object supporting the IRelationship interface. The small circlesare objects supporting the IRole interface.

Figure 9-1 Base relationships.

Roles represent objects in relationships. Roles have a maximum cardinality. As illustrated, the containerrole can be involved in many instances of a relationship. The containee roles can only be involved in asingle instance of a relationship.

Figure 9-2 illustrates the navigation functionality of relationships; for example the arrow between a role andanother role indicates it is possible to navigate from one role to another. The arrow does not, however,indicate that the object reference to the other role is necessarily stored by the role.

Figure 9-2 Navigation functionality of base relationships.

Table 9-1 lists the interfaces to support relationships and roles.

3.6.4.4.1.2 Level Two: Graphs of Related Objects

Distributed objects do not exist in isolation. They are connected together. Objects connected together formgraphs of related objects. The Relationship Service defines the ITraversal interface. The ITraversal interfacedefines an operation to traverse a graph. The traversal object cooperates with extended roles supporting theIMSGraphs::IRole interface and objects supporting the INode interface.

Figure 9-3 illustrates a graph of related objects. The folder, the figure, the logo and the book all support theINode interface. The small circles are roles supporting the IMSGraphs::IRole interface..

PUT IN FIGURE 9-3 GRAPHS…

Table 9-3 lists the interfaces to support graphs of related objects.

3.6.4.4.1.3 Level Three: Specific Relationships

Containment and reference are two important relationships. The Relationship Service defines these twobinary relationships. Table 9-4 and Table 9-5 list the interfaces defining specific relationships.

3.6.4.4.2 Hierarchy of Relationship Interface

The relationship interfaces are arranged into the interface hierarchy illustrated in Figure 9-4.

3.6.4.4.3 Hierarchy of Role Interface

The role interfaces are arranged into the interface hierarchy illustrated in Figure 9-5.

PUT IN FIGURE 9-5 ROLE INTERFACE HIERARCHY

The IRole interface defines operations to efficiently navigate relationships between related objects.

The IMSGraphs::IRole interface defines an operation to return the edges that involve the role. This is usedby the traversal service defined at the graph level.

Finally, IContainsRole, IContainedInRole, IReferencesRole and IReferencedByRole are specific roles fortwo important relationships: containment and reference.



The IMS is deriving from Node an interface called IResource. This interface adds an object reference for theIGroup that a resource exists within and an object reference for the ISession under which the IResource andits related objects are running. In addition, we are creating relationships to cover aggregation by embeddingand aggregation by reference as well as a relationship to cover sequencing.


The Relationship Service defines interfaces to support the functionality described in section 9.2. Table 9-1through Table 9-5 give high level descriptions of the Relationship Service interfaces.Table 9-1 Interfaces defined in the IMSObjectIdentity moduleInterface Purpose Primary ClientsIMSObjectIdentity::IIndentifiableObject

To determine if two objects areidentical

There are many clients. The graphlevel of the Relationship service isone.

Table 9-2 Interfaces defined in the IMSRelationships moduleInterface Purpose Primary ClientsIMSRelationships::IRelationship

Represents an instance of arelationship type

Clients that navigate betweenrelated objects.

IRelationshipFactory Supports the creation ofrelationships

Clients establishing relationships

Role Defines navigation operations forrelationships. Implements type andcardinality constraints.

Clients that navigate betweenrelated objects.Relationship factories.

IRoleFactory Supports the creation of roles. Objects participating inrelationship.

IRelationshipIterator Iterates the relationships in which aparticular role object participates.

Clients that navigate relationships.

Table 9-3 Interfaces defined in the IMSGraphs moduleInterface Purpose Primary ClientsIMSGraphs::ITraversal

Defines an operation to traverse agraph, given a starting node andtraversal criteria

Clients that want a standard serviceto traverse graphs

ITraversalFactory Supports the creation of a traversalobject

Clients that want a standard serviceto traverse graphs.

ITraversalCriteria Provides navigation behaviorbetween nodes.

Traversal Implementations

IRole Extends theIMSRelationships::IRole interfaceto return edges

Clients that traverse graphs ofrelated objects

IEdgeIterator Returns additional edges from arole.

Clients that traverse graphs ofrelated objects

INodeFactory Supports the creation of nodes. Clients that create nodes in graphs

Table 9-4 Interfaces defined in the IMSContainment moduleInterface Purpose Primary ClientsIMSContainment::Relationship

One-to-many relationship Clients that depend on containmentrelationship type

IContainsRole Represents an object that containsother objects

Clients that navigate containmentrelationships between objects

IContainedInRole Represents an object that itcontained in other objects

Clients that navigate containmentrelationships between objects.

Table 9-5 Interfaces defined in the IMSReference moduleInterface Purpose Primary Clients



IMSReference::Relationship

Many-to-many relationship Clients that depend on the referencerelationship type.

IReferencesRole Represents an object that referencesother objects

Clients that navigate referencerelationships between objects

IReferencedByRole Represents an object that isreferenced by other objects

Clients that navigate referencerelationships between objects

InterfaceIMSObjectIdentity:: 3.6.4.4.4.1.1 PURPOSE 3.6.4.4.4.1.2 PRIMARY

CLIENTS

IIdentifiableObject To determine if two objects areidentical

There are many clients. The graphlevel of the Relationship Service isone.

InterfaceIMSRelat ionsh ips : :Relationship Represents an instance of a

relationship type.Clients that navigate betweenrelated objects.

IRelationshipFactory Supports the creation ofrelationships.

Clients establishing relationships.

IRole Defines navigation operations forrelationships. Implements type andcardinality constraints.

Clients that navigate betweenrelated objects. Relationshipfactories.

IRoleFactory Supports the creation of roles. Objects participating inrelationships.

IRelationshipIterator Iterates the relationships in which aparticular role object participates

Clients that navigate relationships.

InterfaceIMSGraphs::Traversal Defines an operation to traverse a

graph, given a starting node andtraversal criteria.


ITraversalFactory Supports the creation of a traversalobject.


Role Extends theIMSRelationships::IRole interfaceto return edges.

Clients that traverse graphs ofrelated objects.

IEdgeIterator Returns additional edges from arole.


Node Defines operations for a relatedobject to reveal its roles.


INodeFactory Supports the creation of nodes. Clients that create nodes in graphs.

Resource Extends the INode interface.Defines operations that allow alearning resource to navigate intorelationships as well as the rest ofits IMS environment.

Clients and IMS learning resourceswhich wish to access the IGroup andISession objects in which thelearning resource is running.

InterfaceIMSContainment::Relationship One-to-many relationship Clients that depend on the

Containment relationship type.IContainsRole Represents an object that contains

other objects.Clients that navigate containmentrelationships between objects.

IContainedInRole Represents an object that iscontained in other objects.

Clients that navigate containmentrelationships between objects.

Interface



IMSReference::

Relationship Many-to-many relationship Clients that depend on the referencerelationship type.

IReferencesRole Represents an object that referencesother objects.

Clients that navigate referencerelationships between objects.

IReferencedByRole Represents an object that isreferenced by other objects.

Clients that navigate referencerelationships between objects.

3.6.5 Property

3.6.5.1 Origin of InterfacesThe following information is based entirely on World Wide Web Consortium’s ( W3C ) Document ObjectModel. The only changes that have been made, other than the addition of IMS context information, is theharmonization of interface signatures with the rest of the IMS and the possible removal of some low levelW3C dependencies.

3.6.5.2 Property Service Description


The IMS requirements call for managing a great deal of information. Much of this information is quitestructured and is fit to be managed by objects, such as Groups, Message Channels, Security, and so forth.There is a good amount, however, that is quite dynamic, varies from instance to instance, and does notnecessarily impact the fundamental type of an object. For example, two message channels in which onesupports filtering and one does not are two distinct types of Message Channels. There are different, or atleast additional, methods on the objects that are necessary for using them properly. However, two Userobjects, one which supports a simple address and e-mail and the other which supports multiple e-mails,notification preferences, and a preferred learning style are not so clearly different types of objects. It could beargued that the additional information carried by the second profile should be added via a new interface anddefined with IDL. This will work. However, much of the usage and manipulation of this information isup to the program which reads it, and it is likely that highly stylized programs might want to add evenmore information to the profile of their own choosing.In addition to these types of questions, the IMS needed to create interfaces for manipulating meta-data.Meta-data by definition is of unconstrained complexity. Simple meta-data is basic attribute/value pairs.However, the meta-data tagging enabled by the Resource Description Format (RDF) can be quite complex,indeed. In fact, the RDF may be able to rival the proposed Relationship Service in its expressive power.In the end, though, both the simple attribute/value pair meta-data and the RDF meta-data are instances of aMeta-data object as far as the IMS is concerned.The IMS Property Service allows for arbitrarily complex dynamic property sets to be added to a resource,and it allows for arbitrarily complex meta-data to be associated with a resource. The IMS does notstipulate the distinction between attributes that should be defined using the typing system of a target objectenvironment and those that are defined using this interface. Nor does it stipulate the ultimate distinctionbetween meta-data and operation data on objects themselves.

3.6.5.2.2 Property Service Vs other options

Both CORBA and COM provide facilities for associating dynamic information with an object, which doesnot change its fundamental type. The CORBA service in particular is being augmented to include taggedinformation instead of just attribute/value pairs. The basic GetProperty, SetProperty, and AddPropertymethods of IProperty would likely be implemented by these facilities. However, the expressive power ofXML and RDF are envisioned by the IMS as the method of choice for conveying dynamic informationabout objects.The IMS has purposely chosen to promote the use of XML schemas for conveying information that wouldnormally be put in IDL, such as user profile information like learning style, existing skill set, etc. We doso since this type of information is very ill defined in today’s marketplace. IMS will suggest a basic set ofschemas. However, much of the activity over the next few years by vendors will flesh out what these



definitions should be. At that point, it is expected that the IMS will help the industry standardize onXML schemas for the effective interchange of this information.

3.6.5.2.3 Resolution of Technical Issues

Currently, there are no RDF parsers on the market, and the W3C has yet to complete the RDF objectmodel. Therefore, all of the current interfaces proposed are directly in XML. The base sets of meta-data arealso expressed in XML. The IMS does not suggest extending the base IMS meta-data sets until this workis completed. When RDF is completed, the IMS will provide conversion for meta-data objects using thebase sets. Any extended meta-data structures will have to be converted by vendors on their own.

3.6.5.3 Property Service Structure



InterfaceIMSProperty:: 3.6.5.3.2.1.1 PURPOSE 3.6.5.3.2.1.2 PRIMARY

CLIENTS

IProperty Provides for manipulate ofarbitrarily complex dynamicproperty sets, including meta-data

Meta-data tools and learningresources that wish to specializetheir appearance or functionalitybased on user profile information.

The rest of the DocumentObject Model interfaces arenot summarized here.

3.6.6 Security

3.6.6.1 Origin of InterfacesThe following information is based entirely on National Institute of Standards and Technology’s RoleBased Access Control model. The only changes that have been made, other than the addition of IMScontext information, is the harmonization of interface signatures with the rest of the IMS and the possibleremoval of some low level NIST dependencies.

Note on the status of RBAC certification. The Common Criteria for Information Technology SecurityEvaluation (CC) defines the basis for evaluation of security properties of Information Technology producesand systems. The CC is progressing toward international standardization under the auspices of ISO/IEC,JTC 1, SC27/WG3. A CC Protection Profile for RBAC is being developed. Conformance evaluation andtesting of the RBAC Security Service will be available in the future using the CC RBAC ProtectionProfile.

3.6.6.2 Security Service Description


The IMS Security Service Interfaces provides authentication, access control, integrity, and confidentialityservices to IMS Applications. Authentication provides a user’s identity to an application. Access controlenforces access policy on objects given a user’s identity, user attributes, and object attributes. Integrityensures tamper-proof communication. Confidentiality ensures private communication. The Security Serviceinterfaces are designed so that they may be implemented within the commonly available securityenvironments, such as, CORBA and COM.



Authentication mechanisms often differ between security environments. IMS Applications and Objects relyon authentication information provided by means of the Security Service Interfaces. Using the SecurityService Interfaces, an IMS Application or Object is able to:

• Obtain the principal that it represents, i.e., in the name of whom, what organization, or whatsystem process does the IMS Object perform operations.

• Obtain the principal of the application or object requesting its services. The IMS security service uses the Role Based Access Control (RBAC) Model designed by NIST. Accesscontrol to IMS Objects using the NIST RBAC mechanism is provided by the security environment and bythe IMS Object. RBAC is not the only means by which IMS Objects are protected from unauthorizedaccess. Depending on the access policy for an IMS Object, the Object can enforce access control beyond thebasic RBAC mechanism by means of attributes other than roles, e.g., enrollment in a specific class. Someof these additional attributes are made available to an IMS Object through the Profile Service. Using theSecurity and Profile Service Interfaces, an IMS Application or Object is able to:

• Obtain the attributes of the principal that it represents.• Obtain the attributes of the principal of the application or object requesting its services.• Obtain its attributes.• With sufficient privilege, administer access control policy by managing user/role, role/role, and

role/operation relationships.

Using the Security Service Interfaces, an IMS Application or Object is able to make authenticated requeststo IMS Objects. Requests may have integrity and/or confidentiality protection. When secure requests aremade, the responses are equally secure.

3.6.6.2.2 Security Service Vs other options

There are many security environments in common use. Each security environment may have differentmechanisms and algorithms supporting the security services for authentication, access control, integrity,and confidentiality. Each security environment may have different interfaces to those services, interfaces thatare high level and/or low level. For example, CORBA and COM support different security environments.The interfaces to their security services are different. Although a CORBA specification exists forinteroperability between CORBA and COM objects, the CORBA specification does not includeinteroperability of security services.

The IMS Specification includes high level interfaces to security services in order to enhance the portabilityand interoperability of IMS Applications and Objects between different security environments. By using theIMS Security Service Interfaces, IMS Applications and Objects have the opportunity to securelycommunicate between IMS Systems. The IMS Security Service Interfaces are designed so that they may beimplemented within existing security environments using the interfaces of the host environment.

In order to provide a common metaphor for managing access control across different IMS Systems, the IMSSpecification includes interfaces to the Role Based Access Control (RBAC) Model developed by NIST.The RBAC metaphor is natural to the way administrators think of an individual’s relationship to anorganization, i.e., in terms of the job position or roles that an individual has within the organization. WithRBAC, administrators do not have to translate the way they think about individuals’ responsibilities intoan access control mechanism. With RBAC, the natural way of thinking about an organization is the accesscontrol mechanism. As a result, RBAC lowers the cost of administration and makes the process ofadministrating access control policy less error-prone as compared to other access control mechanisms, inparticular, associating users directly with permissions. The NIST RBAC Model supports non-trivial accesscontrol policies while allowing efficient implementation.


The Security Services Interfaces provide the opportunity for portability and interoperability of securityservices between IMS Systems. The Security Services Interfaces of IMS Systems may be implementedusing a variety of mechanisms and algorithms available within the security environment hosting the



implementations. The extent to which IMS Applications and Objects securely interoperate between IMSSystems is determined by the IMS System implementations.

Providing a single authentication mechanism between IMS Systems is a particularly difficult issue. Itrequires consensus among implementers as to which authentication mechanism(s) to support. Organizationsthat require the capability of interoperating with IMS Systems of other organizations may have trustcredentials issued by other organizations.

The use of Public Key Infrastructure (PKI) as a means of authentication between security environments isincreasingly supported and can serve as a means of authentication across IMS Systems implemented indifferent security environments. Public key certificates as a means of authentication can currently be used inmany environments, e.g., HTTP, email, CORBA, COM, and Kerberos. Public key certificates are the onlywidely supported authentication and integrity mechanism for messaging systems such as email. In order touse public key certificates, an organization must invest in the necessary infrastructure. While the technologyto support this infrastructure is available, there are serious organizational and legal policy questions thatmust be decided by an organization before using the technology.

3.6.6.3 Security Service Structure


3.6.6.3.1.1 RBAC0RBAC 0 is the most basic type of role based access control service. It defines the functionality to defineusers and roles without the use of inheritance or separation of duty. These basic services are built on by theother classes of RBAC service.

3.6.6.3.1.2 RBAC1RBAC 1 takes RBAC 0 and adds the notion of inheritance relationships between roles

3.6.6.3.1.3 RBAC2RBAC 2 takes RBAC 0 and adds the notion of separation of duty. Separation of duty establishes mutualexclusion between roles on two levels. Static separation of duty controls how roles are assigned to users. Auser cannot be assigned two roles that are labeled statically separate. Dynamic separation of duty controlshow the active role set is formed for the user. Two roles with dynamic separation cannot both end up in theactive role set.

3.6.6.3.1.4 RBAC3RBAC 3 takes RBAC 0 and includes both inheritance and separation of duty.


InterfaceIMSRBAC:: 3.6.6.3.2.1.1 PURPOSE 3.6.6.3.2.1.2 PRIMARY

CLIENTS

IActiveRoleSet Expose those roles assigned to auser which are in effect for aparticular context.

Access Control List evaluationprograms and securityadministration clients.

IAssignedRoleSet The set of roles directly assigned tothe user.

Security administration clients.

IAuthorizedRoleSet The set of roles associated with theuser, including inherited roles.


IInherit Maps a role to the set of roles fromwhich it inherits.


IOperation Defines a method and the objects onwhich that method can be invoked.

Access Control List evaluationprograms and security



This is the smallest securable unit. administration clients.

IOperationDB Defines the collection of operationsin an RBAC system.


IRBAC0 Defines the most basic behaviors ofan RBAC system.


IRBAC1 Adds the notion of inheritance ofroles to RBAC0


IRBAC2 Adds the notion of separation ofduty to RBAC0


IRBAC3 Combines RBAC0, RBAC1, andRBAC2


IRole Defines a logical group that sharescommon duties. The interfacesupports cardinality constraints.

Security administration clients,notification type messages ( forgeneric targeting of messages )

IRoleDB The collection of roles for an RBACsystem.

Security administration clients

IRoleUserDB The collection of mappingsbetween users and the roles thatthey are assigned.


ISecurity Defines operations that allowaccess to a security principal and toperform private method invocations( i.e., encrypted invocations ).

Resources and Tools that requiresecure communications or explicitauthorization.

ISeparationOfDuty Defines the mapping between a roleand the roles it conflicts with.


ISubject Label’s a user’s security session. Access control list evaluationprograms and securityadministration clients.

IUser Defines a user within the securitysystem. This interface will becombined with the IMSGroup::IUserinterface.

Access control list evaluationprograms and securityadministration clients.

3.6.7 PersistenceThe IMS faces a difficult challenge when it comes to persistence. The industry has many, sometimescompeting, standards around which persistence of data and objects is performed. For traditionalcomponents, such as JavaBeans and ActiveX controls, and compound documents, such as Microsoft Officedocuments, a form of serialization is used. Many existing legacy applications, as well as data driven webpages, use either variants of ODBC or JDBC. Modern object systems or object/relational systems usestandards from the Object Database Management Group to provide interoperability. Lastly, the comingadoption of XML as the data lingua franca has many companies looking at XML based serializationformats. In this atmosphere, the IMS is faced with a few requirements that seem to call for a standardizedpersistence model.First and foremost is the ability for a student to pause their work and resume it at a later time, potentiallyfrom a different workstation. In addition, there is a requirement to easily transfer learning resources, simpleand complex, from one IMS environment to another. Since an IMS learning resource can be a complexgraph of objects, moving it is no mean feat. The IMS in general attempts to decoupage the interface to thevarious components of a learning system from the actual implementations of those components. However,when it comes to allowing an interoperable transfer mechanism, as in the later case, or a user state bucket,as in the former, we are in danger of forcing implementations into a narrow line.Since the industry as a whole has not come up with one common way for persisting objects that works inall cases, the IMS is hoping to use a form of XML serialization to enable the persistence features required inan IMS system. However, the IMS is about transferring objects, not just data. XML currently only dealswith data, though there are a host of options on the horizon for moving objects along with their data viaXML. Microsoft, members of the ODMG, and many others are working on this problem. The IMS hopesto work with the industry to adopt a common XML object serialization format that will allow the



movement of learning resources between IMS implementations. The IMS will not dictate any particularpersistence mechanism once the learning resources are instantiated inside of an IMS implementation.

3.6.8 Digital Commerce

3.6.8.1 Commerce Service Description


3.6.8.1.2 Commerce Service Vs other options


3.6.8.2 Commerce Service Structure



4 Proof of Concept Implementation

4.1 Introduction

4.1.1 Scope and Status of Prototype

The prototype consists of a Management System, Content Server and Profile Server which are intended todemonstrate key areas of the IMS Specifications and to test the viability of the central concepts of the IMSdesign philosophy. The prototype was created as a proof-of-concept implementation and as a platform forfurther experimentation and design refinement.. As a proof-of-concept work the prototype concentrates onthose features of the IMS instructional model which set it apart from existing online instructional platforms.Features commonly found on existing platforms which did not illustrate core requirements or did notrequire innovative approaches were given minimal representation or omitted altogether. The prototypepurposely does not address issues of performance, scalability and ease of use that will be important in thedevelopment of any robust and large scale commercial implementation

4.1.2 Platform requirements

The prototype has been developed using Java and CORBA technologies. To access all the currentprototype features client browsers must support JDK 1.1.5 and RMI which is used to interface applets withCORBA objects running on the server. HTTP communications are handled by servlets running inconjunction with the Java Web Server. The prototype is currently running on an NT Server 4 with 128MB RAM and uses approximately 100 MB disk space. The ORB used for development was Visigenic'sVisibroker.

4.2 User Interface



4.2.1 Logging In

Entry to the prototype is through a log in screen which collects the user's name and password and poststhem to a LogIn servlet. The servlet finds or creates an appropriate User object and stores it with the user'sSession which leverages the Java Web Server's built in session object. The user's start group is looked upand an initial page is generated containing information about the user's current group and its associatedresources, members and tools. A Management Bar appearing on the left side of the main display screenreferences Groups, Resources, Members, Communications, Backpack, and Control Panels.

4.2.2 Groups

The group is the organizing construct in the design of the prototype. A group includes members,resources, tools and subgroups. It has its own dedicated chat and notification channels. Resources andutilities dynamically configure their presentation to the user based in part on group data. From theManagement Bar members, resources, tools and subgroups can be added or edited.

4.2.3 Resources

Resources may be added, accessed and edited from the Management Bar. A resource in the IMS system isrepresented by a Resource Object which contains a reference to the resource's location, the groups it belongsto, its sign posts which govern user notifications and other administrative data. Enabling or disabling aresource's notification events is done through the Management Bar's Control Panel.

4.2.4 Members

A group member has access to all of a group's resources, tools, other members and selected subgroups.From the Management Bar a user can search for other members, list current members or see who ispresently on line.

4.2.5 Communications

Various communication tools are available to group members from the Management Bar. These include athreaded Discussion List, Message Service, and Chat. These utilities differ from common implementationsof these services found on standard online educational platforms in that they leverage information from theiruser's profile and group membership to create dynamic presentations tailored to the individual user. TheMessage Service and Chat make heavy use of CORBA services proxied by the Message Channel ManagerRMI interface.

4.2.6 Backpack

Selecting the Backpack option from the Management Bar displays references to programs and tools thatusers would use to personalize their experience. A user may add his or her favorite tools, such as aCalculator or a Statistics Tool, and carry these tools across different groups.



4.2.7 Control Panel

The Control panel enables the user to edit and control all other Management Bar items.

4.3 Overview of Prototype Architecture

4.3.1 Management

Users are represented by a User object that contains pointers to user profiles, preferences, records, groupmembership and management data. The management of users, groups, and resources is handled by thecentral administrative object called the Coordinator.

4.3.2 Messaging

Support for event notification, asynchronous messaging, and interoperability between applications at thedata exchange level is made possible by a Channel Manager which leverages the Corba Event services.The Channel Manager allows applications to access or create CORBA event channels for asynchronousmessaging and provides methods for sending messages, waiting for messages, or listing existing channels.Each group has a dedicated chat and notification channel and applications may create their own channels forhandling multiuser synchronous collaboration. Applets in browsers may have full access to these functionsthrough an RMI server interface. Web pages can send messages by posting data to a serverCGI_MessageRouter servlet as demonstrated in the tutorial concluding this section.

Messages may be simple or structured. Simple messages may consist of any string, serialized object, orbyte array of data. Structured messages employ the Message object to attach type information to themessage to assist receiving applications in interpreting the message body.

The message channel subsystem can be used to route messages to various channels, users or files.Messages sent to a dedicated router channel are intercepted by the Message Router, a stand alone RMIutility whose only function is to listen for messages and route them to their correct destinations. Therouter checks the message for certain routing information that tells it where the message is to be forwarded.If the routing information indicates that the message is to be sent to a given user the router looks up theuser's notification preferences in the user's profile and makes a best effort attempt at delivery. The mostcommon notification preference will probably be an email address, but might be another named channel orfile name where the message is to be stored.

In the following diagram we see how messages can flow across the system. In this illustration a studenttakes a test presented in a browser window. The test data is sent to a grading application for scoring andthe results are sent to the instructor via email, the instructor's preferred notification method.



1. Answers are Posted to the CGI_MessageRouter on the server.2. The Router forwards the answers to the Test Data channel.3. A grader application monitoring the channel grades the answers.4. The assessment data is sent to the Message Router.5. The Message Router finds the instructor's notification preferences.6. The Message Router emails the assessment to the instructor.

4.3.3 Content

Content is represented by a Resource object which includes information on where the application programis located and methods for setting and getting notification sign posts, and other management data. Anapplication will naturally contain points at which it makes sense to publish event notifications about auser's progress. At such points in the program an appropriate signpost is consulted. The signpostindicates whether the owner or administrator of the resource has elected to enable or disable the resource andwhere the notification message is to be sent. The tutorial which concludes this section demonstrates thestructure of signposts and how they can be created and used in conjunction with the Resource Agent utilityclass.

4.3.4 Content Server

The IMS Content Server is primarily intended to showcase both the use of meta-data for finding learningresources on the World Wide Web and the creation of meta-data for making learning resources easier tofind. The Content Server is a proof-of-concept implementation and not a full blown repository of learningresources. It was created to demonstrate the efficacy of meta-data for accessing learning resources and isintended to support:

• Effective discovery via the Internet of high quality materials for a particular educational or trainingpurpose.

• Management of materials, including intellectual property rights, commerce, and customization oflearning experiences.

• Reuse of educational resources at micro and macro levels. (See http://www.imsproject.org/meta-data)



In the current version of the server, you can create and edit meta-data for learning resources. Youmay also elect to have this meta-data rendered in xml/rdf format for inclusion in a web page or associatedmeta-data file. There are several fields that may be filled out in order to create the meta-data for a learningresource. Here is a partial listing of these fields

locationversion numberformattitleauthorkeywordslanguagesubjectabstractlearning leveleducational objectivesuse timesourceprerequisitesrelationstewarduse rightsprice codecatalog id

4.3.5 Profile ServerThe IMS Profile Server is an independent server accessed by the Management System to create, store, editand retrieve user profiles and records. In the current version of the prototype the interface from theManagement System to the Profile Server is not actively implemented but for testing purposes calls to theProfile Server may be made using a straightforward telnet protocol as outlined in the installationinstructions. The IMS Profile Server supports the following commands:

list-personLists all persons in the personal database.

new-person person-keyCreates a new person record.

open-person person-keyOpens the existing person record.

close-personCloses the current person record.

list-person-fieldLists all the name-value pairs associated with the current person record.

person-put-field name valuePuts the value "value" in the field named "name" for the current person record.

person-get-field nameGets the value associated with the field named "name" for the current person record.

person-delete-field name



Deletes the name-value pair named by "name" for the current person record.

list-performanceLists all the performance records in the database.

new-performance person-key content-key date-time-keyCreates a new performance record based on the primary key

open-performance person-key content-key date-time-keyOpens an existing performance record based on the primary key.

close-performanceCloses the opened performance record.

performance-list-fieldLists all the name-value pairs for the current performance record.

performance-put-field name valuePuts the value "value" in the field named "name" for the current performance record.

performance-get-field name Gets the value associated with the field named "name" .

performance-delete-field nameDeletes the name-value pair named by "name" for the current performance record.

4.4 Prototype API Reference

There are many classes that are useful to programs who wish to construct applications that will interoperatewith the IMS management system. Some of these classes are listed here with a brief description of theirmost useful method calls.

4.4.1 user class

The User represents an individual in the IMS system. Every user has a user profile, preferences, groupmembership, etc. The User object is not persisted by itself, but is persisted through a UserInfo object thatcontains more user tracking information.

User(String userName)Constructor

String getName()Returns the user's login name. Note that this is not the user's "real" name. The real name of user isobtained this way:PersonalData pd = u.getUserProfile().getPersonalData();String fName = pd.getNameFamily(); // family nameString gName = pd.getNameGiven(); // given name(s)

long getID()Returns the user's unique ID by which s/he is identified throughout the system.

UserProfile getUserProfile()Returns the user's UserProfile .

Vector getGroups()



Returns a vector of the user's group memberships.

String getStartGroup()Returns the name of the user's starting group.

void setStartGroup(String groupName)Changes the name of the user's starting group.

void setProfile(String profileServer, long profileID)This method assigns the profile information to the user object.

getPersonalData()

getPreferences()

getRecords()

4.4.2 Group Class

An IMS group represents a collection of people, resources, and additional sub-groups.

Group(String groupName, long parentGroupID)Constructor

Vector getSubgroups()Returns a vector of the identities of the subgroups.

Vector getResources()Returns a vector of the identities of the resources.

String getHomepage()Returns the group's home page (a URL).

void setHomepage(String homepage)Assigns a new home page (URL) for the group.

User getOwner()Returns the user ID of the group's owner.

void setOwner(User owner)Assigns the user ID of the group's owner.

Vector getMembers()Returns a vector of the identities of the group members.

String getCChannel()Returns the name of the group-specific CHAT channel.

String getNChannel()Returns the name of the group-specific notification channel. The notification channel carries managmentstyle signals, such as the addition or removal of members, resources, and subgroups.

void setNChannel(String nChannel)Assigns a new name for the group-specific notification channel.

boolean addMember(User user)Adds a new user to the group, properly updating both the group and the



user record.

boolean removeMember(User user)Removes a user from the group, properly updating both the group and the user record.

void addResource(Resource resource)Adds a resource to the group.

void removeResource(Resource resource)Removes a resource from the group.

void addSubGroup(Group child)Adds the given group to the current group's list of subgroups.

void removeSubGroup(Group child)Removes the given group from the current group's list of subgroups.

4.4.3 UserProfile Class

A UserProfile forms a collection of personal data, user preferences, and certifications. A UserProfile isserialized separately from the User object, but for ease-of-use is loaded and attached to the User object whenthe User object is loaded.

UserProfile(User user)Constructor

PersonalData getPersonalData()Returns the personal data associated with this profile.

Preferences getPreferences()Returns the preferences associated with this profile.

Records getRecords()Returns the user certification records.

4.4.4 Resource Class

An IMS Resource represents a collection of information about a learning resource, an object addressable byURL. Every resource is directly associated with a group and has meta-data associated with it.

Resource(String name, String url)Constructor

String getURL()

void setURL(String url)

Meta-data getMeta-data()

void setMeta-data(Meta-data meta-data)

Vector getSignPosts()Returns a vector of Sign Posts for the resource.

void setSignPosts(Vector signPosts)



Sets the resources vector of sign posts.

Vector getGroups()Returns a list of groups to which this resource belongs.

4.4.5 SignPost Class

A Resource may contain a set of SignPosts which indicate the internal points at which it is willing to postprogress notifications. The user who controls the resource can enable or disable these notifications andchoose where notifications are to be sent. When the resource is activated it consults these signposts at eachpotential notification point. If the SignPost is enabled a notification message is sent to the user, channel orfile indicated by the destination field. The signposts are associated with the Resource object. They may beedited at any time but go into effect on each subsequent activation of the resource. A SignPost contains thefollowing fields:

nameExample: Frog_Dissection_3.5descriptionExample: Send performance score when user has completed the heart dissection.destinationExample: U:Ken_SchwellerenabledExample: true

The user who controls this resource would see this signpost and all the others belonging to the resourcewhen she first adds the resource or invokes a resource editing menu at some later time. The destination andenable fields would, for example, be set by checking them on a form. The Frog Dissection Resource wouldinterpret the signpost in the example above to mean: Notify user Ken_Schweller according to hispersonal notification preferences when the user has reached sign post 'Frog_Dissection_3.5.'

SignPost()Constructor.

SignPost(String sp)Reconstructs a SignPost from its stringified representation.

void setName(String name)

void setDescription(String description)

void setDestination(String destination)Destination may be a (U)ser, (C)hannel, or (F)ile according to the IMS Routing prefix conventions.

void setEnable(boolean enable)

String getName()

String getDescription()

String getDestination()

boolean getEnable()

String toString()Converts the signpost to a string that can be easily transported, stored, or otherwise exchanged betweensystems.



4.5 RMI servers

There are three Java RMI servers that are activated at server start up time. The Message Router has nomethods exposed as User APIs. It creates and continuously monitors a selected message channel. It routeseach message on the channel to its appropriate destination which might be another channel, a file, or a user.In the case of messages directed to users the Router checks the user's notification preferences to determinehow to proceed. Normally the notification would be by email, but forwarding of the message to anotheruser, file, or channel is permitted. Its only method is run().

The IMS Server Coordinator Object represents the management entry point to the IMS system. Onceconnected to the system, through this object, functions such as login(), listUsers(), getGroups(), etc. areavailable, as well as methods to manipulate group membership, group organizational hierarchy, resourcecreation, etc.

4.5.1 Coordinator RMI Interface

void addResource(long resourceID, long groupID)Adds a resource to the indicated parent group.

void addSubgroup(long newgroupID , long parentgroupID)Adds a child group to the indicated parent group.

void addUserToGroup(User user, long groupID)Adds a given user to the group indicated by the ID.

void changePassword(User user, String old, String new, String verify)Changes the password of the given user.

Group createGroup(String groupname)Creates a group.

Resource createResource(String name, String url, long groupID)Creates a resource and add it to a group.

User createUser(String username, String password)Creates a user with password.

void createUserProfile(long userID, String profileServer)Creates a new profile for the given user.

Vector getActiveGroupUsers(long groupID)Returns a vector of User ID's of active group members.

Group getGroup(long groupID)Returns a Group object based on the group's unique ID.

Resource getResource(long resourceID)Returns a Resource object based on the Resource's unique ID.

User getUser(long userID)Returns a User object based on the user's unique ID.

Vector listGroups(String matchSubString)



Returns a list of available groups in the system.

Vector listResources(long groupID, String matchSubString)

Vector listUsers(String matchSubString)Returns a list of available users in the system.

void login(String username, String password)

void logout(User user)

void removeResource(long resourceID, long groupID)Removes a previously added resource from the indicated parent group.

void removeSubgroup(long groupID, long groupID)Removes a previously added child group from the indicated parent group.

void removeUserFromGroup(User user, long groupID)Removes a given user from the group indicated by the ID

void setUserProfile(long userID, String profileServer, long profileID)Assigns an existing profile for the given user.

4.5.2 Channel Manager RMI Interface

boolean openChannel(String channelName)Opens or creates a new Message Channel.

boolean closeChannel(String channelName)Closes named channel if open.

String listChannels()Listsall open channels by name.

boolean isChannelOpen(String channelName)Determines if message channel is available.

String connectChannel(String channelName, int mode)Returns handle to message channel if successful.

boolean disconnectChannel(String connection)Disconnects from named channel.

boolean sendMessage(String connection, String message)Sends asynchronous message to message channel using handle.

String waitMessage(String connection)Synchronous call to message channel. Process waits untila message arrives.

String getMessage(String connection)Synchronous call to message channel. Process returns with or without a message.

boolean isMessageAvailable(String connection)Determines whether a message is available on selected channel.



4.6 Useful Classes

4.6.1 Message Class

This class is useful for creating structured messages to be transmitted over IMS message channels. TheTYPE of a message should, ideally be a common MIME type or expressed in some agreed upon MIMElike format. The BODY of a message is normally plain ascii text or data, however specific applicationsmight serialize objects, convert these to a String form, and push that result through the channel, knowingthat the recipient understands the message type and will take steps to convert the "stringified" and serializedobject back to its original form. Note: XML is the recommended syntax for the character-based messages.

To determine the TYPE and BODY of a message that was received:

Message msg = new Message( myManager.waitMessage( myHandle ) ); String type = msg.getType(); String body = msg.getBody();

To transmit a message with a particular type and body:

Message msg = new Message( "ims-chat/event", "Udo entered chat room" ); myManager.sendMessage( myHandle, msg.toString() );

Message(String type, String body)Constructor

void append(String body)Appends the given body text to the message.

void setType(String type)Assigns a new type to the message format such as "application/purpose" .

void setBody(String body)Assigns a new body to the message.

String getType()Returns the type of the message.

String getBody()Returns the body of the message.

String toString()

4.6.2 Messenger Class

This class provides a convenient interface to the IMS Channel Manager and Message_Router.

Messenger()Constructor

void route(String, Message)Routes a formatted Message to a user, channel, or file .

void route(String, String)Routes a string message to a user, channel, or file using Routing Prefixes.



void routeToChannel(String, Message)Routes formatted Message to named Message Channel.

void routeToChannel(String, String)Routes string message to named Message Channel.

void routeToFile(String, Message)Routes a formatted Message to a named File.

void routeToFile(String, String)Routes a message to a named File.

void routeToUser(String, Message)Routes a formatted Message to a user by name.

void routeToUser(String, String)Routes a string message to a user by name.

void close()Closes messenger and shutsdown connection to ims-router.

4.6.3 Resource Agent

The Resource Agent provides a resource with information about its user's identity and preferences. Itinforms a resource about the group it is in, other group members, which members are active, other groupresources, and available message channels. By extending the Messenger class it provides a means for theresource to send, receive and route messages to other channels, users and files. Finally, it contains methodsfor getting and setting a resource's sign posts.

ResourceAgent(String resourcename, String username,String groupname, String host)Constructor

String getResourceName()

Vector getActiveMembers()Gets IDs of group members currently on line.

Vector getActiveMembersByName()Gets names of group members currently on line.

Vector getSignPosts()Gets the Resource Sign Posts.

void setSignPosts(Vector signposts)Resets the Resource Sign Posts.

String getGroupName()Returns the name of the group.

long getGroupID()Returns the group's unique ID.

Vector getGroupResources()Returns a vector of the identities of the resources.



long getGroupOwner()Returns the user ID of the group's owner.

Vector getGroupMembers()Returns a vector of the identities of the group members.

String getGroupChatChannel()Returns the name of the group-specific CHAT channel.

String getGroupNChannel()Returns the name of the group-specific notification channel.

String getGroupReport()Returns all group data in a formatted report.

String getUserName()Gets the User's Login name.

long getUserID()Gets the User's ID.

String getUserPreferredBrowser()Gets the User's Preferred Browser.

String getUserLanguage()Gets the User's Preferred Language.

String getUserEmail()Gets the User's Email.

void quit()Quits Agent, closes any opened channels.

4.6.4 CGI_MessageRouter

The CGI_MessageRouter is a servlet that responds to cgi post messages from web based applicationsallowing users to send messages via HTTP to the IMS message channels. An example of sending amessage to the server in this fashion is presented in the concluding tutorial.

4.7 Prototype Utility Applications

4.7.1 Chat

The Chat Utility was designed to demonstrate the use of the the Message Channels as a tool for groupcollaboration. This chat is unique in that it does not depend on the use of socket connections to adedicated chat server. Instead, messages from client chat applets are sent by RMI to a group's chat channelmanaged by the CORBA channel manager. The client also monitors this channel to intercept messagesfrom other group members.

4.7.2 Message Board



The Message Board Utility is a basic threaded discussion list configured for each group. The servlet thatmanages the presentation consults each user's session information to determine their current group.

4.7.3 Message Service

The message center allows users to send messages to one another according to the recipients' personalnotification preferences. Messages are posted to a channel monitored by the Router which looks up eachusers notification preferences in their personal profile and attempts to deliver the message accordingly. Note,this is quite different in concept from a simple email center.

4.7.4 Channel Spy

The channel spy utility allows a user to monitor messages sent to designated message channels. It is auseful testing and debugging tool during the application development process.

4.8 Resource Demos

4.8.1 History Test

The History Test demonstrates how data can be posted from an HTML form to an IMS message channelvia a dedicated CGI_MessageRouter Servlet. See Fig. 1 for a diagram of the steps involved.

4.8.2 Collaborative Graph and Monitor

The Collaborative Graph demonstrates synchronous message passing between applications and the use ofnotification sign posts. Two or more students work in separate applications trying to match a mysteryfunction given by their teacher and are able to 'push' functions to each other for viewing. As sign postspreviously enabled by the instructor are encountered by each student notification events are generated andsent to a dedicated channel. This channel is attended by a Monitor program which does a statisticalanalysis on the information received.

4.9 Communicating with the Server: A Brief Tutorial

In this tutorial we will show how to use the Message, Messenger, CGI Message Router, Resource Agent,and Sign Post classes to communicate with the IMS server from various resource applications.

4.9.1 Posting HTML Form data to a Message Channel

For this example let's imagine that we are doing a class survey on TV viewing habits. We plan to collectour data using a simple HTML web form and post the data to a dedicated IMS message channel where aspecial statistics program will capture and summarize the results. We will focus in this example on theclient end of this sequence and show how this posting can be done from the user's browser. We begin bysetting up the following form leaving the form's 'action' value incomplete.

<form method= "post" action= " ??? ">



Enter your name: <input name="name" size="20"> <hr> Which do you prefer? <input type= "radio" name= "music" value= "rock"> rock <input type= "radio" name= "music" value= "jazz"> jazz <hr> Press <input type="submit" value="here"> to submit this data.</form>

To complete the form all we need to know is the URL of the imsserver we are connecting to and the nameof the message channel that is being monitored by the statistics program. Let's suppose that the server is at'www.server.edu' and that we know the statistics program is listening on a channel named 'tv_survey'. Wewould complete the form as follows:

<form method= "post"action= "http://www.server.edu/servlet/cgimessagerouter"> <input type = "hidden" name = "destination" value= "C:tv_survey"> Enter your name: <input name="name" size="20"> <hr> Which do you prefer? <input type= "radio" name= "music" value= "rock"> rock <input type= "radio" name= "music" value= "jazz"> jazz <hr> Press <input type="submit" value="here"> to submit this data.</form>

The action line tells us that we are posting our data to the 'cgimessagerouter' servlet located at'www.server.edu'. The CGI Message Router will examine the hidden destination field to determine howto route the survey data. From the destination value 'C:tv_survey' it will determine that the body of themessage (the name/value form pairs) is to be forwarded to a channel named 'tv_survey'.

We can test whether our form is posting data correctly by monitoring the 'tv_survey' channel with theChannel Spy utility accessible from the management bar of the prototype. Activate the Spy program andset it to the proper channel. After filling in the form in your browser and submitting the data, refresh thewindow containing the Spy program to see the data displayed .

4.9.2 Monitoring the Message Channel

The statistics program introduced in the preceding example needs to monitor the 'tv_survey' messagechannel and update its data base each time it intercepts a message. The following code shows how aTV_SurveyMonitor applet could use a Messenger Object to open a channel for monitoring.

import org.ims.msgchannel.rmi.Messenger;import org.ims.msgchannel.Message;...

public class TV_SurveyMonitor extends Applet implements Runnable{ ... private Thread listener; ...



public void init() { ... }

public void start() { listener = new Thread(this); listener.start(); }

public void run() { Messenger messenger = new Messenger("www.server.edu"); messenger.openChannel("tv_survey"); String mchannel =

messenger.connectChannel("tv_survey", "r"); while(true) { Message msg =

new Message( messenger.waitMessage(mchannel) ); String body = msg.getBody(); updateRecords(body); } }

public void updateRecords(String msg) { ... }}

In this example the applet creates a 'listener' thread to monitor the 'tv_survey' channel. AMessenger object is created to open and connect the applet to the channel. The applet then enters acontinual loop to wait for messages and update database records. Note that because of applet security thisapplet must originate from the same browser which hosts the IMS server.

4.9.3 Creating Signposts

In our final example we show how to add signposts to an existing program. Let's suppose we havewritten a 'Frog Dissection' applet and we wish to publish notifications when users have reached criticalpoints in the program. We can identify each critical point and identify it with a signpost. For example, atthe point where a student has finished dissecting the frog's brain we might like to send a message to hisprofessor that he completed the task with some particular score. Here is some code that illustrates howsuch a signpost might be created.

SignPost sp;sp = new SignPost();sp.setName("Brain Dissection SP");sp.setDescription("Send notification when user finishes dissecting brain.");sp.setDestination(U:Ken Schweller);sp.setEnable(true);



Sign Posts can be named in any way you wish, in this example the sign post is named 'Brain DissectionSP". The description indicates when a notification is to be sent. This information is displayed to userswhen they elect to enable or disable a resource's notifications from the Management bar on the prototypesmain presentation page. The sign post description never appears to a user when the program is actuallyrunning. The destination indicates where the notification is to be sent, in this case to Ken Schwelleraccording to his notification preferences, most likely email. This and any other sign posts created can besaved in a local vector as follows.

Vector signposts = new Vector();signposts.addElement(sp);

When all the sign posts have been created they can be persisted in the associated Resource Object. This ismost easily done using the "setSignPosts" method of the Resource Agent that knows exactly how to findand communicate with the programs associated Resource object.

String host = "www.imsserver.edu";agent = new ResourceAgent("Frog Dissection", null, null, host);agent.setSignPosts(signposts);

When the Frog Dissection program is activated by a user it must reload its sign post data from itsassociated Resource object once again using the Resource Agent. This reloading is necessary sinceindividual signposts may have been either enabled or disabled from the Resource Notifications editor sincethe program was last run.

signposts = agent.getSignPosts();

When the user finishes dissecting the frog brain and it is time to report his score the program composes amessage based on the user's name and score and calls its 'notify' method.

Message msg = new Message(user +" scored " + score+" on brain dissection.");notify("Brain Dissection SP", msg, signposts);

An example notify method is presented below. This method searches for the 'brain dissection' signpost anddetermines whether it is currently enabled. If it is enabled it extracts from the sign post the properdestination and forwards the message to that location.

public boolean notify(String spname, Message msg, Vector signposts){ SignPost sp; for (int i=0; i<signposts.size(); i++) { sp = (SignPost) signposts.elementAt(i); if (sp.getName().equals(spname) && sp.getEnable()) { agent.routeToChannel(sp.getDestination(), msg); } return true; } return false;}



Reference SchemaThis section will contain schemas for Meta-data and other structured data such as test items. The syntaxused in the examples will include XML/RDF and XML-DATA. These and other data classes will bestored online at the IMS/NIST Meta-data Description Repository where they and other schemas used incommunities of best practice will be able to visually and programmatically browse the collections ofschemas.

4.10Meta-data

4.10.1Module

4.10.2Item

4.10.3Tool

4.10.4Course Catalog

4.11Schemas for AssessmentA Schema for Multiple Choice TestsHere is an example of an XML-DATA Schema for a simple Multiple Choice Test. This schema indicatesthat such a test contains an (optional) title and one or more test items. Items themselves consist of anindex number, any number of distractor choices, and the correct answer. This schema is only meant to beillustrative. Actual stored schemas will be developed in conjunction with practitioner experts and ananalysis of common and best practices. Following the schema is an example of how actual test data mightbe packaged for transport.

<?xml:namespace name="urn:uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882/" as="s"/?><s:schema> <elementType id="title"> <string/> </elementType> <elementType id="number">

<string/> </elementType> <elementType id="stem"> <string/> </elementType> <elementType id="distractor"> <string/> </elementType> <elementType id="correct"> <string/> </elementType> <elementType id="item"> <element type="#number"/> <element type="#stem" /> <element type="#distractor" occurs="ONEORMORE"/> <element type="#correct" /> </elementType> <elementType id="mc_test"> <element type="#title" occurs="OPTIONAL"/> <element type="#item" occurs="ONEORMORE"/> </elementType></s:schema>



Here is a short multiple choice test on Midwest Geography based on the XML-Data Schema shown above.For demonstration purposes we can imagine that this schema is available from a repository athttp://www.ims.org/schemas/tests/..

<?xml:namespace name="http://www.ims.org/schemas/tests/" as="test"/><test:GeoTest> <mc_test> <title> Midwest Geography Test </title> <item> <number> 1 </number>

<stem> The Capital of Iowa is </stem> <distractor> Storm Lake </distractor> <distractor> Sioux City </distractor> <correct> Des Moines </correct> </item> <item> <number> 2 </number>

<stem> Lake Okoboji is located in </stem> <distractor> Kansas </distractor> <distractor> Missouri </distractor>

<distractor> Minnesota </distractor> <correct> Iowa </correct>

</item> </mc_test></test:GeoTest>

A Schema for Multiple Choice Test AnswersThe XML-Data Schema for reporting an individual's scores on a multiple choice test might look like this:

<?xml:namespace name="urn:uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882/" as="s"/?><s:schema> <elementType id="title"> <string/> </elementType>

<elementType id="taker"> <string/> </elementType>

<elementType id="date"> <string/> <dataType dt=date.ISO8601"/> </elementType>

<elementType id="giver"> <string/> </elementType> <elementType id="number">

<string/> </elementType> <elementType id="tendered"> <string/> </elementType> <elementType id="correct"> <string/> </elementType> <elementType id="item"> <element type="#number"/> <element type="#tendered" /> <element type="#correct" /> </elementType> <elementType id="mc_test"> <element type="#title" occurs="OPTIONAL" />

<element type="#taker" />



<element type="#date" occurs="OPTIONAL" /><element type="#giver" occurs="OPTIONAL"/>

<element type="#item" occurs="ONEORMORE"/> </elementType></s:schema>

Actual packaged test results would look like this:<?xml:namespace name="http://www.ims.org/schemas/answers/" as="answers"/><answers:GeoTest> <mc_test> <title> Midwest Geography Test </title> <taker> Bob Alcorn </taker> <date> 19980528 </date> <giver> Ken Schweller </giver> <item> <number> 1 </number> <tendered> Storm Lake</tendered>

<correct> Des Moines </correct> </item> <item> <number> 2 </number>

<tendered> Iowa </tendered> <correct> Iowa </correct>

</item> </mc_test></answers:GeoTest>

4.12Schemas for Performance DataPerformance Information may be stored in a User's Profile at any time. The information might describe aperson's performance over an entire academic program, a single course, a single test, or even how the persondid on a single discrete exercise or question. The schema given here illustrates what such a performanceprofile might look like expressed in XML-data.

<?xml:namespace name="urn:uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882/" as="s"/?><s:schema> <elementType id="content-identifier"> <string/> </elementType>

<elementType id="performance-coding"> <string/> </elementType>

<elementType id="performance"> <string/> </elementType>

<elementType id="issued-by"> <string/> </elementType> <elementType id="begin-date-time">

<string/><dataType dt=date.ISO8601"/>

</elementType> <elementType id="end-date-time"> <string/>

<dataType dt=date.ISO8601"/> </elementType> <elementType id="received-by"> <string/>



</elementType><elementType id="certificate-identifier">

<string/> </elementType> <elementType id="item"> <element type="#content-identifier"/> <element type="#performance-coding" /> <element type="#performance" />

<element type="#issued-by"/> <element type="#begin-date-time" occurs="OPTIONAL /> <element type="#end-date-time" occurs="OPTIONAL />

<element type="#received-by" occurs="OPTIONAL /> <element type="#certificate-identifier" occurs="OPTIONAL /> </elementType></s:schema>

Here is an example of how a student's grade on our geology test might be represented as performance datausing the XML-Data Schema above.

<?xml:namespace name="http://www.ims.org/schemas/performance/" as="perf"/><perf:GeoTest>

<item><content-identifier> BVU-GEOLOGY-01-MOD-1234 </content-identifier><preformance-coding> US-NYS-LETTER-GRADE </performance-coding><performance> C </performance><issued-by> BUENA-VISTA-UNIVERSITY </issued-by>

</item></perf:GeoTest>

4.13Schemas for NotificationsNotifications will be delivered over the IMS Message Channel using Structured Event messages as detailedin the API section on Messaging. There will be an inheritance hierarchy of structured event objects andeach of which will also be expressible in XML-Data format. An XML-Data representation of a structuredevent message for notifying professor Schweller about Bob Alcorn's score on the geography test might looklike this:

<?xml:namespace name="http://www.ims.org/schemas/notifications/" as="notif"/><notif:testscore>

<domain-type> EDUCATION </domain-type><event-type> NOTIFICATION </domain-type><event-name> ASSESSMENT </event-name><header>

<to> DR-SCHWELLER </to><from> MW-GEO-TEST </from>

<re> BOB-ALCORN </re></header><filterable-data>

<date> 19980528 </date></filterable-data><body>

<numquest> 2 </numquest><numorrect> 1 </numcorrect>

<pct-score> 50 </pct-score></body>

<notif:testscore>



4.14Schemas for NavigationResources will post Navigation events to the Message Channel when their users reach those parts of thelearning exercise that are marked by Sign Posts. These navigational messages are a special kind ofNotification message and thus will have an XML representation similar to but extending that forNotifications presented above.

<?xml:namespace name="http://www.ims.org/schemas/navigation/" as="nav"/><nav:testscore>

<domain-type> EDUCATION </domain-type><event-type> NOTIFICATION </event-type><event-name> NAVIGATION </event-name><header>

<to> DR-SCHWELLER </to><from> MW-GEO-TEST </from>

<re> BOB-ALCORN </re></header><filterable-data>

<date> 19980528 </date></filterable-data><body> <signpost> START-TEST </signpost>

<starttime> 19981105T08:15:5 </starttime></body>

<nav:testscore>

5 Reference Data ClassesThis section will contain Corba and DCOM IDL for structured data such as test items. These and otherdata classes will be stored online at the IMS/NIST Meta-data Description Repository where they and otherdata classes used in communities of best practice will be able to visually and programmatically browse thecollections of data classes.

5.1 Performance Data

5.2 Notifications

6 References

6.1 Dublin CoreThe Dublin Core Metadata is at http://purl.oclc.org/metadata/dublin_core/

6.2 OMGThe Object Management Group is at http://www.omg.org/

6.3 ODMGThe Object Database Management Group is at http://www.odmg.org/

6.4 W3 RDF and XMLThe World Wide Web Consortium (with links to the Resource Description Format and eXtensible Mark-up Language documentation) is at http://www.W3C.org/



6.5 NIST RBACThe National Institute for Standards and Technology, Role Based Access Control is athttp://hissa.ncsl.nist.gov/rbac/

7 ContributorsThe following people have participated on the IMS Technical team providing input into the Specificationsand prototype development.

Steve Griffin (COLLEGIS Research Institute)Andy Doyle (International Thomson Publishers)Bob Alcorn (Blackboard)Brad Cox (George Mason University)Frank Farance (Farance Inc)John Barkley (NIST)Ken Schweller (Buena Vista University)Kirsten Boehner (COLLEGIS Research Institute)Mike Pettit (Blackboard)Neal Nored (IBM)Tom Rhodes (NIST)Tom Wason (UNC)Udo Schuermann (Blackboard)

8 ThanksMany people have contributed to the development of this technical specification. We would like to thankthe participants of the Requirements meeting, technical meetings, design sessions, and focus group. Wewould also like to thank the Advisory Board members for their support and insight into the progress of theproject's goals:

9 Special ThanksWe'd like to offer special thanks to the following individuals and organizations for their support andguidance:Mark Resmer (California State University - Sonoma)Denis Newman (Center for Distributed Learning)Lou Zweier (Center for Distributed Learning)Rachel Smith (Center for Distributed Learning)Carol Twigg (Educom)Investment Member Companies:Apple ComputerAsymetrixAT&T Learning NetworkBuena Vista UniversityThe California State UniversityCOLLEGISCOLLEGIS Research InstituteCommittee on Institutional Cooperation (CIC)Educational Testing ServiceEmpower CorporationFarance, Inc.George Mason UniversityIBM EducationInternational Thomson PublishingJoint Information Systems Committee (JISC)KPMG Peat Marwick LLP



Miami-Dade Community CollegeMicrosoftNational Institute of Standards and Technology (NIST)OraclePeopleSoftSimon & SchusterSun MicrosystemsUNISYSUniversity of CalifornizUniversity of MichiganUniverstiy of North Carolina at Chapel HillU.S. Department of Defense@learning

10 Appendix A: Interface Descriptions

10.1Group Service Interfaces

10.1.1.1 Interface Descriptions

10.1.1.1.1Module Group

10.1.1.1.1.1The ICertification InterfaceA Certification is an abstract object reference encapsulating the validation that a user holds credentialsgranted to him or her by the certifying agency. The Certification can be self-contained data, including suchthings as expiration date, or it could be an object with a Validate() method which would contact thecertifying agency to check the status of the user's certification.

10.1.1.1.1.1.1 THE USER ATTRIBUTE

This is a reference to the IMSUser that owns this Certification.

10.1.1.1.1.2The IGroup InterfaceThe Group is the central abstraction of the IMS model. A Group is a set of GroupMembers, Resources, andTools that can communicate with one another through a MessageChannel. GroupMembers have differentroles such as leader, TA, learner, guest, etc. which determine their rights to access group tools, resources,and functions.

10.1.1.1.1.2.1 MCHANNELMANAGER

10.1.1.1.1.2.2 MRESOURCECOORDINATOR

This is the ResourceCoordinator that owns the Group

10.1.1.1.1.2.3 MGROUPMEMBERS

These are the GroupMembers that are assigned to this Group.

10.1.1.1.1.2.4 MPARTS

This is the collection of Parts, or Resources, for a group.

10.1.1.1.1.2.5 CREATEGROUP

This method creates a sub-group. The default behavior is to cascade the members from the parent group andnot to cascade the resources from the parent group. If the owner parameter is passed as null, the owner of theparent group is assigned ownership of this group.



10.1.1.1.1.2.6 CREATERESOURCE

This method adds a resource object to a group. The resource object can either be a reference to a resource orthe resource itself, data and all.

10.1.1.1.1.2.7 DELETEGROUP

This method removes a subgroup from a group. All of the contents of the group will be deleted unless thereare imposed constraints due to relationships the sub-group has with other objects in the system.

10.1.1.1.1.2.8 DELETERESOURCE

This method removes a resource from a group. If this is an actual resource, data and all, instead of amoniker resource, then the resource is removed from the IMS system entirely.

10.1.1.1.1.2.9 CREATEGROUPMEMBER

This method associates an User with a group. The member can then be assigned the roles that they play inthe group. These roles are inherited from the generic roles defined in the Role Based Access Control serviceof the ResourceCoordinator. See the documentation of ResourceCoordinator and the associated securityinterfaces for more information.

10.1.1.1.1.2.10 DELETEGROUPMEMBER

This method removes a GroupMember from a group. The User represented by the GroupMember object isnot affected.

10.1.1.1.1.3The IGroupMember Interface

10.1.1.1.1.3.1 MGROUP

This is the group that this group member belongs to.

10.1.1.1.1.3.2 MSESSION

10.1.1.1.1.4The IUser Interface

10.1.1.1.1.4.1 MRESOURCECOORDINATOR

This is the ResourceCoordinator that has control over this User definition.

10.1.1.1.1.4.2 MPERSONALDATA

This is a reference to the PersonalData owned by this User.

10.1.1.1.1.4.3 MPREFERENCES

This is a reference to the Preferences owned by this User.

10.1.1.1.1.4.4 MCERTIFICATIONS

This is a reference to the collection of Certifications owned by this User.

10.1.1.1.1.5The IResourceCoordinator interface

10.1.1.1.1.5.1 MUSERS

This is the collection of users that are defined within this ResourceCoordinator. All assignments of Usersto Groups owned by this ResourceCoordinator must come from this pool.

10.1.1.1.1.5.2 MGROUPS

This is the collection of root level groups owned by a ResourceCoordinator.

10.1.1.1.1.5.3 REGISTERUSER



Create a user in the context of this ResourceCoordinator.

10.1.1.1.1.5.4 SHOWCATALOG

10.1.1.1.1.5.5 ISENROLLED

10.1.1.1.1.5.6 CERTIFYUSER

10.1.1.2 CORBA IDL#ifndef _GROUP_IDL_#define _GROUP_IDL_

module Group{interface Certification{

attribute User mUser;};

interface Group{

exception ObjectNotFound{};

attribute ChannelManager mChannelManager;

attribute ResourceCoordinator mResourceCoordinator;

sequence<GroupMember> mGroupMembers;

sequence<Part> mParts;

Group CreateGroup( in boolean cascadeUsers,in boolean cascadeResources,in User owner );

void CreateResource(in Resource resource);

void DeleteGroup( in Group group )raises( ObjectNotFound );

void DeleteResource(in Resource resource )raises( ObjectNotFound );

GroupMember CreateGroupMember( in User user );

void DeleteGroupMember( in GroupMember groupMember )raises( ObjectNotFound );

};

interface GroupMember{

attribute Group mGroup;

attribute Session mSession;



};

interface User{

attribute ResourceCoordinator mResourceCoordinator;

attribute Property::Property mPersonalData;

attribute Property::Property mPreferences;

sequence<Certification> mCertifications;

};

interface ResourceCoordinator{

sequence<User> mUsers;

sequence<Group> mGroups;

void RegisterUser( in User user );

void ShowCatalog();

boolean IsEnrolled( in User user );

void CertifyUser( in User user );

};

};

#endif // _GROUP_IDL_

10.1.1.3 DCOM IDL

10.2Session Service Interfaces

10.2.1.1 Interface Descriptions

10.2.1.2 CORBA IDL

10.2.1.3 DCOM IDL

10.3Messaging Service Interfaces

10.3.1Origin of InterfacesThe following information is based entirely on the Object Management Group’s proposed specification ofthe Common Object Services Notification Service. The only changes that have been made, other than theaddition of IMS context information, is the harmonization of interface signatures with the rest of the IMSand the possible removal of some low level CORBA dependencies.



10.3.2Interface Descriptions

10.3.2.1 The IMSNotification ModuleThe IMSNotification module defines the Structured Event data type, along with a data type used fortransmitting sequences of Structured Events. In addition, this module provides constant declarations for eachof the standard quality of service (QoS) and administrative properties supported by all Notification Serviceimplementations. Some properties also have associated constant declarations which indicate their possiblesettings. Finally, administrative interfaces are defined for managing sets of QoS and administrativeproperties.

10.3.2.1.1The STRUCTUREDEVENT Data Structure

The STRUCTUREDEVENT data structure defines the fields which comprise a Structured Event. Thefollowing subsections briefly describe each of these fields. A detailed description of Structured Events isprovided in section 2.2.

10.3.2.1.1.1Fixed Header

The following fields make up the fixed portion of the header of every Structured Event.

10.3.2.1.1.1.1 DOMAINTYPE

The domainType field contains a string which identifies the vertical industry domain (e.g.,telecommunications, healthcare, finance, etc.) within which the type of event which characterizes a givenStructured Event is defined. The definition of this field enables each vertical domain to define their own setof event types without worrying about name collisions with those defined by other vertical domains.

10.3.2.1.1.1.2 EVENTTYPE

The eventType field contains a string which identifies the type of event contained within a given StructuredEvent. This name should be unique among all event types defined within a given vertical domain, which isidentified by the domain_type field.

10.3.2.1.1.1.3 EVENTNAME

The eventName field contains a string which names a specific instance of Structured Event. This name isnot interpreted by any component of the Notification Service, and thus the semantics associated with it canbe defined by end-users of the service. This field can be used, for instance, to associate names withindividual Structured Events which can be used to uniquely identify an instance of a particular type ofStructured Event within a given installation of the Notification Service.

10.3.2.1.1.2variableHeader

The remainder of the header of a Structured Event is contained within the variableHeader field. The data typeof this field is a sequence of name-value pairs, where each name is a string and each value a CORBA::Any.While this field can essentially contain any name-value pairs which users of the service deem to be useful toprovide in the header of a Structured Event, standard names and associated value types are defined in Table 2-3 on page 35 of this document. The standard variable header fields defined there provide QoS relatedinformation about the current Structured Event that should override other QoS settings within the channelwhen objects within the channel process the current Structured Event.

10.3.2.1.1.3Body of a Structured Event

The body of a Structured Event is intended to contain the contents of an instance of a Structured Eventbeing published by a Notification Service supplier. It’s contents are broken down into two fields: thefilterableData and the remainderOfBody. The purpose of each of these fields is defined below.

10.3.2.1.1.3.1 FILTERABLEDATA



The filterableData portion of the body of a Structured Event is a sequence of name-value pairs, where nameis of type string and the value is a CORBA::Any. The main purpose of this portion of the event body is toprovide a convenient structure into which event body fields upon which filtering is likely to be performedcan be placed. It is anticipated that mappings of standard event types to the Structured Event will be definedsuch that standard event body field names correspond to values of well-known data types. Examples of suchmappings for common event types used within the Telecommunications industry are provided in section 4of this document. In addition, end users can define their own name-value pairs which comprise the filterableportion of any proprietary event types.

10.3.2.1.1.3.2 REMAINDEROFBODY

The remainderOfBody portion of the event body is intended to hold event data upon which filtering is notlikely to be performed. From a logical point of view, the “interesting” fields of the event data should beplaced into the filterableData portion, and the “rest” of the event placed here. Obviously it is not possible topredict what portion of the event will be interesting (or not) to all consumers. The division of the eventbody within the structured event in this fashion merely provides a hint to consumers. It is still possible toperform filtering on the contents of the remainderOfBody portion of the event body, however this willrequire decomposing the Any data structure which contains this portion into actual typed data elements,using the typecode contained within the Any. Thus filtering on this portion of the event body is likely tobe less efficient than filtering on the filterable_data portion.

10.3.2.1.2The EventBatch Data Type

The IMSNotification module defines the EventBatch data type as a sequence of Structured Events.The IMSNotifyComm module defined in section 3.3 defines interfaces which support the transmissionand receipt of sequences of Structured Events within a single operation. Such a sequence of StructuredEvents transmitted as a unit is referred to as an event batch, and is of the EventBatch data type.

10.3.2.1.3QoS and Administrative Constant Declarations

The IMSNotification module declares several constants related to QoS properties of event transmission,and administrative properties of notification channels. The meanings of each property related to QoS and itsassociated values is described in detail in section 2.5.5 of this document. The meanings of each propertyrelated to channel administration and its associated values is described in section 2.5.7.

10.3.2.1.4The IQoSAdmin Interface

The IQoSAdmin interface defines operations which enable clients to get and set the values of QoSproperties. It also defines an operation that can verify whether or not a set of requested QoS propertysettings can be satisfied, along with returning information about the range of possible settings for additionalQoS properties. IQoSAdmin is intended to be an abstract interface which is inherited by the IProxy,IAdmin, and IEventChannel interfaces defined in the IMSNotifyChannelAdmin andIMSTypedNotifyChannelAmin modules. The semantics of the operations supported by this interfaceare defined below.

10.3.2.1.4.1GetQoS

The GetQoS operation takes no input parameters, and returns a sequence of name-value pairs whichencapsulates the current quality of service settings for the target object (which could be an Event Channel,Admin, or Proxy object).

10.3.2.1.4.2SetQoS

The SetQoS operation takes as an input parameter a sequence of name-value pairs which encapsulatesquality of service property settings that a client is requesting that the target object (which could be an EventChannel, Admin, or Proxy object) support as its default quality of service. If the implementation of thetarget object is not capable of supporting any of the requested quality of service settings, or if any of therequested settings would be in conflict with a QoS property defined at a higher level of the object hierarchywith respect to QoS (see section 2.5.6), the UnsupportedQoS exception is raised. This exception



contains as data a sequence of data structures, each of which identifies the name of a QoS property in theinput list whose requested setting could not be satisfied, along with an error code and a range of settings forthe property which could be satisfied. The meanings of the error codes which might be returned are describedin Table 2-4.

10.3.2.1.4.3ValidateQos

The ValidateQos operation accepts as input a sequence of QoS property name-value pairs which specify aset of QoS settings that a client would like to know if the target object is capable of supporting. If the anyof the requested settings could not be satisfied by the target object, the operation raises theUnsupportedQoS exception. This exception contains as data a sequence of data structures, each of whichidentifies the name of a QoS property in the input list whose requested setting could not be satisfied, alongwith an error code and a range of settings for the property which could be satisfied. The meanings of theerror codes which might be returned are described in Table 2-4. If all requested QoS property value settingscould be satisfied by the target object, the operation returns successfully (without actually setting the QoSproperties on the target object) with an output parameter that contains a sequence of PropertyRange datastructures. Each element in this sequence includes the name of a an additional QoS property supported bythe target object which could have been included on the input list and resulted in a successful return fromthe operation., along with the range of values that would have been acceptable for each such property.

10.3.2.1.5The IAdminPropertiesAdmin Interface

The IAdminProperitesAdmin interface defines operations which enable clients to get and set the valuesof administrative properties. This interface is intended to be an abstract interface which is inherited by theEvent Channel interfaces defined in the IMSNotifyChannelAdmin andIMSTypedNotifyChannelAmin modules. The semantics of the operations supported by this interfaceare defined below.

10.3.2.1.5.1GetAdmin

The GetAdmin operation takes no input parameters, and returns a sequence of name-value pairs whichencapsulates the current administrative settings for the target channel.

10.3.2.1.5.2SetAdmin

The SetAdmin operation takes as an input parameter a sequence of name-value pairs which encapsulatesadministrative property settings that a client is requesting that the target channel support. If theimplementation of the target object is not capable of supporting any of the requested administrative propertysettings, the UnsupportedAdmin exception is raised. This exception has associated with it a list ofname-value pairs of which each name identifies an administrative property whose requested setting could notbe satisfied, and each associated value the closest setting for that property which could be satisfied.

10.3.2.2 The IMSNotifyFilter ModuleThe IMSNotifyFilter module defines the interfaces supported by the filter objects used by theNotification Service. Two different types of filter objects are defined here. The first type support the IFilterinterface and encapsulate the constraints which will be used by a proxy object associated with a notificationchannel in order to make decisions about which events to forward, and which to discard. The second typesupport the IMappingFilter interface and encapsulate constraints along with associated values, wherebythe constraints determine whether a proxy object will alter the way it treats each event with respect to aparticular property of the event, and the value specifies the property value the proxy would apply to eachevent which satisfies the associated constraint. In addition to the two types of filter object interface definedin this module, the IMSNotifyFilter module also defines the IFilterFactory interface which supportsthe operations required to create each type of filter object, and the IFilterAdmin interface which supportsoperations which enable an interface (IProxy or IAdmin) which inherits it to manage a list of IFilterinstances.

10.3.2.2.1The IFilter Interface



The IFilter interface defines the behaviors supported by objects which encapsulate constraints used by theproxy objects associated with an event channel in order to determine which events they receive will beforwarded, and which will be discarded. Each object supporting the IFilter interface can encapsulate asequence of any number of constraints. Each event received by a proxy object which has one or moreobjects supporting the IFilter interface associated with it must satisfy at least one of the constraintsassociated with one of its associated IFilter objects in order to be forwarded (either to another proxy objector to the consumer, depending on the type of proxy the filter is associated with), otherwise it will bediscarded. Each constraint encapsulated by a filter object is a structure comprised of two main components.The first component is a sequence of data structures, each of which indicates an event type comprised of adomain and a type name. The second component is a boolean expression over the properties of an event,expressed in some constraint grammar (more on this below). For a given constraint, the sequence of eventtype structures in the first component nominates a set of event types to which the constraint expression inthe second component applies. Each element of the sequence can contain strings which will be matched forequality against the domainName and typeName fields of each event being evaluated by the filter object, orit could contain strings with wildcard symbols (*), indicating a pattern match should be performed againstthe type contained in each event, rather than a comparison for equality when determining if the booleanexpression should be applied to the event, or the event should simply be discarded without even attemptingto apply the boolean expression. Note that an empty sequence included as the first component of aconstraint implies that the associated expression applies to all types of events, as does a sequence comprisedof a single element whose domain and type name are both set to either the empty string or else the wildcardsymbol alone contained in quotes. The constraint expressions associated with a particular object supportingthe IFilter interface are expressed as strings which obey the syntax of a particular constraint grammar (i.e.a BNF). Every conformant implementation of this service must support constraint expressions expressed inthe default constraint grammar described in section 2.4. In addition, implementations may support otherconstraint grammars, and/or users of this service may implement their own filter objects which allowconstraints to be expressed in terms of an alternative constraint grammar. As long as such user-defined filterobjects support the IFilter interface, they can be attached to Proxy or Admin objects in the same fashionas the default IFilter objects supported by the implementation of the service are, and the channel should beable to use them to filterevents in the same fashion. The IFilter interface supports the operations requiredto manage the constraints associated with an object instance which supports the interface, along with areadonly attribute which identifies the particular constraint grammar in which the constraints encapsulatedby this object have meaning. In addition, the IFilter interface supports three variants of the matchoperation which can be invoked by an associated proxy object upon receipt of an event (the specific variantselected depends upon whether the event is received in the form of an Any, a Structured Event, or a TypedEvent), to determine if the event should be forwarded or discarded, based on whether or not the eventsatisfies at least one criteria encapsulated by the filter object. The IFilter interface also supportsoperations which enable a client to associate with the target filter object any number of “callbacks” whichare notified each time there is a change to the list of event types which the constraints encapsulated by thefilter object could potentially cause proxies to which the filter is attached to receive. Operations are alsodefined to support administration of this callback list by unique identifier. The operations supported by theIFilter interface are described in more detail within the following subsections.

10.3.2.2.1.1constraintGrammar

The constraintGrammar attribute is a readonly attribute which identifies the particular grammar withinwhich the constraint expressions encapsulated by the target filter object have meaning. The value of thisattribute is set upon creation of a filter object instance, based on the input provided to the factory creationoperation for the filter instance.

The dependency of a filter object on its constraints being expressed within a particular constraint grammarmanifests itself within the implementation of the Match operations described below, which must be able toparse the constraints to determine whether or not a particular event satisfies one of them.



Every conformant implementation of the Notification Service must support an implementation of theIFilter interface which supports the default constraint grammar described in section 2.4. The value whichthe constraintGrammar attribute is set to in the case the target filter object supports this default grammarwill be “EXTENDED_TCL”. In addition, implementations and/or end users may provide additionalimplementations of the IFilter interface which support different constraint grammars, and thus would setthe constraintGrammar attribute to a different value upon creation of such a filter object.

10.3.2.2.1.2AddContraints

The AddConstraints operation is invoked by a client in order to associate one or more new constraints withthe target filter object. The operation accepts as input a sequence of constraint data structures, each elementof which consists of a sequence of event type structures and a constraint expressed within the constraintgrammar supported by the target object. Upon processing each constraint, the target object associates anumeric identifier with the constraint that is unique among all constraints it encapsulates. If any of theconstraints in the input sequence is not a valid expression within the supported constraint grammar, theInvalidConstraint exception is raised. This exception contains as data the specific constraint expressionthat was determined to be invalid. Upon successful processing of all input constraint expressions, theAddConstraints operation returns a sequence in which each element will be a structure including one of theinput constraint expressions, along with the unique identifier assigned to it by the target filter object.

Note that the semantics of the AddConstraints operation are such that its side-effects are performedatomically upon the target filter object. Once add_constraints is invoked by a client, the target filter objectis temporarily disabled from usage by any proxy object it may be associated with. The operation is thencarried out, either successfully adding all of the input constraints to the target object or none of them (in thecase one of the input expressions was invalid). Upon completion of the operation, the target filter object iseffectively re-enabled and can once again be used by associated filter objects in order to make eventforwarding decisions.

10.3.2.2.1.3ModifyConstraints

The ModifyConstraints operation is invoked by a client in order to modify the constraints associated withthe target filter object. This operation can be used both to remove constraints currently associated with thetarget filter object, and to modify the constraint expressions of constraints which have previously been addedto the target filter object.

The operation accepts two input parameters. The first input parameter is a sequence of numeric valueswhich are each intended to be the unique identifier associated with one of the constraints currentlyencapsulated by the target filter object. If all input values supplied within a particular invocation of thisoperation are valid, then the specific constraints identified by the values contained in the first inputparameter will be deleted from the list of those encapsulated by the target filter object.

The second input parameter to this operation is a sequence of structures, each of which contains a constraintstructure and a numeric value. The numeric value contained by each element of the sequence is intended tobe the unique identifier associated with one of the constraints currently encapsulated by the target filterobject. If all input values supplied within a particular invocation of this operation are valid, then theconstraint expression associated with the already encapsulated constraint identified by the numeric valuecontained within each element of the input sequence will be modified to the new constraint expression thatis contained within the same sequence element.

If any of the numeric values supplied within either of the two input sequences does notcorrespond to theunique identifier associated with some constraint currently encapsulated by the target filter object, theConstraintNotFound exception is raised. This exception contains as data the specific identifier whichwas supplied as input but did not correspond to the identifier of some constraint encapsulated by the targetobject. If any of the constraint expressions supplied within an element of the second input sequence is not avalid expression in terms of the constraint grammar supported by the target object, the



InvalidConstraint exception is raised. This exception contains as data the specific constraint that wasdetermined to be invalid. Note that the semantics of the ModifyConstraints operation are such that its side-effects are performed atomically upon the target filter object. Once ModifyConstraints is invoked by aclient, the target filter object is temporarily disabled from usage by any proxy object it may be associatedwith. The operation is then carried out, either successfully deleting all of the constraints identified in thefirst input sequence and modifying those associated with constraints identified in the second input sequence,or performing no side effects to the target object (in the case one of the inputs was invalid). Uponcompletion of the operation, the target filter object is effectively re-enabled and can once again be used byassociated filter objects in order to make event forwarding decisions.

10.3.2.2.1.4GetConstraints

The GetConstraints operation is invoked to return a sequence of a subset of the constraints associated withthe target filter object. The operation accepts as input a sequence of numeric values which should correspondto the unique identifiers of constraints encapsulated by the target object. If one of the input values does notcorrespond to the identifier of some encapsulated constraint, the ConstraintNotFound exception israised, containing as data the numeric value that did not correspond to some constraint. Upon successfulcompletion, this operation returns a sequence of data structures, each of which contains one of the inputidentifiers along with its associated constraint.

10.3.2.2.1.5GetAllConstraints

The GetAllConstraints operation returns all of the constraints currently encapsulated by the target filterobject. The return value of this operation is a sequence of structures, each of which contains one of theconstraints encapsulated by the target object along with its associated unique identifier.

10.3.2.2.1.6RemoveAllConstraints

The RemoveAllConstraints operation is invoked to remove all of the constraints currently encapsulated bythe target filter object. Upon completion, the target filter object will still exist but have no constraintsassociated with it.

10.3.2.2.1.7Destroy

The Destroy operation destroys the target filter object, invalidating its object reference.

10.3.2.2.1.8Match

The Match operation evaluates the filter constraints associated with the target filter object against aninstance of an event supplied to the channel in the form of a CORBA::Any. The operation accepts as inputa CORBA::Any which contains an event to be evaluated, and returns a boolean value which will be TRUEin cases where the input event satisfies one of the filter constraints, and FALSE otherwise. The act ofdetermining whether or not a given event passes a given filter constraint is specific to the type of grammarin which the filter constraint is specified. Thus, this operation will need to be re-implemented for eachsupported grammar.

If the input parameter contains data that the match operation is not designed to handle, theUnsupportedFilterableData exception will be raised. An example of this would be if the filterable datacontained a field whose name corresponds to a standard event field that has a numeric value, but the actualvalue associated with this field name within the event is a string.

10.3.2.2.1.9MatchStructured

The MatchStructured operation evaluates the filter constraints associated with the target filter object againstan instance of an event supplied to the channel in the form of a Structured Event. The operation accepts asinput a data structure of type IMSNotification::StructuredEvent which contains an event to be evaluated, andreturns a boolean value which will be TRUE in cases where the input event satisfies one of the filterconstraints, and FALSE otherwise. The act of determining whether or not a given event passes a given filter



constraint is specific to the type of grammar in which the filter constraint is specified. Thus, this operationwill need to be re-implemented for each supported grammar.

If the input parameter contains data that the match operation is not designed to handle, theUnsupportedFilterableData exception will be raised. An example of this would be if the filterable datacontained a field whose name corresponds to a standard event field that has a numeric value, but the actualvalue associated with this field name within the event is a string.

10.3.2.2.1.10 MatchTyped

The Match operation evaluates the filter constraints associated with the target filter object against aninstance of an event supplied to the channel in the form of a typed event. The operation accepts as input asequence of name-value pairs which contains the contents of the event to be evaluated, and returns a booleanvalue which will be TRUE in cases where the input event satisfies one of the filter constraints, and FALSEotherwise. The act of determining whether or not a given event passes a given filter constraint is specific tothe type of grammar in which the filter constraint is specified. Thus, this operation will need to be re-implemented for each supported grammar.

If the input parameter contains data that the Match operation is not designed to handle, theUnsupportedFilterableData exception will be raised. An example of this would be if the filterable datacontained a field whose name corresponds to a standard event field that has a numeric value, but the actualvalue associated with this field name within the event is a string.

10.3.2.2.1.11 AttachCallback

The AttachCallback operation accepts as input the reference to an object supporting theIMSNotifyComm::INotifySubscribe interface, and returns a numeric value assigned to this callbackthat is unique to all such callbacks currently associated with the target object. This operation is invoked toassociate with the target filter object an object supporting the IMSNotifyComm::INotifySubscribeinterface. This interface is inherited by all supplier interfaces (either those that are clients of a notificationchannel, or those that are proxy objects within a notification channel) defined by the Notification Service,and supports a SubscriptionChange operation. After this operation has been successfully invoked on a filterobject, each time the set of constraints associated with the target filter object is modified (either by aninvocation of its AddConstraints or its ModifyConstraints operations), the filter object will invoke theSubscriptionChange object of all its associated callback objects in order to inform suppliers to which thetarget filter object is attached of the change in the set of event types to which clients of the filter objectsubscribe. This enables suppliers to make intelligent decisions about which types of events it shouldactually produce, and which it can suppress the production of.

10.3.2.2.1.12 DetachCallback

The DetachCallback operation accepts as input a numeric value which should be one of the uniqueidentifiers associated with one of the callback objects attached to the target filter object. If the input valuedoes not correspond to the unique identifier of a callback object currently attached to the target filter object,the CallbackNotFound exception is raised. Otherwise, the callback object to which the input valuecorresponds is removed from the list of those associated with the target filter object, so that subsequentchanges to the event type subscription list encapsulated by the target filter object will not be propagated tothe callback object which is being detached.

10.3.2.2.1.13 GetCallbacks

The GetCallbacks operation accepts no input parameters and returns the sequence of all unique identifiersassociated with callback objects attached to the target filter object.

10.3.2.2.2The IMappingFilter Interface

The IMappingFilter interface defines the behaviors of objects which encapsulate a sequence of constraint-value pairs, where each constraint is a structure of the same type as that described in the previous section,



and each value represents a possible setting of a particular property of an event. Note that setting of aparticular property is not intended to imply that any contents of the event will be altered as a result ofapplying a mapping filter, but rather the way a proxy treats the event with respect to a particular property(i.e., priority or lifetime) could change. Upon receiving each event, a proxy object with an associated objectsupporting the IMappingFilter interface will invoke the appropriate Match operation variant (dependingupon whether the event is received in the form of an untyped event, a Structured Event, or a typed event) onthe mapping filter object in order to determine how it should modify a particular property value associatedwith the event to one of the values associated with one of the constraints encapsulated by the mappingfilter. Internally, the mapping filter object applies the constraints it encapsulates to the event in order todetermine whether or not the event’s property should be modified to one of the values associated with aconstraint, or else the default value associated with the mapping filter.

Each instance of an object supporting the IMappingFilter interface is typically associated with a specificevent property. For instance, in this specification IMappingFilter object instances are used to affect theproperties of priority and lifetime for events received by a proxy supplier object. Each event received by aproxy object which has an object supporting the IMappingFilter interface associated with it must satisfyat least one of the constraints associated with the IMappingFilter object in order to have its propertyvalue modified, otherwise the property will remain unchanged. A specific instance supporting theIMappingFilter interface typically applies its encapsulated constraints in an order which begins with thebest possible property setting (e.g., the highest priority or the longest lifetime), and ends with the worstpossible property setting. As soon as a matching constraint is encountered, the associated value is returnedas an output parameter and the proxy which invoked the operation proceeds to modify the property of theevent to the new value.

The constraint expressions associated with a particular object supporting the IMappingFilter interface areexpressed as strings which obey the syntax of a particular constraint grammar (i.e. a BNF). Everyconformant implementation of this service must support constraint expressions expressed in the defaultconstraint grammar described in section 2.4. In addition, implementations may support other constraintgrammars, and/or users of this service may implement their own filter objects which allow constraints to beexpressed in terms of an alternative constraint grammar. As long as such user-defined filter objects supportthe IMappingFilter interface, they can be attached to proxy objects in the same fashion as the defaultIMappingFilter objects supported by the implementation of the service are, and the channel should beable to use them to potentially affect the properties of events in the same fashion.

The IMappingFilter interface supports the operations required to manage the constraint-value pairsassociated with an object instance which supports the interface. In addition, the IMappingFilter interfacesupports a readonly attribute which identifies the particular constraint grammar in which the constraintsencapsulated by this object have meaning. The IMappingFilter interface also supports a readonlyattribute which identifies the typecode associated with the datatype of the specific property value it isintended to affect, and another readonly attribute which holds the default value which will be returned as theresult of a match operation in cases when the event in question is found to satisfy none of the constraintsencapsulated by the mapping filter. Lastly, the IMappingFilter interface supports three variants of theoperation which will be invoked by an associated proxy object upon receipt of an event, to determine howthe property of the event which the target mapping filter object was designed to affect should be modified.The operations supported by the IMappingFilter object are described in more detail within the followingsubsections.

10.3.2.2.2.1constraintGrammar

The constraintGrammar attribute is a readonly attribute which identifies the particular grammar withinwhich the constraint expressions encapsulated by the target filter object have meaning. The value of thisattribute is set upon creation of a mapping filter object instance, based on the input provided to the factorycreation operation for the mapping filter instance.



The dependency of a filter object on its constraints being expressed within a particular constraint grammarmanifests itself within the implementation of the Match operations described below, which must be able toparse the constraints to determine whether or not a particular event satisfies one of them.

Every conformant implementation of the Notification Service must support an implementation of theMappingFilter object which supports the default constraint grammar described in section 2.4. The valuewhich the constraintGrammar attribute is set to in the case the target filter object supports this defaultgrammar will be “EXTENDED_TCL”. In addition, implementations and/or end users may provideadditional implementations of the IMappingFilter interface which support different constraint grammars,and thus would set the constraintGrammar attribute to a different value upon creation of such a filter object.

10.3.2.2.2.2valueType

The valueType attribute is a readonly attribute which identifies the datatype of the property value which thetarget mapping filter object was designed to affect. Note that the factory creation operation for mappingfilter objects accepts as an input parameter the defaultValue to associate with the mapping filter instance.This defaultValue is a CORBA::Any. Upon creation of a mapping filter, the Typecode associated with thedefaultValue is abstracted from the CORBA::Any, and its value is assigned to this attribute. The valueTypeattribute thus serves mainly as a convenience for clients attempting to examine the state of a mapping filterobject.

10.3.2.2.2.3defaultValue

The defaultValue attribute is a readonly attribute that will be the output parameter returned as the result ofany Match operation during which the input event is found to satisfy none of the constraints encapsulatedby the mapping filter. within which the constraints encapsulated by the target filter object have meaning.The value of this attribute is set upon creation of a mapping filter object instance, based on the inputprovided to the factory creation operation for the mapping filter instance.

10.3.2.2.2.4AddMappingContraints

The AddMappingConstraints operation is invoked by a client in order to associate specific mappingconstraints with the target filter object. Note that a mapping constraint is comprised of a constraintstructure paired with an associated value. The operation accepts as input one parameter that is a sequence ofconstraint-value pairs. Each constraint in this sequence must be expressed within the constraint grammarsupported by the target object, and each associated value must be of the data type indicated by the valueTypeattribute of the target object.

Upon processing the each element in the input sequence, the target object associates a numeric identifierwith this constraint-value pair that is unique among all those that it encapsulates. If any of the constraintexpressions in the input sequence is not a valid expression within the supported constraint grammar, theInvalidConstraint exception is raised. This exception contains as data the specific constraint that wasdetermined to be invalid. If any of the values supplied in the input sequence is not of the same datatype asthat indicated by the valueType attribute associated with the target object, the InvalidValue exception israised. This exception contains as data both the invalid value and its corresponding constraint in the firstinput sequence. Upon successful processing of all input constraints, the addMappingConstraints operationreturns a sequence in which each element will be a structure including one of the input constraintexpressions, its corresponding value, and the unique identifier assigned to this constraint-value pair by thetarget filter object.

Note that the semantics of the AddMappingConstraints operation are such that its side-effects are performedatomically upon the target filter object. Once AddMappingConstraints is invoked by a client, the targetfilter object is temporarily disabled from usage by any proxy object it may be associated with. Theoperation is then carried out, either successfully adding all of the input constraint-value pairs to thetargetobject or none of them (in the case one of the input expressions or values was invalid). Upon completion of



the operation, the target filter object is effectively re-enabled and can once again be used by associated filterobjects in order to make event property mapping decisions.

10.3.2.2.2.5ModifyMappingConstraints

The ModifyMappingConstraints operation is invoked by a client in order to modify the constraint-valuepairs associated with the target filter object. This operation can be used both to remove constraint-valuepairs currently associated with the target filter object, and to modify the constraints and/or values ofconstraint-value pairs which have previously been added to the target filter object.

The operation accepts two input paramaters. The first input parameter is a sequence of numeric valueswhich are each intended to be the unique identifier associated with one of the constraint-value pairs currentlyencapsulated by the target filter object. If all input values supplied within a particular invocation of thisoperation are valid, then the specific constraint-value pairs identified by the values contained in the firstinput parameter will be deleted from the list of those encapsulated by the target filter object. The secondinput parameter to this operation is a sequence of structures, each of which contains a constraint structure,an Any value, and a numeric identifier. The numeric identifier contained by each element of the sequence isintended to be the unique identifier associated with one of the constraint-value pairs currently encapsulatedby the target filter object. If all input values supplied within a particular invocation of this operation arevalid, then the constraint associated with the already encapsulated constraint-value pair identified by thenumeric identifier contained within each element of the input sequence will be modified to the newconstraint that is contained within the same sequence element. Likewise, the data value associated with thealready encapsulated constraint-value pair identified by the numeric identifier contained within each elementof the input sequence will be modified to the new data value that is contained in the same element of thesequence.

If any of the numeric identifiers supplied within either of the two input sequences does not correspond to theunique identifier associated with some constraint-value pairs currently encapsulated by the target filterobject, the ConstraintNotFound exception is raised. This exception contains as data the specificidentifier which was supplied as input but did not correspond to the identifier of some constraint-value pairencapsulated by the target object. If any of the constraint expressions supplied within an element of thesecond input sequence is not a valid expression in terms of the constraint grammar supported by the targetobject, the InvalidConstraint exception is raised. This exception contains as data the specific constraintthat was determined to be invalid. If any of the values supplied in the second input sequence is not of thesame datatype as that indicated by the value_type attribute associated with the target object, theInvalidValue exception is raised. This exception contains as data both the invalid value and itscorresponding constraint expression.

Note that the semantics of the ModifyMappingConstraints operation are such that its side-effects areperformed atomically upon the target filter object. Once ModifyMappingConstraints is invoked by a client,the target filter object is temporarily disabled from usage by any proxy object it may be associated with.The operation is then carried out, either successfully deleting all of the constraint-value pairs identified inthe first input sequence and modifying the constraints and values associated with constraints identified in thesecond input sequence, or performing no side effects to the target object (in the case one of the inputs wasinvalid). Upon completion of the operation, the target filter object is effectively re-enabled and can onceagain be used by associated filter objects in order to make event property mapping decisions.

10.3.2.2.2.6GetMappingConstraints

The GetMappingConstraints operation is invoked to return a sequence of a subset of the constraint-valuepairs associated with the target filter object. The operation accepts as input a sequence of numeric valueswhich should correspond to the unique identifiers of constraint-value pairs encapsulated by the target object.If one of the input values does not correspond to the identifier of some encapsulated constraint-value pair,the ConstraintNotFound exception is raised, containing as data the numeric value that did notcorrespond to some such pair. Upon successful completion, this operation returns a sequence of data



structures, each of which contains one of the input identifiers along with its associated constraint structureand constraint value.

10.3.2.2.2.7GetAllMappingConstraints

The GetAllMappingConstraints operation returns all of the constraint-value pairs currently encapsulated bythe target filter object. The return value of this operation is a sequence of structures, each of which containsone of the constraints encapsulated by the target object along with its associated value and unique identifier.

10.3.2.2.2.8RemoveAllMappingConstraints

The RemoveAllMappingConstraints operation is invoked to remove all of the constraint-value pairscurrently encapsulated by the target filter object. Upon completion, the target filter object will still existbut have no constraint-value pairs associated with it.

10.3.2.2.2.9Destroy

The Destroy operation destroys the target filter object, invalidating its object reference.

10.3.2.2.2.10 Match

The Match operation is invoked on an object supporting the IMappingFilter interface in order todetermine how some property value of a particular event supplied to the channel in the form of aCORBA::Any should be modified. The operation accepts an Any as input, which contains the event beingevaluated. Upon invocation, the target mapping filter object begins applying the constraints it encapsulatesin order according to each constraints associated value, starting with the constraint with the “best” associatedvalue for the specific property the mapping filter object was designed to affect (e.g., the highest priority, thelongest lifetime, etc.), and ending with the constraint with the “worst” associated value. Upon encounteringa constraint which the input filterable data matches, the operation sets the output parameter contained in itssignature to the value associated with the constraint, and sets the return value of the operation to TRUE. Ifthe input filterable data satisfies none of the constraints encapsulated by the target mapping filter object, thereturn value of the operation is set to FALSE, and the output parameter is set to the value of thedefaultValue attribute associated with the target mapping filter object. The act of determining whether or nota given filterable event data passes a given filter constraint is specific to the type of grammar in which thefilter constraint is specified. Thus, this operation will need to be re-implemented for each supportedgrammar.


10.3.2.2.2.11 MatchStructured

The MatchStructured operation is invoked on an object supporting the IMappingFilter interface in orderto determine how some property value of a particular event supplied to the channel in the form of aStructured Event should be modified. The operation accepts a IMSNotification::StructuredEvent as input,which contains the event being evaluated. Upon invocation, the target mapping filter object beginsapplying the constraints it encapsulates in order according to each constraints associated value, starting withthe constraint with the “best” associated value for the specific property the mapping filter object wasdesigned to affect (e.g., the highest priority, the longest lifetime, etc.), and ending with the constraint withthe “worst” associated value. Upon encountering a constraint which the input filterable data matches, theoperation sets the output parameter contained in its signature to the value associated with the constraint, andsets the return value of the operation to TRUE. If the input filterable data satisfies none of the constraintsencapsulated by the target mapping filter object, the return value of the operation is set to FALSE, and theoutput parameter is set to the value of the default_value attribute associated with the target mapping filterobject. The act of determining whether or not a given filterable event data passes a given filter constraint isspecific to the type of grammar in which the filter constraint is specified. Thus, this operation will need to



be re-implemented for each supported grammar. If the input parameter contains data that the match operationis not designed to handle, the UnsupportedFilterableData exception will be raised. An example of thiswould be if the filterable data contained a field whose name corresponds to a standard event field that has anumeric value, but the actual value associated with this field name within the event is a string.

10.3.2.2.2.12 MatchTyped

The MatchTyped operation is invoked on an object supporting the IMappingFilter interface in order todetermine how some property value of a particular event supplied to the channel in the form of a typedevent should be modified. The operation accepts as input a sequence of name-value pairs which contains thecontents of the event to be evaluated (how a typed event is converted to a sequence of name-value pairs bythe channel is described in section 2.7). Upon invocation, the target mapping filter object begins applyingthe constraints it encapsulates in order according to each constraints associated value, starting with theconstraint with the “best” associated value for the specific property the mapping filter object was designedto affect (e.g., the highest priority, the longest lifetime, etc.), and ending with the constraint with the“worst” associated value. Upon encountering a constraint which the input filterable data matches, theoperation sets the output parameter contained in its signature to the value associated with the constraint, andsets the return value of the operation to TRUE. If the input filterable data satisfies none of the constraintsencapsulated by the target mapping filter object, the return value of the operation is set to FALSE, and theoutput parameter is set to the value of the default_value attribute associated with the target mapping filterobject. The act of determining whether or not a given filterable event data passes a given filter constraint isspecific to the type of grammar in which the filter constraint is specified. Thus, this operation will need tobe re-implemented for each supported grammar.


10.3.2.2.3The IFilterFactory Interface

The IFilterFactory interface defines operations for creating filter objects.

10.3.2.2.3.1CreateFilter

The CreateFilter operation is responsible for creating a new forwarding filter object. It takes as input astring parameter which identifies the grammar in which constraints associated with this filter will havemeaning. If the client invoking this operation supplies as input the name of a grammar that is notsupported by any forwarding filter implementation this factory is capable of creating, theInvalidGrammar exception is raised. Otherwise, the operation returns the reference to an objectsupporting the IFilter interface, which can subsequently be configured to support constraints in theappropriate grammar.

10.3.2.2.3.2CreateMappingFilter

The CreateMappingFilter operation is responsible for creating a new mapping filter object. It takes as inputa string parameter which identifies the grammar in which constraints associated with this filter will havemeaning, and an Any which will be set as the defaultValue of the newly created mapping filter. If the clientinvoking this operation supplies as input the name of a grammar that is not supported by any mappingfilter implementation this factory is capable of creating, the InvalidGrammar exception is raised.Otherwise, the operation returns the reference to an object supporting the IMappingFilter interface,which can subsequently be configured to support constraints in the appropriate grammar, along with theirassociated mapping values.

10.3.2.2.4The IFilterAdmin Interface

The IFilterAdmin interface defines operations that enable an object supporting this interface to manage alist of filter objects, each of which supports the IFilter interface. This interface is intended to be an



abstract interface which is inherited by all of the Proxy and Admin interfaces defined by the NotificationService. The difference in the semantics between a list of filter objects that is associated with an Adminobject, and a list that is associated with a Proxy object, is described in section 2.1.2.

10.3.2.2.4.1AddFilter

The AddFilter operation accepts as input the reference to an object supporting the IFilter interface. Theaffect of this operation is that the input filter object is appended to the list of filter objects associated withthe target object upon which the operation was invoked. The operation associates with the newly added filterobject a numeric identifier that is unique among all filter objects currently associated with the target, andreturns that value as the result of the operation.

10.3.2.2.4.2RemoveFilter

The RemoveFilter operation accepts as input a numeric value that is intended to be the unique identifier of afilter object that is currently associated with the target object. If identifier supplied does correspond to afilter object currently associated with the target object, then the corresponding filter object will be removedfrom the list of filters associated with the target object. Otherwise, the FilterNotFound exception willbe raised.

10.3.2.2.4.3GetFilter

The GetFilter operation accepts as input a numeric identifier that is intended to correspond to one of thefilter objects currently associated with the target object. If this is the case, the object reference of thecorresponding filter object is returned. Otherwise, the FilterNotFound exception is raised.

10.3.2.2.4.4GetAllFilters

The GetAllFilters operation accepts no input parameters, and returns the list of unique identifiers whichcorrespond to all of the filters currently associated with the target object.

10.3.2.2.4.5RemoveAllFilters

The RemoveAllFilters operation accepts no input parameters, and removes all filter objects from the list ofthose currently associated with the target object.

10.3.2.3 The IMSNotifyComm ModuleThe IMSNotifyComm module defines the interfaces which support Notification Service clients thatcommunicate using Structured Events or sequences of Structured Events. In addition, this module definesthe interfaces which enable event suppliers to be informed when the types of events being subscribed to bytheir associated consumers change, and event consumers to be informed whenever there is a change in thetypes of events being produced by their suppliers (this model is described in detail in section 2.6).

10.3.2.3.1The INotifyPublish Interface

The INotifyPublish interface supports an operation which allows a supplier of Notifications toannounce, or publish, the names of the types of events it will be supplying, It is intended to be an abstractinterface which is inherited by all Notification Service consumer interfaces, and enables suppliers to informconsumers supporting this interface of the types of events they intend to supply.

10.3.2.3.1.1OfferChange

The OfferChange operation takes as input two sequences of event type names: the first specifying thoseevent types which the client of the operation (an event supplier) is informing the target consumer objectthat it is adding to the list of event types it plans to supply, and the second specifying those event typeswhich the client no longer plans to supply. This operation raises the InvalidEventType exception if one ofthe event type names supplied in either input parameter is syntactically invalid. In this case, the invalidname is returned in the type field of the exception.



Note that each event type name is comprised of two components: the name of the domain in which theevent type has meaning, and the name of the actual event type. Also note that either component of a typename may specify a complete domain/event type name, a domain/event type name containing the wildcard‘*’ character, or the special event type name “%ALL” described in section 2.6.5.

10.3.2.3.2The INotifySubscribe Interface

The INotifySubscribe interface supports an operation which allows a consumer of notifications toinform suppliers of notifications of the types of notifications it wishes to receive. It is intended to be anabstract interface which is inherited by all Notification Service supplier interfaces. In essence, its mainpurpose is to enable notification consumers to inform suppliers of the types of notifications that are ofinterest to them, ultimately enabling the suppliers to avoid supplying notifications that are not of interestto any consumer.

10.3.2.3.2.1SubscriptionChange

The SubscriptionChange operation takes as input two sequences of event type names: the first specifyingthose event types which the associated Consumer wants to add to its subscription list, and the secondspecifying those event types which the associated consumer wants to remove from its subscription list.This operation raises the InvalidEventType exception if one of the event type names supplied in either inputparameter is syntactically invalid. If this case, the invalid name is returned in the type field of the exception.Note that each event type name is comprised of two components: the name of the domain in which theevent type has meaning, and the name of the actual event type. Also note that either component of a typename may specify a complete domain/event type name, a domain/event type name containing the wildcard‘*’ character, or the special event type name “%ALL” described in section 2.6.5.

10.3.2.3.3The ITxnPushConsumer Interface

The ITxnPushConsumer interface extends the IMSEventComm::IPushConsumer interface toprovide support for standard Event Service events under transaction control using the push model. Inaddition, the ITxnPushConsumer interface inherits the INotifyPublish interface described above,enabling a notification supplier to inform an instance supporting this interface whenever there is a changeto the types of events it intends to produce.

The ITxnPushConsumer interface provides transactional support for events using the CORBATransaction Service (OTS). This enables the ability to treat a push consumer of events in the form of Anysas an OTS Recoverable Server or an XA Resource Manager. When transaction support is implemented,events pushed to such a consumer are available for usage by the consumer when the channel issues asuccessful OTS commit. If the transmission fails for any reason, the transaction is rolled back and theseevents should be discarded by the consumer, as opposed to actually being consumed. This is important inorder to guarantee a consistent state of the application, since other effects of the same transaction (e.g.,database changes) will also be undone.

10.3.2.3.4The ITxnPullSupplier Interface

The ITxnPullSupplier interface extends the IMSEventComm::IPullSupplier interface to providesupport for standard Event Service events under transaction control using the pull model. In addition, theITxnPullSupplier interface inherits the INotifySubscribe interface described above, enabling anotification consumer to inform an instance supporting this interface whenever there is a change to thetypes of events it is interested in receiving.The ITxnPullSupplier interface provides transactional support for pull style suppliers of Any eventsusing the CORBA Transaction Service (OTS). This enables the ability to treat a pull style supplier as anOTS Recoverable Server or an XA Resource Manager. When transaction support is implemented, events arepulled by the channel within the context of a transaction. If the transmission fails for any reason, thetransaction will be rolled back, and the channel discards any portion of the event(s) it has received. In thiscase, the supplier should also restore any state necessary such as to indicate it had not sent the event(s),since other effects of the same transaction (e.g., database changes) will also be undone.



10.3.2.3.5The IStructuredPushConsumer Interface

The IStructuredPushConsumer interface supports an operation which enables consumers to receiveStructured Events by the push model. It also defines an operation which can be invoked to disconnect thepush consumer from its associated supplier. In addition, the IStructuredPushConsumer interfaceinherits the INotifyPublish interface described above, enabling a notification supplier to inform aninstance supporting this interface whenever there is a change to the types of events it intends to produce.Note that an object supporting the IStructuredPushConsumer interface can receive all events whichwere supplied to its associated channel, including events supplied in a form other than a Structured Event.How events supplied to the channel in other forms are internally mapped into a Structured Event fordelivery to a IStructuredPushConsumer is summarized in Table 2-2.

10.3.2.3.5.1PushStructuredEvent

The PushStructuredEvent operation takes as input a parameter of type IStructuredEvent as defined in theIMSNotification module. Upon invocation, this parameter will contain an instance of a StructuredEvent being delivered to the consumer by the supplier to which it is connected. If this operation is invokedupon a IStructuredPushConsumer instance that is not currently connected to the supplier of the event,the Disconnected exception will be raised.In reality there are two types of objects that will support the IStructuredPushConsumer interface: anobject representing an application which receives Structured Events, and aIStructuredProxyPushConsumer (defined in the IMSNotifyChannelAdmin module) associatedwith an event channel which receives structured events from a supplier on behalf of the channel. For thefirst type of object, the implementation of the PushStructuredEvent operation is application specific, and isintended to be supplied by application developers. For the second type of object, the behavior of theoperation is tightly linked to the implementation of the event channel. Basically, it is responsible forapplying any filters that have been registered by with the StructuredProxyPushConsumer, then eitherdiscarding the event or forwarding it to each proxy supplier within the channel depending on whether or notthe event passed the filter.

10.3.2.3.5.2DisconnectStructuredPushConsumer

The DisconnectStructuredPushConsumer operation is invoked to terminate a connection between the targetStructuredPushConsumer, and its associated supplier. This operation takes no input parameters andreturns no values. The result of this operation is that the target StructuredPushConsumer will releaseall resources it had allocated to support the connection, and dispose its own object reference.

10.3.2.3.6The ITxnStructuredPushConsumer Interface

The ITxnStructuredPushConsumer interface extends the IStructuredPushConsumer interface toprovide transactional support for push style consumers of Structured Events using the CORBA TransactionService (OTS). This enables the ability to treat such consumers as an OTS Recoverable Server or an XAResource Manager. When transaction support is implemented, events pushed to such a consumer areavailable for usage by the consumer when the channel issues a successful OTS commit. If the transmissionfails for any reason, the transaction is rolled back and these events should be discarded by the consumer, asopposed to actually being consumed. This is important in order to guarantee a consistent state of theapplication, since other effects of the same transaction (e.g., database changes) will also be undone.

10.3.2.3.7The IStructuredPullConsumer Interface

The IStructuredPullConsumer interface supports the behavior of objects that receive Structured Eventsusing pull-style communication. It defines an operation which can be invoked to disconnect the pullconsumer from its associated supplier. In addition, the IStructuredPullConsumer interface inherits theINotifyPublish interface described above, enabling a notification supplier to inform an instancesupporting this interface whenever there is a change to the types of events it intends to produce.Note that an object supporting the IStructuredPullConsumer interface can receive all events whichwere supplied to its associated channel, including events supplied in a form other than a Structured Event.



How events supplied to the channel in other forms are internally mapped into a Structured Event fordelivery to a StructuredPullConsumer is summarized in Table 2-2.

10.3.2.3.7.1DisconnectStructuredPullConsumer

The DisconnectStructuredPullConsumer operation is invoked to terminate a connection between the targetStructuredPullConsumer, and its associated supplier. This operation takes no input parameters andreturns no values. The result of this operation is that the target StructuredPullConsumer will releaseall resources it had allocated to support the connection, and dispose its own object reference.

10.3.2.3.8The IStructuredPullSupplier Interface

The IStructuredPullSupplier interface supports operations which enable suppliers to transmitStructured Events by the pull model. It also defines an operation which can be invoked to disconnect thepull supplier from its associated consumer. In addition, the IStructuredPullSupplier interface inheritsthe INotifySubscribe interface described above, enabling a notification consumer to inform an instancesupporting this interface whenever there is a change to the types of events it is interested in receiving.Note that an object supporting the IStructuredPullSupplier interface can transmit events which canpotentially be received by any consumer connected to the channel, including those which consume events ina form other than a Structured Event. How events supplied to the channel in the form of a Structured Eventare internally mapped into different forms for delivery to consumers which receive events in a form otherthan the Structured Event is summarized in Table 2-2.

10.3.2.3.8.1PullStructuredEvent

The PullStructuredEvent operation takes no input parameters, and returns a value of type StructuredEvent as defined in the IMSNotification module. Upon invocation, the operation will block until anevent is available for transmission, at which time it will return an instance of a Structured Event whichcontains the event being delivered to its connected consumer. If invoked upon a StructuredPullSupplierthat is not currently connected to the consumer of the event, the Disconnected exception will be raised.In reality there are two types of objects that will support the IStructuredPullSupplier interface: anobject representing an application which transmits Structured Events, and aStructuredProxyPullSupplier (defined in the IMSNotifyChannelAdmin module) associated withan event channel which transmits events to a pull style consumer on behalf of the channel. For the firsttype of object, the implementation of the PullStructuredEvent operation is application specific, and isintended to be supplied by application developers. The application specific implementation of this operationshould construct a structured event, and return it within a StructuredEvent data structure. For the secondtype of object, the behavior of the operation is tightly linked to the implementation of the event channel.Basically, it is responsible for forwardinga structured event, within an StructuredEvent data structure, asthe return value to the consumer it is connected to upon the availability of an event which passes thefilter(s) associated with the StructuredProxyPullSupplier. Note that the operation will block untilsuch an event is available to return.

10.3.2.3.8.2TryPullStructuredEvent

The TryPullStructuredEvent operation takes no input parameters, and returns a value of typeStructuredEvent as defined in the IMSNotification module. It also returns an output parameter oftype boolean which indicates whether or not the return value actually contains an event. Upon invocation,the operation will return an instance of a Structured Event which contains the event being delivered to itsconnected consumer, if such an event is available for delivery at the time the operation was invoked. If anevent is available for delivery and thus returned as the result, the output parameter of the operation will beset to TRUE. If no event is available to return upon invocation, the operation will return immediately withthe value of the output parameter set to FALSE. In this case, the return value will not contain a validevent. If invoked upon a StructuredPullSupplier that is not currently connected to the consumer of theevent, the Disconnected exception will be raised.



In reality there are two types of objects that will support the IStructuredPullSupplier interface: anobject representing an application which transmits Structured Events, and aIStructuredProxyPullSupplier (defined within the IMSNotifyChannelAdmin module) associatedwith an event channel which transmits events to a PullConsumer on behalf of the channel. For the firsttype of object, the implementation of the TryPullStructuredEvent operation is application specific, and isintended to be supplied by application developers. If an event is available to be returned upon invocation ofthis operation, the application specific implementation of this operation should construct a StructuredEvent, and return it within a StructuredEvent data structure along with setting the value of the outputparameter to TRUE. Otherwise, the operation should return immediately after setting the value of theoutput parameter to FALSE. For the second type of object, the behavior of the operation is tightly linkedto the implementation of the event channel. Basically, if an event is available to be returned uponinvocation of this operation, it is responsible for forwarding it, within a StructuredEvent data structure,as the return value to the consumer it is connected to, in addition to setting the output parameter toFALSE. If no event is available to return to the consumer upon invocation of this operation, it willimmediately return with the output parameter to set to FALSE, and the return value not containing a validevent.

10.3.2.3.8.3DisconnectStructuredPullSupplier

The DisconnectStructuredPullSupplier operation is invoked to terminate a connection between the targetStructuredPullSupplier, and its associated consumer. This operation takes no input parameters andreturns no values. The result of this operation is that the target StructuredPullSupplier will release allresources it had allocated to support the connection, and dispose its own object reference.

10.3.2.3.9The ITxnStructuredPullSupplier Interface

The ITxnStructuredPullSupplier interface extends the IStructuredPullSupplier interface toprovide transactional support for pull style suppliers of Structured Events using the CORBA TransactionService (OTS). This enables the ability to treat such a supplier as an OTS Recoverable Server or an XAResource Manager. When transaction support is implemented, events are pulled by the channel within thecontext of a transaction. If the transmission fails for any reason, the transaction will be rolled back, and thechannel discards any portion of the event(s) it has received. In this case, the supplier should also restore anystate necessary such as to indicate it had not sent the event(s), since other effects of the same transaction(e.g., database changes) will also be undone.

10.3.2.3.10 The IStructuredPushSupplier Interface

The IStructuredPushSupplier interface supports the behavior of objects that transmit Structured Eventsusing push-style communication. It defines an operation which can be invoked to disconnect the pushsupplier from its associated consumer. In addition, the IStructuredPushSupplier interface inherits theINotifySubscribe interface described above, enabling a notification consumer to inform an instancesupporting this interface whenever there is a change to the types of events it is interested in receiving.Note that an object supporting the IStructuredPushSupplier interface can transmit events which canpotentially be received by any consumer connected to the channel, including those which consume events ina form other than a Structured Event. How events supplied to the channel in the form of a Structured Eventare internally mapped into different forms for delivery to consumers which receive events in a form otherthan the Structured Event is summarized in Table 2-2.

10.3.2.3.10.1 DisconnectStructuredPushSupplier

The DisconnectStructuredPushSupplier operation is invoked to terminate a connection between the targetStructuredPushSupplier, and its associated consumer. This operation takes no input parameters andreturns no values. The result of this operation is that the target StructuredPushSupplier will release allresources it had allocated to support the connection, and dispose its own object reference.

10.3.2.3.11 The ISequencePushConsumer Interface



The ISequencePushConsumer interface supports an operation which enables consumers to receivesequences Structured Events by the push model. It also defines an operation which can be invoked todisconnect the push consumer from its associated supplier. In addition, the ISequencePushConsumerinterface inherits the INotifyPublish interface described above, enabling a notification supplier to informan instance supporting this interface whenever there is a change to the types of events it intends to produce.Note that an object supporting the ISequencePushConsumer interface can receive all events which weresupplied to its associated channel, including events supplied in a form other than a sequence of StructuredEvents. How events supplied to the channel in other forms are internally mapped into a sequence ofStructured Events for delivery to a SequencePushConsumer is summarized in Table 2-2.

10.3.2.3.11.1 PushStructuredEvents

The PushStructuredEvents operation takes as input a parameter of type EventBatch as defined in theIMSNotification module. This data type is the same as a sequence of Structured Events. Uponinvocation, this parameter will contain a sequence of Structured Events being delivered to the consumer bythe supplier to which it is connected. If this operation is invoked upon a SequencePushConsumerinstance that is not currently connected to the supplier of the event, the Disconnected exception will beraised.Note that the maximum number of events that will be transmitted within a single invocation of thisoperation, along with the amount of time a supplier of a sequence of Structured Events will accumulateindividual events into the sequence before invoking this operation, are controlled by QoS property settings.In reality there are two types of objects that will support the ISequencePushConsumer interface: anobject representing an application which receives sequences of Structured Events, and aISequenceProxyPushConsumer (defined in the IMSNotifyChannelAdmin module) associatedwith an event channel which receives sequences of Structured Events from a supplier on behalf of thechannel. For the first type of object, the implementation of the PushStructuredEvents operation isapplication specific, and is intended to be supplied by application developers. For the second type of object,the behavior of the operation is tightly linked to the implementation of the event channel. Basically, it isresponsible for applying any filters that have been registered by with theISequenceProxyPushConsumer to each event in each sequence it receives, then either discarding eachevent or forwarding it to each proxy supplier within the channel depending on whether or not the eventpassed the filter.

10.3.2.3.11.2 DisconnectSequencePushConsumer

The DisconnectSequencePushConsumer operation is invoked to terminate a connection between the targetSequencePushConsumer, and its associated supplier. This operation takes no input parameters andreturns no values. The result of this operation is that the target SequencePushConsumer will releaseall resources it had allocated to support the connection, and dispose its own object reference.

10.3.2.3.12 The ITxnSequencePushConsumer Interface

The ITxnSequencePushConsumer interface extends the ISequencePushConsumer interface toprovide transactional support for push style consumers of sequences of Structured Events using the CORBATransaction Service (OTS). This enables the ability to treat such consumers as an OTS Recoverable Serveror an XA Resource Manager. When transaction support is implemented, events pushed to such a consumerare available for usage by the consumer when the channel issues a successful OTS commit. If thetransmission fails for any reason, the transaction is rolled back and these events should be discarded by theconsumer, as opposed to actually being consumed. This is important in order to guarantee a consistent stateof the application, since other effects of the same transaction (e.g., database changes) will also be undone.

10.3.2.3.13 The ISequencePullConsumer Interface

The ISequencePullConsumer interface supports the behavior of objects that receive sequences ofStructured Events using pull-style communication. It defines an operation which can be invoked todisconnect the pull consumer from its associated supplier. In addition, the ISequencePullConsumerinterface inherits the INotifyPublish interface described above, enabling a notification supplier to inform



an instance supporting this interface whenever there is a change to the types of events it intends to produce.Note that an object supporting the ISequencePullConsumer interface can receive all events which weresupplied to its associated channel, including events supplied in a form other than a sequence of StructuredEvents. How events supplied to the channel in other forms are internally mapped into a sequence ofStructured Events for delivery to a SequencePullConsumer is summarized in Table 2-2.

10.3.2.3.13.1 DisconnectSequencePullConsumer

The DisconnectSequencePullConsumer operation is invoked to terminate a connection between the targetSequencePullConsumer, and its associated supplier. This operation takes no input parameters andreturns no values. The result of this operation is that the target SequencePullConsumer will release allresources it had allocated to support the connection, and dispose its own object reference.

10.3.2.3.14 The ISequencePullSupplier Interface

The ISequencePullSupplier interface supports operations which enable suppliers to transmit sequencesof Structured Events by the pull model. It also defines an operation which can be invoked to disconnect thepull supplier from its associated consumer. In addition, the ISequencePullSupplier interface inheritsthe INotifySubscribe interface described above, enabling a notification consumer to inform an instancesupporting this interface whenever there is a change to the types of events it is interested in receiving.Note that an object supporting the ISequencePullSupplier interface can transmit events which canpotentially be received by any consumer connected to the channel, including those which consume events ina form other than a sequence of Structured Events. How events supplied to the channel in the form of asequence of Structured Events are internally mapped into different forms for delivery to consumers whichreceive events in a form other than the a sequence of Structured Events is summarized in Table 2-2.

10.3.2.3.14.1 PullStructuredEvents

The PullStructuredEvents operation takes as an input parameter a numeric value, and returns a value of typeEventBatch as defined in the IMSNotification module. This data type is the same as a sequence ofStructured Events. Upon invocation, the operation will block until a sequence of Structured Events isavailable for transmission, at which time it will return the sequence containing events being delivered to itsconnected consumer. If invoked upon a SequencePullSupplier that is not currently connected to theconsumer of the event, the Disconnected exception will be raised.

Note that the maximum length of the sequence returned will never exceed the value of the input parameter.In addition, the amount of time the supplier will accumulate events into the sequence before transmitting it,along with the maximum size of any sequence it will transmit (regardless of the input parameter), arecontrolled by QoS property settings as described in section 2.5.5.

In reality there are two types of objects that will support the ISequencePullSupplier interface: anobject representing an application which transmits sequences of Structured Events, and aISequenceProxyPullSupplier (defined in the IMSNotifyChannelAdmin module) associated withan event channel which transmits events to a pull style consumer on behalf of the channel. For the firsttype of object, the implementation of the PullStructuredEvents operation is application specific, and isintended to be supplied by application developers. The application specific implementation of this operationshould construct a sequence of Structured Events, and return it within a EventBatch data structure. For thesecond type of object, the behavior of the operation is tightly linked to the implementation of the eventchannel. Basically, it is responsible for forwarding a sequence of Structured Events, within an EventBatchdata structure, as the return value to the consumer it is connected to upon the availability of events whichpass the filter(s) associated with the SequenceProxyPullSupplier. Note that the operation will blockuntil there is a sequence available to return.

10.3.2.3.14.2 TryPullStructuredEvents

The TryPullStructuredEvents operation takes as an input parameter a numeric value, and returns a value oftype EventBatch as defined in the IMSNotification module. This data type is the same as a sequence



of Structured Events. The operation also returns an output parameter of type boolean which indicateswhether or not the return value actually contains a sequence of events. Upon invocation, the operation willreturn a sequence of a Structured Events which contains events being delivered to its connected consumer, ifsuch a sequence is available for delivery at the time the operation was invoked. If an event sequence isavailable for delivery and thus returned as the result, the output parameter of the operation will be set toTRUE. If no event sequence is available to return upon invocation, the operation will return immediatelywith the value of the output parameter set to FALSE. In this case, the return value will not contain a validevent sequence. If invoked upon a SequencePullSupplier that is not currently connected to theconsumer of the event, the Disconnected exception will be raised.

Note that the maximum length of the sequence returned will never exceed the value ofthe input parameter.In reality there are two types of objects that will support the ISequencePullSupplier interface: anobject representing an application which transmits sequences of Structured Events, and aISequenceProxyPullSupplier (defined within the IMSNotifyChannelAdmin module) associatedwith an event channel which transmits events to a PullConsumer on behalf of the channel. For the firsttype of object, the implementation of the TryPullStructuredEvents operation is application specific, and isintended to be supplied by application developers. If an event sequence is available to be returned uponinvocation of this operation, the application specific implementation of this operation should construct anEventBatch instance, and return it along with setting the value of the output parameter to TRUE.Otherwise, the operation should return immediately after setting the value of the output parameter toFALSE. For the second type of object, the behavior of the operation is tightly linked to theimplementation of the event channel. Basically, if an event sequence is available to be returned uponinvocation of this operation, it is responsible for forwarding it, within an EventBatch data structure, asthe return value to the consumer it is connected to, in addition to setting the output parameter to FALSE. Ifno event sequence is available to return to the consumer upon invocation of this operation, it willimmediately return with the output parameter to set to FALSE, and the return value not containing a validevent.

10.3.2.3.14.3 DisconnectSequencePullSupplier

The DisconnectSequencePullSupplier operation is invoked to terminate a connection between the targetSequencePullSupplier, and its associated consumer. This operation takes no input parameters andreturns no values. The result of this operation is that the target SequencePullSupplier will release allresources it had allocated to support the connection, and dispose its own object reference.

10.3.2.3.15 The ITxnSequencePullSupplier Interface

The ITxnSequencePullSupplier interface extends the ISequencePullSupplier interface to providetransactional support for pull style suppliers of sequences of Structured Events using the CORBATransaction Service (OTS). This enables the ability to treat such a supplier as an OTS Recoverable Serveror an XA Resource Manager. When transaction support is implemented, events are pulled by the channelwithin the context of a transaction. If the transmission fails for any reason, the transaction will be rolledback, and the channel discards any portion of the event(s) it has received. In this case, the supplier shouldalso restore any state necessary such as to indicate it had not sent the event(s), since other effects of thesame transaction (e.g., database changes) will also be undone.

10.3.2.3.16 The ISequencePushSupplier Interface

The ISequencePushSupplier interface supports the behavior of objects that transmit sequences ofStructured Events using push-style communication. It defines an operation which can be invoked todisconnect the push supplier from its associated consumer. In addition, the ISequencePushSupplierinterface inherits the INotifySubscribe interface described above, enabling a notification consumer toinform an instance supporting this interface whenever there is a change to the types of events it is interestedin receiving.



Note that an object supporting the ISequencePushSupplier interface can transmit events which canpotentially be received by any consumer connected to the channel, including those which consume events ina form other than a sequence of Structured Events. How events supplied to the channel in the form of asequence of Structured Events are internally mapped into different forms for delivery to consumers whichreceive events in a form other than a sequence of Structured Events is summarized in Table 2-2.

10.3.2.3.16.1 DisconnectSequencePushSupplier

The DisconnectSequencePushSupplier operation is invoked to terminate a connection between the targetSequencePushSupplier, and its associated consumer. This operation takes no input parameters andreturns no values. The result of this operation is that the target SequencePushSupplier will release allresources it had allocated to support the connection, and dispose its own object reference.

10.3.2.4 The IMSNotifyChannelAdmin ModuleThe IMSNotifyChannelAdmin module defines the interfaces necessary to create, configure, andadminister instances of a Notification Service event channel. It defines the different types of proxy interfaceswhich support connections from the various types of clients that are supported, the Admin interfaces, theEventChannel interface, and a factory interface for instantiating new channels.

10.3.2.4.1The IProxyConsumer Interface

The IProxyConsumer interface is intended to be an abstract interface that is inherited by the differentvarieties of proxy consumers that can be instantiated within a notification channel. It encapsulates thebehaviors common to all Notification Service proxy consumers. In particular, the IProxyConsumerinterface inherits the IQoSAdmin interface defined within the IMSNotification module, and theIFilterAdmin interface defined within the IMSNotifyFilter module. The former inheritance enables allproxy consumers to administer a list of associated QoS properties, while the latter inheritance enables allproxy consumers to administer a list of associated filter objects. Locally, the IProxyConsumer interfacedefines a readonly attribute which contains a reference to the ISupplierAdmin object that created it. Inaddition, the IProxyConsumer interface defines an operation that returns the list of event types a givenproxy consumer instance is configured to forward, and an operation which can be queried to determine whichmessage level QoS properties can be set on a per-event basis.

10.3.2.4.1.1ObtainSubscriptionTypes

The ObtainSubscriptionTypes operation accepts no parameters and returns a list of event type names. Thisreturned list represents the names of event types which consumers connected to the channel are interested inreceiving. Consumers express their interest in receiving particular types of events by configuring filtersassociated with the proxy suppliers to which they are connected to encapsulate constraints which expresssubscriptions to specific event instances. Such subscriptions could be based on the types and/or contents ofevents. The proxy suppliers extract the event type information from these subscriptions, and share it withthe proxy consumer objects connected to the same channel. Supplier objects can thus obtain thisinformation from the channel by invoking the ObtainSubscriptionTypes operation on the proxy consumerobject to which they are connected. This information enables suppliers to suppress sending types of eventsto the channel in which no consumer is currently interested.

10.3.2.4.1.2ValidateEventQos

The ValidateEventQos operation accepts as input a sequence of QoS property name-value pairs whichspecify a set of QoS settings that a client is interested in setting on a per-event basis. Note that the QoSproperty settings contained in the optional header fields of a Structured Event may differ from those that areconfigured on a given proxy object. This operation is essentially a check to see if the target proxy objectwill honor the setting of a set of QoS properties on a per-event basis to values that may conflict with thoseset on the proxy itself. If any of the requested settings would not be honored by the target object on a per-event basis, the operation raises the UnsupportedQoS exception. This exception contains as data asequence of data structures, each of which identifies the name of a QoS property in the input list whose



requested setting could not be satisfied, along with an error code and a range of settings for the propertywhich could be satisfied. The meanings of the error codes which might be returned are described in Table 2-4.

If all requested QoS property value settings could be satisfied by the target object, the operation returnssuccessfully with an output parameter that contains a sequence of PropertyRange data structures. Eachelement in this sequence includes the name of a an additional QoS property whose setting is supported bythe target object on a per-event basis and which could have been included on the input list while stillresulting in a successful return from the operation. Each element also includes the range of values thatwould have been acceptable for each such property.

10.3.2.4.2The IProxySupplier Interface

The IProxySupplier interface is intended to be an abstract interface that is inherited by the differentvarieties of proxy suppliers that can be instantiated within a notification channel. It encapsulates thebehaviors common to all Notification Service proxy suppliers. In particular, the IProxySupplierinterface inherits the IQoSAdmin interface defined within the IMSNotification module, and theIFilterAdmin interface defined within the IMSNotifyFilter module. The former inheritance enables allproxy suppliers to administer a list of associated QoS properties, while the latter inheritance enables allproxy suppliers to administer a list of associated filter objects. Locally, the IProxySupplier interfacedefines a readonly attribute which contains a reference to the IConsumerAdmin object that created it. Inaddition, the ProxySupplier interface defines attributes that associate with each proxy supplier two mappingfilter objects, one for priority and one for lifetime. As described in section 2.3.1, these mapping filterobjects enable proxy suppliers to be configured to alter the way they treat events with respect to theirpriority and lifetime based on the type and contents of each individual event. Lastly, the IProxySupplierinterface defines an operation that returns the list of event types that a given proxy supplier couldpotentially forward to its associated consumer, and an operation which can be queried to determine whichmessage level QoS properties can be set on a per-event basis.

10.3.2.4.2.1priorityFilter

The PriorityFilter attribute contains a reference to an object supporting the IMappingFilter interfacedefined in the IMSNotifyFilter module. Such an object encapsulates a list of constraint-value pairs,where each constraint is a boolean expression based on the type and contents of an event, and the value is apossible priority setting for the event. Upon receipt of each event by a proxy supplier object whosePriorityFilter attribute contains a non-nil reference, the proxy supplier will invoke the appropriate variant ofthe Match operation supported by the mapping filter object. The mapping filter object will proceed to applyits encapsulated constraints to the event, and return the one with the highest associated priority settingwhich evaluates to TRUE, or else its associated defaultValue if no constraints evaluate to TRUE. Uponreturn from the Match operation, if the output parameter is TRUE, the proxy supplier treats the event withrespect to its priority according to the return value, as opposed to a priority setting contained within theevent. If the output parameter is FALSE, the proxy supplier will treat the event with respect to its priorityaccording to the value set for the priority property in the event header if this property is present, otherwiseit will use the output parameter returned from the Match operation (i.e., the default value of the mappingfilter object).

10.3.2.4.2.2lifetimeFilter

The lifetime_filter attribute contains a reference to an object supporting the IMappingFilter interfacedefined in the IMSNotifyFilter module. Such an object encapsulates a list of constraint-value pairs,where each constraint is a boolean expression based on the type and contents of an event, and the value is apossible lifetime setting for the event. Upon receipt of each event by a proxy supplier object whoselifetimeFilter attribute contains a non-nil reference, the proxy supplier will invoke the appropriate variant ofthe Match operation supported by the mapping filter object. The mapping filter object will proceed to applyits encapsulated constraints to the event, and return the one with the highest associated lifetime settingwhich evaluates to TRUE, or else its associated defaultValue if no constraints evaluate to TRUE. Upon



return from the Match operation, if the output parameter is TRUE, the proxy supplier treats the event withrespect to its lifetime according to the return value, as opposed to a lifetime setting contained within theevent. If the output parameter is FALSE, the proxy supplier will treat the event with respect to its lifetimeaccording to the value set for the lifetime property in the event header if this property is present, otherwiseit will use the output parameter returned from the Match operation (i.e., the default value of the mappingfilter object).

10.3.2.4.2.3ObtainOfferedTypes

The ObtainOfferedTypes operation accepts no parameters and returns a list of event type names. Eachelement of the returned list names a type of event that the target proxy supplier object could potentiallyforward to its associated consumer. Note that through inheritance, all proxy consumer objects will supportthe INotifyPublish interface defined in the IMSNotifyComm module. This interface supports theOfferChange operation, which can be invoked by suppliers each time there is a change to the list of eventtypes they plan to supply to their associated consumer. Thus, this mechanism relies on event supplierskeeping the channel informed of the types of events they plan to supply by invoking the OfferChangeoperation on their associated proxy consumer object. Internally to the channel, the proxy consumers willshare the information about event types that will be supplied to the channel with the proxy supplier objectsassociated with the channel. This enables consumers to discover the types of events that could by suppliedto them by the channel by invoking the ObtainOfferedTypes operation on their associated proxy supplier.

10.3.2.4.2.4ValidateEventQos

The ValidateEventQos operation accepts as input a sequence of QoS property name-value pairs whichspecify a set of QoS settings that a client is interested in setting on a per-event basis. Note that the QoSproperty settings contained in the optional header fields of a Structured Event may differ from those that areconfigured on a given proxy object. This operation is essentially a check to see if the target proxy objectwill honor the setting of a set of QoS properties on a per-event basis to values that may conflict with thoseset on the proxy itself. If any of the requested settings would not be honored by the target object on a per-event basis, the operation raises the UnsupportedQoS exception. This exception contains as data asequence of data structures, each of which identifies the name of a QoS property in the input list whoserequested setting could not be satisfied, along with an error code and a range of settings for the propertywhich could be satisfied. The meanings of the error codes which might be returned are described in Table 2-4.If all requested QoS property value settings could be satisfied by the target object, the operation returnssuccessfully with an output parameter that contains a sequence of PropertyRange data structures. Eachelement in this sequence includes the name of a an additional QoS property whose setting is supported bythe target object on a per-event basis and which could have been included on the input list while stillresulting in a successful return from the operation. Each element also includes the range of values thatwould have been acceptable for each such property.

10.3.2.4.3The IProxyPushConsumer Interface

The IProxyPushConsumer interface supports connections to the channel by suppliers who will pushevents to the channel as untyped Anys. Note that such suppliers are identical to OMG Event Service push-style suppliers of untyped events. The IProxyPushConsumer interface defined here, however, supportsevent filtering and configuration of various QoS properties. Thus, this interface enables OMG EventService style untyped event suppliers to take advantage of these new features offered by the NotificationService.

Through inheritance of the IProxyConsumer interface, the IProxyPushConsumer interface supportsadministration of various QoS properties, administration of a list of associated filter objects, and a readonlyattribute containing the reference of the ISupplierAdmin object which created it. In addition, thisinheritance implies that a IProxyPushConsumer instance supports an operation which will return thelist of event types which consumers connected to the same channel are interested in receiving, and anoperation which can return information about the instance’s ability to accept a per-event QoS request.



The IProxyPushConsumer interface inherits the INotifyPublish interface defined in theIMSNotifyComm module, enabling its associated supplier to inform it whenever the list of event typeswhich the supplier plans to supply changes.

The IProxyPushConsumer interface also inherits from the IPushConsumer interface defined withinthe IMSEventComm module of the OMG Event Service. This interface supports the Pull operationwhich the supplier connected to a IProxyPushConsumer instance will invoke to send an event to thechannel in the form of an Any, and the operation required to disconnect the IProxyPushConsumer fromits associated supplier. Finally, the IProxyPushConsumer interface defines the operation which can beinvoked by a push supplier to establish the connection over which the push supplier will send events to thechannel.

10.3.2.4.3.1ConnectAnyPushSupplier

The ConnectAnyPushSupplier operation accepts as an input parameter the reference to an object supportingthe IPushSupplier interface defined within the IMSEventComm module of the OMG Event Service.This reference is that of a supplier which plans to push events to the channel with which the target object isassociated in the form of untyped Anys. This operation is thus invoked in order to establish a connectionbetween a push-style supplier of events in the form of Anys, and the notification channel. Once established,the supplier can proceed to send events to the channel by invoking the push operation supported by thetarget IProxyPushConsumer instance. If the target object of this operation is already connected to apush supplier object, the AlreadyConnected exception will be raised.

10.3.2.4.4The ITxnProxyPushConsumer Interface

The ITxnProxyPushConsumer interface supports connections to the channel by suppliers who willpush events to the channel as untyped anys. It adds transactional behavior of these events to the functionsprovided in the IProxyPushConsumer interface. Events pushed to the channel within the context of atransaction do not logically enter the channel until the supplier commits the transaction. If the supplieraborts the transaction, any event(s) it had supplied are thus discarded by the channel, and the channelproceeds to behave as if it had never received these events.

10.3.2.4.5The IStructuredProxyPushConsumer Interface

The IStructuredProxyPushConsumer interface supports connections to the channel by suppliers whowill push events to the channel as Structured Events. Through inheritance of the IProxyConsumerinterface, the IStructuredProxyPushConsumer interface supports administration of various QoSproperties, administration of a list of associated filter objects, and a readonly attribute containing thereference of the ISupplierAdmin object which created it. In addition, this inheritance implies that aIStructuredProxyPushConsumer instance supports an operation which will return the list of eventtypes which consumers connected to the same channel are interested in receiving, and an operation whichcan return information about the instance’s ability to accept a per-event QoS request.

The IStructuredProxyPushConsumer interface also inherits from the IStructuredPushConsumerinterface defined in the IMSNotifyComm module. This interface supports the operation which enables asupplier of Structured Events to push them to the IStructuredProxyPushConumer, and also theoperation which can be invoked to close down the connection from the supplier to theIStructuredProxyPushConsumer. In addition, since the IStructuredPushConsumer interfaceinherits from the INotifyPublish interface, a supplier can inform theIStructuredProxyPushConsumer to which it is connected whenever the list of event types it plans tosupply to the channel changes.

Lastly, the IStructuredProxyPushConsumer interface defines a method that can be invoked by a push-style supplier of Structured Events in order to establish a connection between the supplier and a notificationchannel over which the supplier will proceed to send events.



10.3.2.4.5.1ConnectStructuredPushSupplier

The ConnectStructuredPushSupplier operation accepts as an input parameter the reference to an objectsupporting the IStructuredPushSupplier interface defined within the IMSNotifyComm module.This reference is that of a supplier which plans to push events to the channel with which the target object isassociated in the form of Structured Events. This operation is thus invoked in order to establish aconnection between a push-style supplier of events in the form of Structured Events, and the notificationchannel. Once established, the supplier can proceed to send events to the channel by invoking thePushStructuredEvent operation supported by the target IStructuredProxyPushConsumer instance. Ifthe target object of this operation is already connected to a push supplier object, the AlreadyConnectedexception will be raised.

10.3.2.4.6The ITxnStructuredProxyPushConsumer Interface

The ITxnStructuredProxyPushConsumer interface supports connections to the channel by supplierswho will push events to the channel as Structured Events. It adds transactional behavior of these events tothe functions provided in the IStructuredProxyPushConsumer interface. Events pushed to the channelwithin the context of a transaction do not logically enter the channel until the supplier commits thetransaction. If the supplier aborts the transaction, any event(s) it had supplied are thus discarded by thechannel, and the channel proceeds to behave as if it had never received these events.

10.3.2.4.7The ISequenceProxyPushConsumer Interface

The ISequenceProxyPushConsumer interface supports connections to the channel by suppliers whowill push events to the channel as sequences of Structured Events. Through inheritance of theIProxyConsumer interface, the ISequenceProxyPushConsumer interface supports administrationof various QoS properties, administration of a list of associated filter objects, and a readonly attributecontaining the reference of the ISupplierAdmin object which created it. In addition, this inheritanceimplies that a ISequenceProxyPushConsumer instance supports an operation which will return thelist of event types which consumers connected to the same channel are interested in receiving, and anoperation which can return information about the instance’s ability to accept a per-event QoS request.

The ISequenceProxyPushConsumer interface also inherits from the ISequencePushConsumerinterface defined in the IMSNotifyComm module. This interface supports the operation which enables asupplier of sequences of Structured Events to push them to the ISequenceProxyPushConumer, andalso the operation which can be invoked to close down the connection from the supplier to theISequenceProxyPushConsumer. In addition, since the ISequencePushConsumer interface inheritsfrom the INotifyPublish interface, a supplier can inform the ISequenceProxyPushConsumer towhich it is connected whenever the list of event types it plans to supply to the channel changes.

Lastly, the ISequenceProxyPushConsumer interface defines a method that can be invoked by a push-style supplier of sequences of Structured Events in order to establish a connection between the supplier anda notification channel over which the supplier will proceed to send events.

10.3.2.4.7.1ConnectSequencePushSupplier

The ConnectSequencePushSupplier operation accepts as an input parameter the reference to an objectsupporting the ISequencePushSupplier interface defined within the IMSNotifyComm module. Thisreference is that of a supplier which plans to push events to the channel with which the target object isassociated in the form of sequences of Structured Events. This operation is thus invoked in order toestablish a connection between a push-style supplier of events in the form of sequences of StructuredEvents, and the notification channel. Once established, the supplier can proceed to send events to thechannel by invoking the PushStructuredEvents operation supported by the targetISequenceProxyPushConsumer instance. If the target object of this operation is already connected to apush supplier object, the AlreadyConnected exception will be raised.

10.3.2.4.8The ITxnSequenceProxyPushConsumer Interface



The ITxnSequenceProxyPushConsumer interface supports connections to the channel by supplierswho will push events to the channel as a sequence of Structured Events. It adds transactional behavior ofthese events to the functions provided in the ISequenceProxyPushConsumer interface. Events pushedto the channel within the context of a transaction do not logically enter the channel until the suppliercommits the transaction. If the supplier aborts the transaction, any event(s) it had supplied are thus discardedby the channel, and the channel proceeds to behave as if it had never received these events.

10.3.2.4.9The IProxyPullSupplier Interface

The IProxyPullSupplier interface supports connections to the channel by consumers who will pullevents from the channel as untyped Anys. Note that such consumers are identical to OMG Event Servicepull-style consumers of untyped events. The IProxyPullSupplier interface defined here, however,supports event filtering and configuration of various QoS properties. Thus, this interface enables OMGEvent Service style untyped event consumers to take advantage of these new features offered by theNotification Service.Through inheritance of the IProxySupplier interface, the IProxyPullSupplier interface supportsadministration of various QoS properties, administration of a list of associated filter objects, mappingfilters for event priority and lifetime, and a readonly attribute containing the reference of theIConsumerAdmin object which created it. In addition, this inheritance implies that aIProxyPullSupplier instance supports an operation which will return the list of event types which theproxy supplier will potentially by supplying, and an operation which can return information about theinstance’s ability to accept a per-event QoS request.

The IProxyPullSupplier interface inherits the INotifySubscribe interface defined in theIIMSNotifyComm module, enabling it to be notified whenever its associated consumer changes the listof event types it is interested in receiving. This notification occurs via the callback mechanism described insection 2.3.

The IProxyPullSupplier interface also inherits from the IPullSupplier interface defined within theIMSEventComm module of the OMG Event Service. This interface supports the pull and try_pulloperations which the consumer connected to a IProxyPullSupplier instance will invoke to receive anevent from the channel in the form of an Any, and the operation required to disconnect theIProxyPullSupplier from its associated consumer. Finally, the IProxyPullSupplier interface definesthe operation which can be invoked by a pull consumer to establish the connection over which the pullconsumer will receive events from the channel.

10.3.2.4.9.1ConnectAnyPullConsumer

The ConnectAnyPullConsumer operation accepts as an input parameter the reference to an objectsupporting the IPullConsumer interface defined within the IMSEventComm module of the OMGEvent Service. This reference is that of a consumer which plans to pull events from the channel with whichthe target object is associated in the form of untyped Anys. This operation is thus invoked in order toestablish a connection between a pull-style consumer of events in the form of Anys, and the notificationchannel. Once established, the consumer can proceed to receive events from the channel by invoking thePull or TryPull operations supported by the target IProxyPullSupplier instance. If the target object ofthis operation is already connected to a pull consumer object, the AlreadyConnected exception will beraised.

10.3.2.4.10 The ITxnProxyPullSupplier Interface

The ITxnProxyPullSupplier interface supports connections to the channel by consumers who will pullevents from the channel as untyped anys. It adds transactional behavior of these events to the functionsprovided in the IProxyPullSupplier interface. Events pulled from the channel within the context of atransaction are not deleted from a proxy supplier’s queue until the consumer performing the pulloperation(s) commits the transaction. If the transaction aborts, the channel treats the event(s) as if they hadnot been pulled from the proxy supplier involved in the transaction. In this case, the application should



discard any portion of the event(s) it had received during the transaction, as other effects of the transaction(e.g., database updates) will also be undone.

10.3.2.4.11 The IStructuredProxyPullSupplier Interface

The IStructuredProxyPullSupplier interface supports connections to the channel by consumers whowill pull events from the channel as Structured Events. Through inheritance of the IProxySupplierinterface, the IStructuredProxyPullSupplier interface supports administration of various QoSproperties, administration of a list of associated filter objects, and a readonly attribute containing thereference of the IConsumerAdmin object which created it. In addition, this inheritance implies that aIStructuredProxyPullSupplier instance supports an operation which will return the list of event typeswhich the proxy supplier will potentially by supplying, and an operation which can return informationabout the instance’s ability to accept a per-event QoS request.

The IStructuredProxyPullSupplier interface also inherits from the IStructuredPullSupplierinterface defined in the IMSNotifyComm module. This interface supports the operations which enable aconsumer of Structured Events to pull them from the IStructuredProxyPullSupplier, and also theoperation which can be invoked to close down the connection from the consumer to theIStructuredProxyPullSupplier. In addition, since the IStructuredPullSupplier interface inheritsfrom the INotifySubscribe interface, a IStructuredProxyPullSupplier can be notified whenever thelist of event types which its associated consumer is interested in receiving changes. This notification occursvia the callback mechanism described in section 2.3.

Lastly, the IStructuredProxyPullSupplier interface defines a method that can be invoked by a pull-style consumer of Structured Events in order to establish a connection between the consumer and anotification channel over which the consumer will proceed to receive events.

10.3.2.4.11.1 ConnectStructuredPullConsumer

The ConnectStructuredPullConsumer operation accepts as an input parameter the reference to an objectsupporting the IStructuredPullConsumer interface defined within the IMSNotifyComm module.This reference is that of a consumer which plans to pull events from the channel to which the target objectis associated in the form of Structured Events. This operation is thus invoked in order to establish aconnection between a pull-style consumer of events in the form of Structured Events, and the notificationchannel. Once established, the consumer can proceed to receive events from the channel by invoking thePullStructuredEvent or TryPullStructuredEvent operations supported by the targetIStructuredProxyPullSupplier instance. If the target object of this operation is already connected to apull consumer object, the AlreadyConnected exception will be raised.

10.3.2.4.12 The ITxnStructuredProxyPullSupplier Interface

The ITxnStructuredProxyPullSupplier interface supports connections to the channel by consumerswho will pull events from the channel as Structured Events. It adds transactional behavior of these events tothe functions provided in the IStructuredProxyPullSupplier interface. Events pulled from the channelwithin the context of a transaction are not deleted from a proxy supplier’s queue until the consumerperforming the pull operation(s) commits the transaction. If the transaction aborts, the channel treats theevent(s) as if they had not been pulled from the proxy supplier involved in the transaction. In this case, theapplication should discard any portion of the event(s) it had received during the transaction, as other effectsof the transaction (e.g., database updates) will also be undone.

10.3.2.4.13 The ISequenceProxyPullSupplier Interface

The ISequenceProxyPullSupplier interface supports connections to the channel by consumers whowill pull events from the channel as sequences of Structured Events. Through inheritance of theIProxySupplier interface, the ISequenceProxyPullSupplier interface supports administration ofvarious QoS properties, administration of a list of associated filter objects, and a readonly attributecontaining the reference of the IConsumerAdmin object which created it. In addition, this inheritance



implies that a ISequenceProxyPullSupplier instance supports an operation which will return the listof event types which the proxy supplier will potentially by supplying, and an operation which can returninformation about the instance’s ability to accept a per-event QoS request.

The ISequenceProxyPullSupplier interface also inherits from the ISequencePullSupplierinterface defined in the IMSNotifyComm module. This interface supports the operations which enable aconsumer of sequences of Structured Events to pull them from the ISequenceProxyPullSupplier, andalso the operation which can be invoked to close down the connection from the consumer to theISequenceProxyPullSupplier. In addition, since the ISequencePullSupplier interface inheritsfrom the INotifySubscribe interface, a ISequenceProxyPullSupplier can be notified whenever thelist of event types which its associated consumer is interested in receiving changes. This notification occursvia the callback mechanism described in section 2.3.

Lastly, the ISequenceProxyPullSupplier interface defines a method that can be invoked by a pull-styleconsumer of sequences of Structured Events in order to establish a connection between the consumer and anotification channel over which the consumer will proceed to receive events.

10.3.2.4.13.1 ConnectSequencePullConsumer

The ConnectSequencePullConsumer operation accepts as an input parameter the reference to an objectsupporting the ISequencePullConsumer interface defined within the IMSNotifyComm module.This reference is that of a consumer which plans to pull events from the channel to which the target objectis associated in the form of sequences of Structured Events. This operation is thus invoked in order toestablish a connection between a pull-style consumer of events in the form of sequences of StructuredEvents, and the notification channel. Once established, the consumer can proceed to receive events from thechannel by invoking the PullStructuredEvents or TryPullStructuredEvents operations supported by thetarget ISequenceProxyPullSupplier instance. If the target object of this operation is already connectedto a pull consumer object, the AlreadyConnected exception will be raised.

10.3.2.4.14 The ITxnSequenceProxyPullSupplier Interface

The ITxnSequenceProxyPullSupplier interface supports connections to the channel by consumerswho will pull events from the channel as a sequence of Structured Events. It adds transactional behavior ofthese events to the functions provided in the ISequenceProxyPullSupplier interface. Events pulledfrom the channel within the context of a transaction are not deleted from a proxy supplier’s queue until theconsumer performing the pull operation(s) commits the transaction. If the transaction aborts, the channeltreats the event(s) as if they had not been pulled from the proxy supplier involved in the transaction. In thiscase, the application should discard any portion of the event(s) it had received during the transaction, asother effects of the transaction (e.g., database updates) will also be undone.

10.3.2.4.15 The IProxyPullConsumer Interface

The IProxyPullConsumer interface supports connections to the channel by suppliers who will makeevents available for pulling to the channel as untyped Anys. Note that such suppliers are identical to OMGEvent Service pull-style suppliers of untyped events. The IProxyPullConsumer interface defined here,however, supports event filtering and configuration of various QoS properties. Thus, this interface enablesOMG Event Service style untyped event suppliers to take advantage of these new features offered by theNotification Service.

Through inheritance of the IProxyConsumer interface, the IProxyPullConsumer interface supportsadministration of various QoS properties, administration of a list of associated filter objects, and a readonlyattribute containing the reference of the ISupplierAdmin object which created it. In addition, thisinheritance implies that a IProxyPullConsumer instance supports an operation which will return thelist of event types which consumers connected to the same channel are interested in receiving, and anoperation which can return information about the instance’s ability to accept a per-event QoS request.



The IProxyPullConsumer interface inherits the INotifyPublish interface defined in theIMSNotifyComm module, enabling its associated supplier to inform it whenever the list of event typeswhich the supplier plans to supply changes. The IProxyPullConsumer interface also inherits from theIPullConsumer interface defined within the IMSEventComm module of the OMG Event Service.This interface supports the operation required to disconnect the IProxyPullConsumer from its associatedsupplier. Finally, the IProxyPullConsumer interface defines the operation which can be invoked by apull supplier to establish the connection over which the pull supplier will send events to the channel.

10.3.2.4.15.1 ConnectAnyPullSupplier

The ConnectAnyPullSupplier operation accepts as an input parameter the reference to an object supportingthe IPullSupplier interface defined within the IMSEventComm module of the OMG Event Service.This reference is that of a supplier which plans to make events available for pulling to the channel withwhich the target object is associated in the form of untyped Anys. This operation is thus invoked in order toestablish a connection between a pull-style supplier of events in the form of Anys, and the notificationchannel. Once established, the channel can proceed to receive events from the supplier by invoking the Pullor TryPull operations supported by the supplier (whether the channel will invoke Pull or TryPull, and thefrequency with which it will perform such invocations, is a detail which is specific to the implementationof the channel). If the target object of this operation is already connected to a pull supplier object, theAlreadyConnected exception will be raised. An implementation of the IProxyPullConsumerinterface may impose additional requirements on the interface supported by a pull supplier (e.g., it may bedesigned to invoke some operation other than Pull or TryPull in order to receive events). If the pull supplierbeing connected does not meet those requirements, this operation raises the TypeError exception.

10.3.2.4.16 The IStructuredProxyPullConsumer Interface

The IStructuredProxyPullConsumer interface supports connections to the channel by suppliers whowill make events available for pulling to the channel as Structured Events. Through inheritance of theIProxyConsumer interface, the IStructuredProxyPullConsumer interface supports administrationof various QoS properties, administration of a list of associated filter objects, and a readonly attributecontaining the reference of the ISupplierAdmin object which created it. In addition, this inheritanceimplies that a IStructuredProxyPullConsumer instance supports an operation which will return thelist of event types which consumers connected to the same channel are interested in receiving, and anoperation which can return information about the instance’s ability to accept a per-event QoS request.

The IStructuredProxyPullConsumer interface also inherits from the IStructuredPullConsumerinterface defined in the IMSNotifyComm module. This interface supports the operation which can beinvoked to close down the connection from the supplier to the IStructuredProxyPullConsumer. Inaddition, since the IStructuredPullConsumer interface inherits from the INotifyPublish interface, asupplier can inform the IStructuredProxyPullConsumer to which it is connected whenever the list ofevent types it plans to supply to the channel changes.

Lastly, the IStructuredProxyPullConsumer interface defines a method that can be invoked by a pull-style supplier of Structured Events in order to establish a connection between the supplier and a notificationchannel over which the supplier will proceed to send events.

10.3.2.4.16.1 ConnectStructuredPullSupplier

The ConnectStructuredPullSupplier operation accepts as an input parameter the reference to an objectsupporting the IStructuredPullSupplier interface defined within the IMSNotifyComm module.This reference is that of a supplier which plans to make events available for pulling to the channel withwhich the target object is associated in the form of Structured Events. This operation is thus invoked inorder to establish a connection between a pull-style supplier of events in the form of Structured Events, andthe notification channel. Once established, the channel can proceed to receive events from the supplier byinvoking the PullStructuredEvent or TryPullStructuredEvent operations supported by the supplier (whetherthe channel will invoke PullStructuredEvent or TryPullStructuredEvent, and the frequency with which it



will perform such invocations, is a detail which is specific to the implementation of the channel). If thetarget object of this operation is already connected to a pull supplier object, the AlreadyConnectedexception will be raised. An implementation of the IStructuredProxyPullConsumer interface mayimpose additional requirements on the interface supported by a pull supplier (e.g., it may be designed toinvoke some operation other than PullStructuredEvent or TryPullStructuredEvent in order to receiveevents). If the pull supplier being connected does not meet those requirements, this operation raises theTypeError exception.

10.3.2.4.17 The ISequenceProxyPullConsumer Interface

The ISequenceProxyPullConsumer interface supports connections to the channel by suppliers whowill make events available for pulling to the channel as sequences of Structured Events. Throughinheritance of the IProxyConsumer interface, the ISequenceProxyPullConsumer interface supportsadministration of various QoS properties, administration of a list of associated filter objects, and a readonlyattribute containing the reference of the ISupplierAdmin object which created it. In addition, thisinheritance implies that a ISequenceProxyPullConsumer instance supports an operation which willreturn the list of event types which consumers connected to the same channel are interested in receiving, andan operation which can return information about the instance’s ability to accept a per-event QoS request.The ISequenceProxyPullConsumer interface also inherits from the ISequencePullConsumerinterface defined in the IMSNotifyComm module. This interface supports the operation which can beinvoked to close down the connection from the supplier to the ISequenceProxyPullConsumer. Inaddition, since the ISequencePullConsumer interface inherits from the INotifyPublish interface, asupplier can inform the ISequenceProxyPullConsumer to which it is connected whenever the list ofevent types it plans to supply to the channel changes. Lastly, the ISequenceProxyPullConsumerinterface defines a method that can be invoked by a pull-style supplier of sequences of Structured Events inorder to establish a connection between the supplier and a notification channel over which the supplier willproceed to send events.

10.3.2.4.17.1 ConnectSequencePullSupplier

The ConnectSequencePullSupplier operation accepts as an input parameter the reference to an objectsupporting the ISequencePullSupplier interface defined within the IMSNotifyComm module. Thisreference is that of a supplier which plans to make events available for pulling to the channel with whichthe target object is associated in the form of sequences of Structured Events. This operation is thus invokedin order to establish a connection between a pull-style supplier of events in the form of sequences ofStructured Events, and the notification channel. Once established, the channel can proceed to receive eventsfrom the supplier by invoking the PullStructuredEvents or TryPullStructuredEvents operations supportedby the supplier (whether the channel will invoke PullStructuredEvents or TryPullStructuredEvents, and thefrequency with which it will perform such invocations, is a detail which is specific to the implementationof the channel). If the target object of this operation is already connected to a pull supplier object, theAlreadyConnected exception will be raised. An implementation of theISequenceProxyPullConsumer interface may impose additional requirements on the interfacesupported by a pull supplier (e.g., it may be designed to invoke some operation other thanPullStructuredEvents or TryPullStructuredEvents in order to receive events). If the pull supplier beingconnected does not meet those requirements, this operation raises the TypeError exception.

10.3.2.4.18 The IProxyPushSupplier Interface

The IProxyPushSupplier interface supports connections to the channel by consumers who will receiveevents from the channel as untyped Anys. Note that such consumers are identical to OMG Event Servicepush-style consumers of untyped events. The IProxyPushSupplier interface defined here, however,supports event filtering and configuration of various QoS properties. Thus, this interface enables OMGEvent Service style untyped event consumers to take advantage of these new features offered by theNotification Service.



Through inheritance of the IProxySupplier interface, the IProxyPushSupplier interface supportsadministration of various QoS properties, administration of a list of associated filter objects, mappingfilters for event priority and lifetime, and a readonly attribute containing the reference of theIConsumerAdmin object which created it. In addition, this inheritance implies that aIProxyPushSupplier instance supports an operation which will return the list of event types which theproxy supplier will potentially by supplying, and an operation which can return information about theinstance’s ability to accept a per-event QoS request. The IProxyPushSupplier interface inherits theINotifySubscribe interface defined in the IMSNotifyComm module, enabling it to be notifiedwhenever its associated consumer changes the list of event types it is interested in receiving. Thisnotification occurs via the callback mechanism described in section 2.3.

The IProxyPushSupplier interface also inherits from the IPushSupplier interface defined within theIMSEventComm module of the OMG Event Service. This interface supports the operation required todisconnect the IProxyPushSupplier from its associated consumer.

Lastly, the IProxyPushSupplier interface defines the operation which can be invoked by a pushconsumer to establish the connection over which the push consumer will receive events from the channel.The IProxyPushSupplier interface also defines a pair of operations which can suspend and resume theconnection between a IProxyPushSupplier instance and its associated IPushConsumer. During thetime such a connection is suspended, the IProxyPushSupplier will accumulate events destined for theconsumer but not transmit them until the connection is resumed.

10.3.2.4.18.1 ConnectAnyPushConsumer

The ConnectAnyPushConsumer operation accepts as an input parameter the reference to an objectsupporting the IPushConsumer interface defined within the IMSEventComm module of the OMGEvent Service. This reference is that of a consumer which will receive events from the channel with whichthe target object is associated in the form of untyped Anys. This operation is thus invoked in order toestablish a connection between a push-style consumer of events in the form of Anys, and the notificationchannel. Once established, the IProxyPushSupplier will proceed to send events destined for theconsumer to it by invoking its push operation. If the target object of this operation is already connected to apush consumer object, the AlreadyConnected exception will be raised. An implementation of theIProxyPushSupplier interface may impose additional requirements on the interface supported by a pushconsumer (e.g., it may be designed to invoke some operation other than push in order to transmit events). Ifthe push consumer being connected does not meet those requirements, this operation raises the TypeErrorexception.

10.3.2.4.18.2 SuspendConnection

The SuspendConnection operation causes the target object supporting the IProxyPushSupplier interfaceto stop sending events to the IPushConsumer instance connected to it. This operation takes no inputparameters and returns no values. If the connection has been previously suspended using this operation andnot resumed by invoking ResumeConnection (described below), the ConnectionAlreadyInactiveexception is raised. Otherwise, the IProxyPushSupplier will not forward events to theIPushConsumer connected to it until ResumeConnection is subsequently invoked. During this time, theIProxyPushSupplier will continue to queue events destined for the IPushConsumer, although eventsthat time out prior to resumption of the connection will be discarded. Upon resumption of the connection,all queued events will be forwarded to the IPushConsumer.

10.3.2.4.18.3 ResumeConnection

The ResumeConnection operation causes the target object supporting the IProxyPushSupplier interfaceto resume sending events to the IPushConsumer instance connected to it. This operation takes no inputparameters and returns no values. If the connection has not been previously suspended using this operationby invoking SuspendConnection (described above), the ConnectionAlreadyActive exception is raised.Otherwise, the IProxyPushSupplier will resume forwarding events to the IPushConsumer connected



to it, including those which have been queued during the time the connection was suspended, and have notyet timed out.

10.3.2.4.19 The IStructuredProxyPushSupplier Interface

The IStructuredProxyPushSupplier interface supports connections to the channel by consumers whowill receive events from the channel as Structured Events. Through inheritance of the IProxySupplierinterface, the IStructuredProxyPushSupplier interface supports administration of various QoSproperties, administration of a list of associated filter objects, and a readonly attribute containing thereference of the IConsumerAdmin object which created it. In addition, this inheritance implies that aIStructuredProxyPushSupplier instance supports an operation which will return the list of eventtypes which the proxy supplier will potentially by supplying, and an operation which can returninformation about the instance’s ability to accept a per-event QoS request.

The IStructuredProxyPushSupplier interface also inherits from the IStructuredPushSupplierinterface defined in the IMSNotifyComm module. This interface supports the operation which can beinvoked to close down the connection from the consumer to the IStructuredProxyPushSupplier. Inaddition, since the IStructuredPushSupplier interface inherits from the INotifySubscribe interface,a IStructuredProxyPushSupplier can be notified whenever the list of event types which its associatedconsumer is interested in receiving changes. This notification occurs via the callback mechanism describedin section 2.3.

Lastly, the IStructuredProxyPushSupplier interface defines the operation which can be invoked by apush consumer to establish the connection over which the push consumer will receive events from thechannel. The IStructuredProxyPushSupplier interface also defines a pair of operations which cansuspend and resume the connection between a IStructuredProxyPushSupplier instance and itsassociated IStructuredPushConsumer. During the time such a connection is suspended, theIStructuredProxyPushSupplier will accumulate events destined for the consumer but not transmitthem until the connection is resumed.

10.3.2.4.19.1 ConnectStructuredPushConsumer

The ConnectStructuredPushConsumer operation accepts as an input parameter the reference to an objectsupporting the IStructuredPushConsumer interface defined within the IMSNotifyComm module.This reference is that of a consumer which will receive events from the channel with which the target objectis associated in the form of Structured Events. This operation is thus invoked in order to establish aconnection between a push-style consumer of events in the form of Structured Events, and thenotificationchannel. Once established, the IStructuredProxyPushSupplier will proceed to send events destined forthe consumer to it by invoking its PushStructuredEvent operation. If the target object of this operation isalready connected to a push consumer object, the AlreadyConnected exception will be raised. Animplementation of the IStructuredProxyPushSupplier interface may impose additional requirementson the interface supported by a push consumer (e.g., it may be designed to invoke some operation otherthan PushStructuredEvent in order to transmit events). If the push consumer being connected does not meetthose requirements, this operation raises the TypeError exception.


The SuspendConnection operation causes the target object supporting theIStructuredProxyPushSupplier interface to stop sending events to the IStructuredPushConsumerinstance connected to it. This operation takes no input parameters and returns no values. If the connectionhas been previously suspended using this operation and not resumed by invoking ResumeConnection(described below), the ConnectionAlreadyInactive exception is raised. Otherwise, theIStructuredProxyPushSupplier will not forward events to the IStructuredPushConsumerconnected to it until ResumeConnection is subsequently invoked. During this time, theIStructuredProxyPushSupplier will continue to queue events destined for theIStructuredPushConsumer, although events that time out prior to resumption of the connection will



be discarded. Upon resumption of the connection, all queued events will be forwarded to theIStructuredPushConsumer.


The ResumeConnection operation causes the target object supporting theIStructuredProxyPushSupplier interface to resume sending events to theIStructuredPushConsumer instance connected to it. This operation takes no input parameters andreturns no values. If the connection has not been previously suspended using this operation by invokingSuspendConnection (described above), the ConnectionAlreadyActive exception is raised. Otherwise,the IStructuredProxyPushSupplier will resume forwarding events to theIStructuredPushConsumer connected to it, including those which have been queued during the time theconnection was suspended, and have not yet timed out.

10.3.2.4.20 The ISequenceProxyPushSupplier Interface

The ISequenceProxyPushSupplier interface supports connections to the channel by consumers whowill receive events from the channel as sequences of Structured Events. Through inheritance of theIProxySupplier interface, the ISequenceProxyPushSupplier interface supports administration ofvarious QoS properties, administration of a list of associated filter objects, and a readonly attributecontaining the reference of the IConsumerAdmin object which created it. In addition, this inheritanceimplies that a ISequenceProxyPushSupplier instance supports an operation which will return the listof event types which the proxy supplier will potentially by supplying, and an operation which can returninformation about the instance’s ability to accept a per-event QoS request.

The ISequenceProxyPushSupplier interface also inherits from the ISequencePushSupplierinterface defined in the IMSNotifyComm module. This interface supports the operation which can beinvoked to close down the connection from the consumer to the ISequenceProxyPushSupplier. Inaddition, since the ISequencePushSupplier interface inherits from the INotifySubscribe interface, aISequenceProxyPushSupplier can be notified whenever the list of event types which its associatedconsumer is interested in receiving changes. This notification occurs via the callback mechanism describedin section 2.3.

Lastly, the ISequenceProxyPushSupplier interface defines the operation which can be invoked by apush consumer to establish the connection over which the push consumer will receive events from thechannel. The ISequenceProxyPushSupplier interface also defines a pair of operations which cansuspend and resume the connection between a ISequenceProxyPushSupplier instance and itsassociated ISequencePushConsumer. During the time such a connection is suspended, theISequenceProxyPushSupplier will accumulate events destined for the consumer but not transmit themuntil the connection is resumed.

10.3.2.4.20.1 ConnectSequencePushConsumer

The ConnectSequencePushConsumer operation accepts as an input parameter the reference to an objectsupporting the ISequencePushConsumer interface defined within the IMSNotifyComm module.This reference is that of a consumer which will receive events from the channel with which the target objectis associated in the form of sequences of Structured Events. This operation is thus invoked in order toestablish a connection between a push-style consumer of events in the form of sequences of StructuredEvents, and the notification channel. Once established, the ISequenceProxyPushSupplier will proceedto send events destined for the consumer to it by invoking its PushStructuredEvents operation. If the targetobject of this operation is already connected to a push consumer object, the AlreadyConnected exceptionwill be raised. An implementation of the ISequenceProxyPushSupplier interface may imposeadditional requirements on the interface supported by a push consumer (e.g., it may be designed to invokesome operation other than PushStructuredEvents in order to transmit events). If the push consumer beingconnected does not meet those requirements, this operation raises the TypeError exception.




The SuspendConnection operation causes the target object supporting theISequenceProxyPushSupplier interface to stop sending events to the ISequencePushConsumerinstance connected to it. This operation takes no input parameters and returns no values. If the connectionhas been previously suspended using this operation and not resumed by invoking resume_connection(described below), the ConnectionAlreadyInactive exception is raised. Otherwise, theISequenceProxyPushSupplier will not forward events to the ISequencePushConsumer connectedto it until ResumeConnection is subsequently invoked. During this time, theISequenceProxyPushSupplier will continue to queue events destined for theISequencePushConsumer, although events that time out prior to resumption of the connection will bediscarded. Upon resumption of the connection, all queued events will be forwarded to theISequencePushConsumer.


The ResumeConnection operation causes the target object supporting theISequenceProxyPushSupplier interface to resume sending events to the ISequencePushConsumerinstance connected to it. This operation takes no input parameters and returns no values. If the connectionhas not been previously suspended using this operation by invoking SuspendConnection (described above),the ConnectionAlreadyActive exception is raised. Otherwise, the ISequenceProxyPushSupplierwill resume forwarding events to the ISequencePushConsumer connected to it, including those whichhave been queued during the time the connection was suspended, and have not yet timed out.

10.3.2.4.21 The IConsumerAdmin Interface

The IConsumerAdmin interface defines the behavior supported by objects which create and manage listsof proxy supplier objects within a Notification Service event channel. Recall that a Notification Serviceevent channel can have any number of IConsumerAdmin instances associated with it. Each such instanceis responsible for creating and managing a list of proxy supplier objects that share a common set of QoSproperty settings, and a common set of filter objects. This feature enables clients to conveniently groupproxy supplier objects within a channel into groupings that each support a set of consumers with acommon set of QoS requirements and event subscriptions.

The IConsumerAdmin interface inherits the IQoSAdmin interface defined within theIMSNotification module, enabling each IConsumerAdmin instance to manage a set of QoS propertysettings. These QoS property settings are assigned as the default QoS property settings for any proxysupplier object created by a IConsumerAdmin instance. In addition, the IConsumerAdmin interfaceinherits from the IFilterAdmin interface defined within the IMSNotifyFilter module, enabling eachIConsumerAdmin instance to maintain a list of filter objects. These filter objects encapsulatesubscriptions that will apply to all proxy supplier objects that have been created by a givenIConsumerAdmin instance. In order to enable optimizing the notification of a group of proxy supplierobjects that have been created by the same IConsumerAdmin instance of changes to these shared filterobjects, the IConsumerAdmin interface also inherits from the INotifySubscribe interface defined inthe IMSNotifyComm module. This inheritance enables a IConsumerAdmin instance to be registeredas the callback object for notification of subscription changes made upon filter objects. TheIConsumerAdmin interface defined in the IMSNotifyChannelAdmin module also inherits from theIConsumerAdmin interface defined in the IMSEventChannelAdmin module. This inheritanceenables clients to use the IConsumerAdmin interface defined in the IMSNotifyChannelAdminmodule to create pure OMG Event Service style proxy supplier objects. Proxy supplier objects created inthis manner may not support configuration of QoS properties, and may not have associated filter objects. Inaddition, proxy supplier objects created through the inherited IConsumerAdmin interface will not haveunique identifiers associated with them, whereas proxy supplier objects created by invoking the operationssupported by the IConsumerAdmin interface defined in the IMSNotifyChannelAdmin module will.



Locally, the IConsumerAdmin interface supports a readonly attribute which maintains a reference to theIEventChannel instance that created a given IConsumerAdmin instance. The IConsumerAdmininterface also supports a readonly attribute which contains a numeric identifier which will be assigned to aninstance supporting this interface by its associated Notification Service event channel upon creation of theIConsumerAdmin instance. This identifier will be unique among all IConsumerAdmin instancescreated by a given channel.

As described above, due to inheritance from the IFilterAdmin interface, a IConsumerAdmin canmaintain a list of filter objects that will be applied to all proxy suppliers it creates. Also recall that eachproxy supplier may itself support a list of filter objects that apply only it. When combining multiple filterobjects within each of these two lists of filter objects that may be associated with a given proxy supplier,OR semantics are applied. However when combining these two lists during the evaluation of a given event,either AND or OR semantics may be applied. The choice is determined by an input flag upon creation ofthe IConsumerAdmin, and the operator that will be used for this purpose by a givenIConsumerAdmin is maintained in a readonly attribute.

The IConsumerAdmin interface also supports attributes which maintain references to priority andlifetime mapping filter objects. These mapping filter objects will be applied to all proxy supplier objectscreated by a given IConsumerAdmin instance. Each IConsumerAdmin instance assigns a uniquenumeric identifier to each proxy supplier object it maintains. The IConsumerAdmin interface supportsattributes which maintain the list of these unique identifiers associated with the proxy pull and the proxypush suppliers created by a given IConsumerAdmin instance. The IConsumerAdmin interface alsosupports an operation which, given the unique identifier of a proxy supplier a given IConsumerAdmininstance has created as input, will return the object reference of that proxy supplier object. Finally, theIConsumerAdmin interface supports operations which can create the various styles of proxy supplierobjects supported by the Notification Service event channel.

10.3.2.4.21.1 myID

The myID attribute is a readonly attribute which maintains the unique identifier of the targetIConsumerAdmin instance which is assigned to it upon creation by the Notification Service eventchannel.

10.3.2.4.21.2 myChannel

The myChannel attribute is a readonly attribute which maintains the object reference of the NotificationService event channel that created a given IConsumerAdmin instance.

10.3.2.4.21.3 myOperator

The myOperator attribute is a readonly attribute which maintains the information regarding whether AND orOR semantics will be used during the evaluation of a given event against a set of filter objects, whencombining the filter objects associated with the target IConsumerAdmin and those defined locally on agiven proxy supplier.

10.3.2.4.21.4 priorityFilter

The priorityFilter attribute maintains a reference to a mapping filter object which affects the way in whicheach proxy supplier object created by the target IConsumerAdmin instance treats each event it receiveswith respect to priority. Note that each proxy supplier object also has an associated attribute whichmaintains a reference to a mapping filter object for the priority property. This local mapping filter object isonly used by the proxy supplier in the event that the priorityFilter attribute of the IConsumerAdmininstance which created it is set to OBJECT_NIL. Otherwise, the mapping filter object referred to by thepriorityFilter attribute of the IConsumerAdmin is used instead of the mapping filter object referred to bythe priorityFilter attribute defined locally to the proxy supplier object.

10.3.2.4.21.5 lifetimeFilter



The lifetimeFilter attribute maintains a reference to a mapping filter object which affects the way in whicheach proxy supplier object created by the target IConsumerAdmin instance treats each event it receiveswith respect to lifetime. Note that each proxy supplier object also has an associated attribute whichmaintains a reference to a mapping filter object for the lifetime property. This local mapping filter object isonly used by the proxy supplier in the event that the lifetimeFilter attribute of the IConsumerAdmininstance which created it is set to OBJECT_NIL. Otherwise, the mapping filter object referred to by thelifetimeFilter attribute of the IConsumerAdmin is used instead of the mapping filter object referred to bythe lifetimeFilter attribute defined locally to the proxy supplier object.

10.3.2.4.21.6 pullSuppliers

The pullSuppliers attribute is a readonly attribute which contains the list of unique identifiers which havebeen assigned by a IConsumerAdmin instance to each pull-style proxy supplier object it has created.

10.3.2.4.21.7 pushSuppliers

The push_suppliers attribute is a readonly attribute which contains the list of unique identifiers which havebeen assigned by a IConsumerAdmin instance to each push-style proxy supplier object it has created.

10.3.2.4.21.8 GetProxySupplier

The GetProxySupplier operation accepts as an input parameter the numeric unique identifier associated withone of the proxy supplier objects which has been created by the target IConsumerAdmin instance. If theinput parameter does correspond to the unique identifier of a proxy supplier object that has been created bythe target IConsumerAdmin instance, that proxy supplier object’s reference is returned as the result ofthe operation. Otherwise, the ProxyNotFound exception is raised.

10.3.2.4.21.9 ObtainNotificationPullSupplier

The ObtainNotificationPullSupplier operation can create instances of the various types of pull-style proxysupplier objects defined within the IMSNotifyChannelAdmin module. Recall that three varieties ofpull-style proxy supplier objects are defined within this module: instances of the IProxyPullSupplierinterface support connections to pull consumers which receive events as Anys, instances of theIStructuredProxyPullSupplier interface support connections to pull consumers which receive eventsas Structured Events, and instances of the ISequenceProxyPullSupplier interface support connectionsto pull consumers which receive events as sequences of Structured Events.

The ObtainNotificationPullSupplier operation thus accepts as an input parameter a flag which indicateswhich style of pull-style proxy supplier instance should be created. If the number of consumers currentlyconnected to the channel with which the target IConsumerAdmin object is associated exceeds the valueof the maxConsumers administrative property, the AdminLimitExceeded exception is raised.Otherwise, the target IConsumerAdmin creates the new pull-style proxy supplier instance and assigns anumeric identifier to it that is unique among all proxy suppliers it has created. The unique identifier isreturned as the output parameter of the operation, and the reference to the new proxy supplier instance isreturned as the operation result.

10.3.2.4.21.10 ObtainNotificationPushSupplier

The ObtainNotificationPushSupplier operation can create instances of the various types of push-style proxysupplier objects defined within the IMSNotifyChannelAdmin module. Recall that three varieties ofpush-style proxy supplier objects are defined within this module: instances of the IProxyPushSupplierinterface support connections to push consumers which receive events as Anys, instances of theIStructuredProxyPushSupplier interface support connections to push consumers which receive eventsas Structured Events, and instances of the ISequenceProxyPushSupplier interface support connectionsto push consumers which receive events as sequences of Structured Events. TheObtainNotificationPushSupplier operation thus accepts as an input parameter a flag which indicates whichstyle of push-style proxy supplier instance should be created. If the number of consumers currentlyconnected to the channel with which the target IConsumerAdmin object is associated exceeds the value



of the maxConsumers administrative property, the AdminLimitExceeded exception is raised.Otherwise, the target IConsumerAdmin creates the new push-style proxy supplier instance and assigns anumeric identifier to it that is unique among all proxy suppliers it has created. The unique identifier isreturned as the output parameter of the operation, and the reference to the new proxy supplier instance isreturned as the operation result.

10.3.2.4.21.11 ObtainTxnNotificationPullSupplier

The ObtainTxnNotificationPullSupplier operation can create instances of the transactional variants of thepull style proxy supplier interfaces defined within the IMSNotifyChannelAdmin module. Recall thatthree varieties of transactional pull-style proxy supplier objects are defined within this module: instances ofthe ITxnProxyPullSupplier interface supporting connections to pull consumers which receive eventsas Anys, instances of the ITxnStructuredProxyPullSupplier interface supporting connections to pullconsumers which receive events as Structured Events, and instances of theITxnSequenceProxyPullSupplier interface supporting connections to pull consumers which receiveevents as sequences of Structured Events. All these interfaces are intended for consumers who requiretransactional semantics while pulling events from the channel.

The ObtainTxnNotificationPullSupplier operation thus accepts as an input parameter a flag which indicateswhich style of transactional pull-style proxy supplier instance should be created. If the number ofconsumers currently connected to the channel with which the target IConsumerAdmin object isassociated exceeds the value of the maxConsumers administrative property, theAdminLimitExceeded exception is raised. Otherwise, the target IConsumerAdmin creates the newtransactional pull-style proxy supplier instance and assigns a numeric identifier to it that is unique amongall proxy suppliers it has created. The unique identifier is returned as the output parameter of the operation,and the reference to the new transactional proxy supplier instance is returned as the operation result.

10.3.2.4.22 The ISupplierAdmin Interface

The ISupplierAdmin interface defines the behavior supported by objects which create and manage lists ofproxy consumer objects within a Notification Service event channel. Recall that a Notification Serviceevent channel can have any number of ISupplierAdmin instances associated with it. Each such instanceis responsible for creating and managing a list of proxy consumer objects that share a common set of QoSproperty settings, and a common set of filter objects. This feature enables clients to conveniently groupproxy consumer objects within a channel into groupings that each support a set of suppliers with acommon set of QoS requirements, and that make common event forwarding decisions driven by theassociation of a common set of filter objects. The ISupplierAdmin interface inherits the IQoSAdmininterface defined within the IMSNotification module, enabling each ISupplierAdmin instance tomanage a set of QoS property settings. These QoS property settings are assigned as the default QoSproperty settings for any proxy consumer object created by a ISupplierAdmin instance. In addition, theISupplierAdmin interface inherits from the IFilterAdmin interface defined within theIMSNotifyFilter module, enabling each ISupplierAdmin instance to maintain a list of filter objects.These filter objects encapsulate subscriptions that will apply to all proxy consumer objects that have beencreated by a given ISupplierAdmin instance. In order to enable optimizing the notification of a group ofproxy consumer objects that have been created by the same ISupplierAdmin instance of changes to thetypes of events being offered by suppliers, the ISupplierAdmin interface also inherits from theINotifyPublish interface defined in the IMSNotifyComm module. This inheritance enables aISupplierAdmin instance to be the target of an offer_change request made by a supplier object, and forthe change in event types being offered to be shared by all proxy consumer objects which were created bythe target ISupplierAdmin.

The ISupplierAdmin interface defined in the IMSNotifyChannelAdmin module also inherits fromthe ISupplierAdmin interface defined in the IMSEventChannelAdmin module. This inheritanceenables clients to use the ISupplierAdmin interface defined in the IMSNotifyChannelAdminmodule to create pure OMG Event Service style proxy consumer objects. Proxy consumer objects created in



this manner may not support configuration of QoS properties, and may not have associated filter objects. Inaddition, proxy consumer objects created through the inherited ISupplierAdmin interface will not haveunique identifiers associated with them, whereas proxy consumer objects created by invoking the operationssupported by the ISupplierAdmin interface defined in the IMSNotifyChannelAdmin module will.Locally, the ISupplierAdmin interface supports a readonly attribute which maintains a reference to theIEventChannel instance that created a given ISupplierAdmin instance. The ISupplierAdmininterface also supports a readonly attribute which contains a numeric identifier which will be assigned to aninstance supporting this interface by its associated Notification Service event channel upon creation of theISupplierAdmin instance. This identifier will be unique among all ISupplierAdmin instances createdby a given channel.

As described above, due to inheritance from the IFilterAdmin interface, a ISupplierAdmin canmaintain a list of filter objects that will be applied to all proxy consumers it creates. Also recall that eachproxy consumer may itself support a list of filter objects that apply only it. When combining multiplefilter objects within each of these two lists of filter objects that may be associated with a given proxyconsumer, OR semantics are applied. However when combining these two lists during the evaluation of agiven event, either AND or OR semantics may be applied. The choice is determined by an input flag uponcreation of the ISupplierAdmin, and the operator that will be used for this purpose by a givenISupplierAdmin is maintained in a readonly attribute.

Each ISupplierAdmin instance assigns a unique numeric identifier to each proxy consumer object itmaintains. The ISupplierAdmin interface supports attributes which maintain the list of these uniqueidentifiers associated with the proxy pull and the proxy push consumers created by a givenISupplierAdmin instance. The ISupplierAdmin interface also supports an operation which, given theunique identifier of a proxy consumer a given ISupplierAdmin instance has created as input, will returnthe object reference of that proxy consumer object. Finally, the ISupplierAdmin interface supportsoperations which can create the various styles of proxy consumer objects supported by the NotificationService event channel.

10.3.2.4.22.1 myID

The myID attribute is a readonly attribute which maintains the unique identifier of the targetISupplierAdmin instance which is assigned to it upon creation by the Notification Service eventchannel.

10.3.2.4.22.2 myChannel

The myChannel attribute is a readonly attribute which maintains the object reference of the NotificationService event channel that created a given ISupplierAdmin instance.

10.3.2.4.22.3 myOperator

The myOperator attribute is a readonly attribute which maintains the information regarding whether AND orOR semantics will be used during the evaluation of a given event against a set of filter objects, whencombining the filter objects associated with the target ISupplierAdmin and those defined locally on agiven proxy consumer.

10.3.2.4.22.4 pullConsumers

The pullConsumers attribute is a readonly attribute which contains the list of unique identifiers which havebeen assigned by a ISupplierAdmin instance to each pull-style proxy consumer object it has created.

10.3.2.4.22.5 pushConsumers

The push_consumers attribute is a readonly attribute which contains the list of unique identifiers whichhave been assigned by a ISupplierAdmin instance to each push-style proxy consumer object it hascreated.



10.3.2.4.22.6 GetProxyConsumer

The GetProxyConsumer operation accepts as an input parameter the numeric unique identifier associatedwith one of the proxy consumer objects which has been created by the target ISupplierAdmin instance.If the input parameter does correspond to the unique identifier of a proxy consumer object that has beencreated by the target ISupplierAdmin instance, that proxy consumer object’s reference is returned as theresult of the operation. Otherwise, the IProxyNotFound exception is raised.

10.3.2.4.22.7 ObtainNotificationPullConsumer

The ObtainNotificationPullConsumer operation can create instances of the various types of pull-style proxyconsumer objects defined within the IMSNotifyChannelAdmin module. Recall that three varieties ofpull-style proxy consumer objects are defined within this module: instances of the IProxyPullConsumerinterface support connections to pull suppliers which send events as Anys, instances of theIStructuredProxyPullConsumer interface support connections to pull suppliers which send events asStructured Events, and instances of the ISequenceProxyPullConsumer interface support connectionsto pull suppliers which send events as sequences of Structured Events.

The ObtainNotificationPullConsumer operation thus accepts as an input parameter a flag which indicateswhich style of pull-style proxy consumer instance should be created. If the number of suppliers currentlyconnected to the channel with which the target ISupplierAdmin object is associated exceeds the value ofthe maxSuppliers administrative property, the AdminLimitExceeded exception is raised. Otherwise,the target ISupplierAdmin creates the new pull-style proxy consumer instance and assigns a numericidentifier to it that is unique among all proxy consumers it has created. The unique identifier is returned asthe output parameter of the operation, and the reference to the new proxy consumer instance is returned asthe operation result.

10.3.2.4.22.8 ObtainNotificationPushConsumer

The ObtainNotificationPushConsumer operation can create instances of the various types of push-styleproxy consumer objects defined within the IMSNotifyChannelAdmin module. Recall that threevarieties of push-style proxy consumer objects are defined within this module: instances of theIProxyPushConsumer interface support connections to push suppliers which send events as Anys,instances of the IStructuredProxyPushConsumer interface support connections to push supplierswhich send events as Structured Events, and instances of the ISequenceProxyPushConsumer interfacesupport connections to push suppliers which send events as sequences of Structured Events.

The ObtainNotificationPushConsumer operation thus accepts as an input parameter a flag which indicateswhich style of push-style proxy consumer instance should be created. If the number of suppliers currentlyconnected to the channel with which the target ISupplierAdmin object is associated exceeds the value ofthe maxSuppliers administrative property, the AdminLimitExceeded exception is raised. Otherwise,the target ISupplierAdmin creates the new push-style proxy consumer instance and assigns a numericidentifier to it that is unique among all proxy consumers it has created. The unique identifier is returned asthe output parameter of the operation, and the reference to the new proxy consumer instance is returned asthe operation result.

10.3.2.4.22.9 ObtainTxnNotificationPushConsumer

The ObtainTxnNotificationPushConsumer operation can create instances of the various types oftransactional push-style proxy consumer objects defined within the IMSNotifyChannelAdmin module.Recall that three varieties of transactional push- style proxy consumer objects are defined within thismodule: instances of the ITxnProxyPushConsumer interface supporting connections to push supplierswhich send events as Anys, instances of the ITxnStructuredProxyPushConsumer interfacesupporting connections to push suppliers which send events as Structured Events, and instances of theITxnSequenceProxyPushConsumer interface supporting connections to push suppliers which sendevents as sequences of Structured Events. All these interfaces are intended for suppliers who requiretransactional semantics while pushing events to the channel.



The ObtainTxnNotificationPushConsumer operation thus accepts as an input parameter a flag whichindicates which style of transactional push-style proxy consumer instance should be created. If the numberof suppliers currently connected to the channel with which the target ISupplierAdmin object isassociated exceeds the value of the maxSuppliers administrative property, the AdminLimitExceededexception is raised. Otherwise, the target ISupplierAdmin creates the new transactional push-style proxyconsumer instance and assigns a numeric identifier to it that is unique among all proxy consumers it hascreated. The unique identifier is returned as the output parameter of the operation, and the reference to thenew transactional proxy consumer instance is returned as the operation result.

10.3.2.4.23 The IEventChannel Interface

The IEventChannel interface encapsulates the behaviors supported by a Notification Service eventchannel. This interface inherits from the IEventChannel interface defined within theIMSEventChannelAdmin module of the OMG Event Service, making an instance of the NotificationService IEventChannel interface fully backward compatible with an OMG Event Service style untypedevent channel. Inheritance of the IEventChannel interface defined within theIMSEventChannelAdmin module enables an instance of the IEventChannel interface defined withinthe IMSNotifyChannelAdmin module to create event service style IConsumerAdmin andISupplierAdmin instances. These instances can subsequently be used to create pure event service styleproxy interfaces, which support connections to pure event service style suppliers and consumers. Note thatwhile Notification Service style proxies and admin objects have unique identifiers associated with them,enabling their references to be obtained by invoking operations on the Notification Service style admin andevent channel interfaces, Event Service style proxies and admin objects do not have associated uniqueidentifiers, and thus cannot be returned by invoking an operation on the Notification Service style admin orevent channel interfaces. The IEventChannel interface defined within the IMSNotifyChannelAdminmodule also inherits from the IQoSAdmin and the IAdminPropertiesAdmin interfaces defined withinthe IMSNotification module. Inheritance of these interfaces enables a Notification Service style eventchannel to manage lists of associated QoS and administrative properties, respectively.

Locally, the IEventChannel interface supports a readonly attribute which maintains a reference to theIEventChannelFactory instance that created it. In addition, each instance of the IEventChannelinterface has an associated default IConsumerAdmin and an associated default ISupplierAdmininstance, both of which exist upon creation of the channel and which have the unique identifier of zero (notethat admin object identifiers only need to be unique among a given type of admin, implying that theidentifiers assigned to IConsumerAdmin objects can overlap those assigned to ISupplierAdminobjects). The IEventChannel interface supports readonly attributes which maintain references to thesedefault admin objects.

The IEventChannel interface supports operations which create new IConsumerAdmin andISupplierAdmin instances. In addition, the IEventChannel interface supports operations which canreturn references to the IConsumerAdmin and ISupplierAdmin instances associated with a givenIEventChannel instance, given the unique identifier of an admin object as input. Finally, theIEventChannel interface supports operations which return the sequence of unique identifiers of allIConsumerAdmin and ISupplierAdmin instances associated with a given IEventChannel instance.

10.3.2.4.23.1 myFactory

The myFactory attribute is a readonly attribute which maintains the object reference of the event channelfactory that created a given Notification Service IEventChannel instance.

10.3.2.4.23.2 defaultConsumerAdmin

The defaultConsumerAdmin attribute is a readonly attribute which maintains a reference to the defaultIConsumerAdmin instance associated with the target IEventChannel instance. Each IEventChannelinstance has an associated default IConsumerAdmin instance, which exists upon creation of the channel



and is assigned the unique identifier of zero. Subsequently, clients can create additional Event Service styleIConsumerAdmin instances by invoking the inherited forConsumers operation, and additionalNotification Service style IConsumerAdmin instances by invoking the NewForConsumers operationdefined by the IEventChannel interface.

10.3.2.4.23.3 defaultSupplierAdmin

The defaultSupplierAdmin attribute is a readonly attribute which maintains a reference to the defaultISupplierAdmin instance associated with the target IEventChannel instance. Each IEventChannelinstance has an associated default ISupplierAdmin instance, which exists upon creation of the channeland is assigned the unique identifier of zero. Subsequently, clients can create additional Event Service styleISupplierAdmin instances by invoking the inherited forSuppliers operation, and additional NotificationService style ISupplierAdmin instances by invoking the NewForSuppliers operation defined by theIEventChannel interface.

10.3.2.4.23.4 NewForConsumers

The NewForConsumers operation is invoked to create a new Notification Service styleIConsumerAdmin instance. The operation accepts as an input parameter a boolean flag which indicateswhether AND or OR semantics will be used when combining the filter objects associated with the newlycreated IConsumerAdmin instance with those associated with a supplier proxy which was created by theIConsumerAdmin during the evaluation of each event against a set of filter objects. The new instance isassigned a unique identifier by the target IEventChannel instance that is unique among allIConsumerAdmin instances currently associated with the channel. Upon completion, the operationreturns the reference to the new IConsumerAdmin instance as the result of the operation, and the uniqueidentifier assigned to the new IConsumerAdmin instance as the output parameter.

10.3.2.4.23.5 NewForSuppliers

The NewForSuppliers operation is invoked to create a new Notification Service style ISupplierAdmininstance. The operation accepts as an input parameter a boolean flag which indicates whether AND or ORsemantics will be used when combining the filter objects associated with the newly createdISupplierAdmin instance with those associated with a consumer proxy which was created by theISupplierAdmin during the evaluation of each event against a set of filter objects. The new instance isassigned a unique identifier by the target IEventChannel instance that is unique among allISupplierAdmin instances currently associated with the channel. Upon completion, the operation returnsthe reference to the new ISupplierAdmin instance as the result of the operation, and the unique identifierassigned to the new ISupplierAdmin instance as the output parameter.

10.3.2.4.23.6 GetConsumerAdmin

The GetConsumerAdmin operation returns a reference to one of the IConsumerAdmin instancesassociated with the target IEventChannel instance. The operation accepts as an input parameter a numericvalue which is intended to be the unique identifier of one of the IConsumerAdmin instances associatedwith the target IEventChannel instance. If this turns out to be the case, the object reference of theassociated IConsumerAdmin instance is returned as the operation result. Otherwise, theAdminNotFound exception is raised.Note that while a Notification Service style event channel can support both Event Service and NotificationService style IConsumerAdmin instances, only Notification Service style IConsumerAdmininstances have associated unique identifiers.

10.3.2.4.23.7 GetSupplierAdmin

The GetSupplierAdmin operation returns a reference to one of the ISupplierAdmin instances associatedwith the target IEventChannel instance. The operation accepts as an input parameter a numeric valuewhich is intended to be the unique identifier of one of the ISupplierAdmin instances associated with thetarget IEventChannel instance. If this turns out to be the case, the object reference of the associated



ISupplierAdmin instance is returned as the operation result. Otherwise, the AdminNotFoundexception is raised.

Note that while a Notification Service style event channel can support both Event Service and NotificationService style ISupplierAdmin instances, only Notification Service style ISupplierAdmin instanceshave associated unique identifiers.

10.3.2.4.23.8 GetAllConsumeradmins

The GetAllConsumerAdmins operation takes no input parameters and returns a sequence of the uniqueidentifiers assigned to all Notification Service style IConsumerAdmin instances which have been createdby the target IEventChannel instance.

10.3.2.4.23.9 GetAllSupplierAdmins

The GetAllSupplierAdmins operation takes no input parameters and returns a sequence of the uniqueidentifiers assigned to all Notification Service style ISupplierAdmin instances which have been createdby the target IEventChannel instance.

10.3.2.4.24 The IEventChannelFactory Interface

The EventChannelFactory interface defines operations for creating and managing new NotificationService style event channels. It supports a routine that creates new instances of Notification Service eventchannels and assigns unique numeric identifiers to them. In addition, the IEventChannelFactoryinterface supports a routine which can return the unique identifiers assigned to all event channels created bya given instance of IEventChannelFactory, and another routine which, given the unique identifier of anevent channel created by a target IEventChannelFactory instance, returns the object reference of that eventchannel.

10.3.2.4.24.1 CreateChannel

The CreateChannel operation is invoked to create a new instance of the Notification Service style eventchannel. This operation accepts two input parameters. The first input parameter is a list of name-value pairswhich specify the initial QoS property settings for the new channel. The second input parameter is a list ofname-value pairs which specify the initial administrative property settings for the new channel. If noimplementation of the IEventChannel interface exists that can support all of the requested QoS propertysettings, the UnsupportedQoS exception is raised. This exception contains as data a sequence of datastructures, each of which identifies the name of a QoS property in the input list whose requested settingcould not be satisfied, along with an error code and a range of settings for the property which could besatisfied. The meanings of the error codes which might be returned are described in Table 2-4.

Likewise, if no implementation of the IEventChannel interface exists that can support all of therequested administrative property settings, the UnsupportedAdmin exception is raised. This exceptioncontains as data a sequence of data structures, each of which identifies the name of an administrativeproperty in the input list whose requested setting could not be satisfied, along with an error code and a rangeof settings for the property which could be satisfied. The meanings of the error codes which might bereturned are described in Table 2-4.

If neither of these exceptions is raised, the CreateChannel operation will return a reference to a newNotification Service style event channel. In addition, the operation assigns to this new event channel anumeric identifier which is unique among all event channels created by the target object. This numericidentifier is returned as an output parameter.

10.3.2.4.24.2 GetAll Channels

The GetAllChannels operation returns a sequence of all of the unique numeric identifiers corresponding toNotification Service event channels which have been created by the target object.



10.3.2.4.24.3 GetEventChannel

The GetEventChannel operation accepts as input a numeric value which is supposed to be the uniqueidentifier of a Notification Service event channel that has been created by the target object. If this inputvalue does not correspond to such a unique identifier, the ChannelNotFound exception is raised.Otherwise, the operation returns the object reference of the Notification Service event channel correspondingto the input identifier.

10.3.2.5 3.5 The IMSTypedNotifyChannelAdmin ModuleThe IMSTypedNotifyChannelAdmin module defines the interfaces necessary to create, configure, andadminister instances of a Notification Service typed event channel. The Notification Service typed eventchannel is essentially a hybrid of the typed event channel defined by the OMG Event Service, and theNotification Service event channel described in the previous section. The Notification Service typed eventchannel supports typed event service clients, exactly as defined in the OMG Event Service, but provides theadvantages of QoS administration of the channel, admin, and proxy interfaces, and also enables filtering tobe performed on typed events. Through inheritance of analogous interfaces defined in theIMSTypedEventChannelAdmin module of the OMG Event Service, a Notification Service typedevent channel supports backward compatibility with an Event Service typed event channel. In addition, theIMSTypedNotifyChannelAdmin module defines new versions of the ITypedEventChannel,admin, and proxy interfaces that support connections from clients who will communication via typedevents, but also desire the ability to configure their connections to the channel to support various QoSproperties, and the ability to define filters based on the type and contents of typed events. The conceptsinvolved with filter of typed events are described in section 2.7. The interfaces and modules which comprisethe IMSTypedNotifyChannelAdmin module are specified below.

10.3.2.5.1The ITypedProxyPushConsumer Interface

The ITypedProxyPushConsumer interface supports connections to the channel by suppliers who willpush OMG Event Service style typed events to the channel. Note that such suppliers are identical to OMGEvent Service push-style suppliers of typed events. The ITypedProxyPushConsumer interface definedhere, however, supports event filtering and configuration of various QoS properties. Thus, this interfaceenables OMG Event Service style typed event suppliers to take advantage of these new features offered bythe Notification Service.

Through inheritance of the IProxyConsumer interface defined in the IMSNotifyChannelAdminmodule, the ITypedProxyPushConsumer interface supports administration of various QoS properties,administration of a list of associated filter objects, and a readonly attribute containing the object reference ofthe ISupplierAdmin 1 instance which created a given ITypedProxyPushConsumer instance. Inaddition, this inheritance implies that a ITypedProxyPushConsumer instance supports an operationwhich will return the list of event types which consumers connected to the same channel are interested inreceiving, and an operation which can return information about the instance’s ability to accept a per-eventQoS request.

The ITypedProxyPushConsumer interface inherits the INotifyPublish interface defined in theIMSNotifyComm module, enabling its associated supplier to inform it whenever the list of event typeswhich the supplier plans to supply changes. The ITypedProxyPushConsumer interface also inheritsfrom the ITypedPushConsumer interface defined within the IMSTypedEventComm module of theOMG Event Service. This interface supports the event type specific operation(s) which the supplierconnected to a ITypedProxyPushConsumer instance will invoke to send events to the channel in theform of typed events. And, since the ITypedPushConsumer interface inherits from theIPushConsumer interface defined in the IMSEventComm module, an instance supporting theITypedProxyPushConsumer interface supports the standard push operation with which it can besupplied untyped events, and the operation required to disconnect the ITypedProxyPushConsumer fromits associated supplier. Finally, the ITypedProxyPushConsumer interface defines the operation which



can be invoked by a push supplier to establish the connection over which the push supplier will send eventsto the channel.

10.3.2.5.1.1ConnectTypedPushSupplier

The ConnectTypedPushSupplier operation accepts as an input parameter the reference to an objectsupporting the IPushSupplier interface defined within the IMSEventComm module of the OMGEvent Service. This reference is that of a supplier which plans to push typed events to the channel withwhich the target object is associated. This operation is thus invoked in order to establish a connectionbetween a push-style supplier of typed events, and the notification channel. Once established, the suppliercan proceed to send events to the channel by invoking the event type specific operation(s) supported by thetarget ITypedProxyPushConsumer instance. If the target object of this operation is already connectedto a push supplier object, the AlreadyConnected exception will be raised.

Note that since there is no difference between the interfaces of suppliers of untyped and typed events, itwould have sufficed to have the ITypedProxyPushConsumer interface to inherit from theIProxyPushConsumer interface defined in the IMSNotifyChannelAdmin module, and to not definea separate “connect” method for push-style suppliers of typed events. It was felt, however, that explicitlydefining this operation makes the usage model of the ITypedProxyPushConsumer interface moreintuitive.

10.3.2.5.2The ITypedProxyPullSupplier Interface

The ITypedProxyPullSupplier interface supports connections to the channel by consumers who willpull OMG Event Service style typed events from the channel. Note that such consumers are identical toOMG Event Service pull-style consumers of typed events. The ITypedProxyPullSupplier interfacedefined here, however, supports event filtering and configuration of various QoS properties. Thus, thisinterface enables OMG Event Service style typed event consumers to take advantage of these new featuresoffered by the Notification Service.

Through inheritance of the IProxySupplier interface, the ITypedProxyPullSupplier interfacesupports administration of various QoS properties, administration of a list of associated filter objects,mapping filters for event priority and lifetime, and a readonly attribute containing the object reference of theIConsumerAdmin 1 instance which created a given ITypedProxyPullSupplier instance. In addition,this inheritance implies that a ITypedProxyPullSupplier instance supports an operation which willreturn the list of event types which the proxy supplier will potentially by supplying, and an operationwhich can return information about the instance’s ability to accept a per-event QoS request.

The ITypedProxyPullSupplier interface inherits the INotifySubscribe interface defined in theIMSNotifyComm module, enabling it to be notified whenever its associated consumer changes the listof event types it is interested in receiving. This notification occurs via the callback mechanism described insection 2.3.

The ITypedProxyPullSupplier interface also inherits from the ITypedPullSupplier interfacedefined within the IMSTypedEventComm module of the OMG Event Service. This interface supportsthe event type specific operation(s) which the consumer connected to a ITypedProxyPullSupplierinstance will invoke to receive events from the channel in the form of typed events. And, since theITypedPullSupplier interface inherits from the IPullSupplier interface defined intheIMSEventComm module, an instance supporting the ITypedProxyPullSupplier interfacesupports the standard Pull and TryPull operations with which it can supply untyped events, and theoperation required to disconnect the ITypedProxyPullSupplier from its associated consumer. Finally,the ITypedProxyPullSupplier interface defines the operation which can be invoked by a pull consumerto establish the connection over which the pull consumer will receive events from the channel.

10.3.2.5.2.1ConnectTypedPullConsumer



The ConnectTypedPullConsumer operation accepts as an input parameter the reference to an objectsupporting the IPullConsumer interface defined within the IMSEventComm module of the OMGEvent Service. This reference is that of a consumer which plans to pull typed events from the channel withwhich the target object is associated. This operation is thus invoked in order to establish a connectionbetween a pull-style consumer of typed events, and the notification channel. Once established, the consumercan proceed to receive events from the channel by invoking the event type specific operation(s) supported bythe target ITypedProxyPullSupplier instance. If the target object of this operation is already connectedto a pull consumer object, the AlreadyConnected exception will be raised.

Note that since there is no difference between the interfaces of consumers of untyped and typed events, itwould have sufficed to have the ITypedProxyPullSupplier interface to inherit from theIProxyPullSupplier interface defined in the IMSNotifyChannelAdmin module, and to not define aseparate “connect” method for pull-style consumers of typed events. It was felt, however, that explicitlydefining this operation makes the usage model of the ITypedProxyPullSupplier interface moreintuitive.

10.3.2.5.3The ITypedProxyPullConsumer Interface

The ITypedProxyPullConsumer interface supports connections to the channel by suppliers who willmake OMG Event Service style typed events available for pulling to the channel. Note that such suppliersare identical to OMG Event Service pull-style suppliers of typed events. TheITypedProxyPullConsumer interface defined here, however, supports event filtering and configurationof various QoS properties. Thus, this interface enables OMG Event Service style typed event suppliers totake advantage of these new features offered by the Notification Service.

Through inheritance of the IProxyConsumer interface, the IProxyPullConsumer interface supportsadministration of various QoS properties, administration of a list of associated filter objects, and a readonlyattribute containing the object reference of the ISupplierAdmin 1 instance which created a givenITypedProxyPullConsumer instance. In addition, this inheritance implies that aITypedProxyPullConsumer instance supports an operation which will return the list of event typeswhich consumers connected to the same channel are interested in receiving, and an operation which canreturn information about the instance’s ability to accept a per-event QoS request.

The ITypedProxyPullConsumer interface inherits the INotifyPublish interface defined in theIMSNotifyComm module, enabling its associated supplier to inform it whenever the list of event typeswhich the supplier plans to supply changes.

The IProxyPullConsumer interface also inherits from the IPullConsumer interface defined withinthe IMSEventComm module of the OMG Event Service. This interface supports the operation requiredto disconnect the ITypedProxyPullConsumer from its associated supplier. Finally, theITypedProxyPullConsumer interface defines the operation which can be invoked by a typed pullsupplier to establish the connection over which the typed pull supplier will send events to the channel.

10.3.2.5.3.1ConnectTypedPullSupplier

The ConnectTypedPullSupplier operation accepts as an input parameter the reference to an objectsupporting the ITypedPullSupplier interface defined within the IMSTypedEventComm module ofthe OMG Event Service. This reference is that of a supplier which plans to make OMG Event Service styletyped events available for pulling to the channel with which the target object is associated. This operationis thus invoked in order to establish a connection between a pull-style supplier of typed events, and thenotification channel. Once established, the channel can proceed to receive events from the supplier byinvoking the event type specific operation(s) supported by the supplier. If the target object of this operationis already connected to a typed pull supplier object, the AlreadyConnected exception will be raised. Animplementation of the ITypedProxyPullConsumer interface may impose additional requirements onthe interface supported by a typed pull supplier (e.g., it may be designed to invoke some specific pull-style



operation to receive events). If the typed pull supplier being connected does not meet those requirements,this operation raises the TypeError exception.

10.3.2.5.4The ITypedProxyPushSupplier Interface

The ITypedProxyPushSupplier interface supports connections to the channel by consumers who willreceive OMG Event Service style events from the channel. Note that such consumers are identical to OMGEvent Service push-style consumers of typed events. The ITypedProxyPushSupplier interface definedhere, however, supports event filtering and configuration of various QoS properties. Thus, this interfaceenables OMG Event Service style typed event consumers to take advantage of these new features offered bythe Notification Service.

Through inheritance of the IProxySupplier interface, the ITypedProxyPushSupplier interfacesupports administration of various QoS properties, administration of a list of associated filter objects,mapping filters for event priority and lifetime, and a readonly attribute containing the object reference of theIConsumerAdmin 1 instance which created a given ITypedProxyPushSupplier instance. In addition,this inheritance implies that a ITypedProxyPushSupplier instance supports an operation which willreturn the list of event types which the proxy supplier will potentially by supplying, and an operationwhich can return information about the instance’s ability to accept a per-event QoS request.

The ITypedProxyPushSupplier interface inherits the INotifySubscribe interface defined in theIMSNotifyComm module, enabling it to be notified whenever its associated consumer changes the listof event types it is interested in receiving. This notification occurs via the callback mechanism described insection 2.3. The ITypedProxyPushSupplier interface also inherits from the IPushSupplier interfacedefined within the IMSEventComm module of the OMG Event Service. This interface supports theoperation required to disconnect the ITypedProxyPushSupplier from its associated consumer.

Lastly, the ITypedProxyPushSupplier interface defines the operation which can be invoked by a typedpush consumer to establish the connection over which the typed push consumer will receive events fromthe channel. The ITypedProxyPushSupplier interface also defines a pair of operations which cansuspend and resume the connection between a ITypedProxyPushSupplier instance and its associatedITypedPushConsumer. During the time such a connection is suspended, theITypedProxyPushSupplier will accumulate events destined for the consumer but not transmit themuntil the connection is resumed.

10.3.2.5.4.1ConnectTypedPushConsumer

The ConnectTypedPushConsumer operation accepts as an input parameter the reference to an objectsupporting the ITypedPushConsumer interface defined within the IMSTypedEventComm moduleof the OMG Event Service. This reference is that of a consumer which will receive OMG Event Servicestyle typed events from the channel with which the target object is associated. This operation is thusinvoked in order to establish a connection between a push-style consumer of typed events, and thenotification channel. Once established, the ITypedProxyPushSupplier will proceed to send eventsdestined for the consumer to it by invoking its event type specific push-style operation(s). If the targetobject of this operation is already connected to a typed push consumer object, the AlreadyConnectedexception will be raised. An implementation of the ITypedProxyPushSupplier interface may imposeadditional requirements on the interface supported by a typed push consumer (e.g., it may be designed toinvoke some specific operation in order to transmit events). If the typed push consumer being connecteddoes not meet those requirements, this operation raises the TypeError exception.

10.3.2.5.4.2SuspendConnection

The SuspendConnection operation causes the target object supporting the ITypedProxyPushSupplierinterface to stop sending events to the ITypedPushConsumer instance connected to it. This operationtakes no input parameters and returns no values. If the connection has been previously suspended using thisoperation and not resumed by invoking resume_connection (described below), the



ConnectionAlreadyInactive exception defined in the IMSNotifyChannelAdmin module is raised.Otherwise, the ITypedProxyPushSupplier will not forward events to the ITypedPushConsumerconnected to it until ResumeConnection is subsequently invoked. During this time, theITypedProxyPushSupplier will continue to queue events destined for the ITypedPushConsumer,although events that time out prior to resumption of the connection will be discarded. Upon resumption ofthe connection, all queued events will be forwarded to the ITypedPushConsumer.

10.3.2.5.4.3ResumeConnection

The ResumeConnection operation causes the target object supporting the ITypedProxyPushSupplierinterface to resume sending events to the ITypedPushConsumer instance connected to it. This operationtakes no input parameters and returns no values. If the connection has not been previously suspended usingthis operation by invoking SuspendConnection (described above), the ConnectionAlreadyActiveexception defined in the IMSNotifyChannelAdmin module is raised. Otherwise, theITypedProxyPushSupplier will resume forwarding events to the ITypedPushConsumer connectedto it, including those which have been queued during the time the connection was suspended, and have notyet timed out.

10.3.2.5.5The ITypedConsumerAdmin Interface

The ITypedConsumerAdmin interface defines the behavior supported by objects which create andmanage lists of proxy supplier objects within a Notification Service typed event channel. Similar to itsuntyped counterpart, a Notification Service typed event channel can have any number ofITypedConsumerAdmin instances associated with it. Each such instance is responsible for creating andmanaging a list of proxy supplier objects that share a common set of QoS property settings, and a commonset of filter objects. This feature enables clients to conveniently group proxy supplier objects within achannel into groupings that each support a set of consumers with a common set of QoS requirements andevent subscriptions.

Note that the ITypedConsumerAdmin interface inherits from IConsumerAdmin interface defined inthe IMSNotifyChannelAdmin module, and the ITypedConsumerAdmin interface defined in theIMSTypedEventChannelAdmin module. These inheritance relationships have several implications fora Notification Service style ITypedConsumerAdmin instance.

First, inheritance of the IConsumerAdmin interface defined in the IMSNotifyChannelAdminmodule implies that in addition to being capable of creating and managing Notification Service style typedproxy supplier objects, a ITypedConsumerAdmin instance can also create and manage instancessupporting any of the proxy supplier interfaces defined in the IMSNotifyChannelAdmin module. Inaddition, since the IConsumerAdmin interface defined in the IMSNotifyChannelAdmin moduleinherits from the IConsumerAdmin interface defined in the IMSEventChannelAdmin module, aITypedConsumerAdmin can also create and manage OMG Event service style untyped proxy supplierobjects. Likewise, inheritance of the ITypedConsumerAdmin interface defined in theIMSTypedEventChannelAdmin module implies that an instance supporting theIMSTypedNotifyChannelAdmin’s version of ITypedConsumerAdmin can create and manageOMG Event Service style typed proxy supplier objects as well.

Thus, instances supporting the ITypedConsumerAdmin interface defined in theIMSTypedNotifyChannelAdmin module can potentially create and manage instances supporting anyof the proxy supplier interfaces defined in the IMSEventChannelAdmin,IMSNotifyChannelAdmin, IMSTypedEventChannelAdmin, and theIMSTypedNotifyChannelAdmin (due to locally defined factory operations) modules. The implicationof this is that a Notification Service style typed event channel can support OMG Event Service styleuntyped and typed consumers, along with all variations of consumers defined in the Notification Service asclients.



Note also that the inherited IMSNotifyChannelAdmin::IConsumerAdmin interface provides aninstance supporting the IMSTypedNotifyChannelAdmin::ITypedConsumerAdmin interface withthe behaviors necessary to associate unique identifiers with the proxy supplier objects it creates. While theITypedConsumerAdmin interface defined here is capable of creating OMG Event Service style untypedand typed proxy supplier objects, only instances of the proxy supplier interfaces defined in the NotificationService can have associated unique identifiers.

Similarly, the inheritance of the IConsumerAdmin interface defined in theIMSNotifyChannelAdmin module provides an instance supporting the ITypedConsumerAdmininterface defined in the IMSTypedNotifyChannelAdmin module with the behaviors necessary tomaintain associated QoS property settings and filter objects. The relationships between the QoS propertysettings and filter objects to the proxy supplier objects created by a ITypedConsumerAdmin instanceare identical to those described in section 3.4.21. Note again that QoS property settings and filter objectscan only be associated with Notification Service style proxy suppliers, both typed and untyped.

Inheritance of the IConsumerAdmin interface defined in IMSNotifyChannelAdmin also impliesthat ITypedConsumerAdmin also inherits from the INotifySubscribe interface defined inIMSNotifyComm . This inheritance enables optimizing the notification of a group of proxy supplierobjects that have been created by the same ITypedConsumerAdmin instance of changes to shared filterobjects, since this inheritance enables a ITypedConsumerAdmin instance to be registered as thecallback object for notification of subscription changes made upon filter objects. Lastly, inheritance of theIConsumerAdmin interface defined in IMSNotifyChannelAdmin implies that an instance of theITypedConsumerAdmin interface supports readonly attributes that maintain the unique identifier of theinstance supplied to it by its creating channel, the object reference of the creating channel, and the flagwhich indicates whether AND or OR semantics will be used when combining the filter objects associatedwith a ITypedConsumerAdmin with those defined on specific proxy suppliers created by theITypedConsumerAdmin.

Locally, the ITypedConsumerAdmin interface supports the operations which create new NotificationService style typed proxy supplier instances. Note lastly that due to inheritance of the IConsumerAdmininterface defined in the IMSNotifyChannelAdmin module, an instance supporting theITypedConsumerAdmin interface supports a readonly attribute which maintains a unique identifierassigned to the instance by the channel which created it.

10.3.2.5.5.1ObtainTypedNotificationPullSupplier

The ObtainTypedNotificationPullSupplier operation is used to create a new Notification Service style proxysupplier instance which will support a connection to the channel with which the targetITypedConsumerAdmin instance is associated by a pull-style consumer of typed events. The operationaccepts as input a string which identifies the name of the strongly typed interface that the newly createdITypedProxyPullSupplier instance should support. The consumer which connects to the newITypedProxyPullSupplier would use this strongly typed interface to invoke operations to receive typedevents.

If the target ITypedConsumerAdmin instance cannot locate an occurrence of theITypedProxyPullSupplier interface which also supports the requested strongly typed interface, theInterfaceNotSupported exception defined the IMSTypedEventChannelAdmin module is raised. Ifthe number of consumers currently connected to the channel with which the targetITypedConsumerAdmin object is associated exceeds the value of the maxConsumers administrativeproperty, the AdminLimitExceeded exception is raised. Otherwise, the targetITypedConsumerAdmin instance creates a new instance supporting the ITypedProxyPullSupplierinterface defined in the IMSTypedNotifyChannelAdmin module. This interface can subsequently beused for a pull-style consumer of typed events to establish a connection to the Notification Service typedevent channel. Upon creating the new ITypedProxyPullSupplier instance, the target



ITypedConsumerAdmin instance associates with it a unique identifier which it returns as an outputparameter. This unique identifier could subsequently be used as the input parameter to the GetProxySupplieroperation inherited by the target ITypedConsumerAdmin instance in order to obtain the reference to thenewly created ITypedProxyPullSupplier instance. This reference is returned as the result of theObtainTypedNotificationPullSupplier operation.

10.3.2.5.5.2ObtainTypedNotificationPushSupplier

The ObtainTypedNotificationPushSupplier operation is used to create a new Notification Service styleproxy supplier instance which will support a connection to the channel with which the targetITypedConsumerAdmin instance is associated by a push-style consumer of typed events. The operationaccepts as input a string which identifies the name of a strongly typed interface that the newly createdITypedProxyPushSupplier instance should use when invoking operations upon its associatedITypedPushConsumer instance to send it events.

If the target ITypedConsumerAdmin instance cannot locate an implementation of theITypedProxyPullSupplier interface which will use the requested strongly typed interface to send eventsto a ITypedPushConsumer, the NoSuchImplementation exception defined theIMSTypedEventChannelAdmin module is raised. If the number of consumers currently connected tothe channel with which the target ITypedConsumerAdmin object is associated exceeds the value of themaxConsumers administrative property, the AdminLimitExceeded exception is raised. Otherwise,the target ITypedConsumerAdmin instance creates a new instance supporting theITypedProxyPushSupplier interface defined in the IMSTypedNotifyChannelAdmin module.This interface can subsequently be used for a push-style consumer of typed events to establish a connectionto the Notification Service typed event channel. Upon creating the new ITypedProxyPushSupplierinstance, the target ITypedConsumerAdmin instance associates with it a unique identifier which itreturns as an output parameter. This unique identifier could subsequently be used as the input parameter tothe GetProxySupplier operation inherited by the target ITypedConsumerAdmin instance in order toobtain the reference to the newly created ITypedProxyPushSupplier instance. This reference is returnedas the result of the ObtainTypedNotificationPushSupplier operation.

10.3.2.5.6The ITypedSupplierAdmin Interface

The ITypedSupplierAdmin interface defines the behavior supported by objects which create and managelists of proxy consumer objects within a Notification Service typed event channel. Similar to its untypedcounterpart, a Notification Service typed event channel can have any number of ITypedSupplierAdmininstances associated with it. Each such instance is responsible for creating and managing a list of proxyconsumer objects that share a common set of QoS property settings, and a common set of filter objects.This feature enables clients to conveniently group proxy supplier objects within a channel into groupingsthat each support a set of consumers with a common set of QoS requirements and event subscriptions.Note that the ITypedSupplierAdmin interface inherits from ISupplierAdmin interface defined in theIMSNotifyChannelAdmin module, and the ITypedSupplierAdmin interface defined in theIMSTypedEventChannelAdmin module. These inheritance relationships have several implications fora Notification Service style ITypedSupplierAdmin instance.First, inheritance of the ISupplierAdmin interface defined in the IMSNotifyChannelAdmin moduleimplies that in addition to being capable of creating and managing Notification Service style typed proxyconsumer objects, a ITypedSupplierAdmin instance can also create and manage instances supportingany of the proxy consumer interfaces defined in the IMSNotifyChannelAdmin module. In addition,since the ISupplierAdmin interface defined in the IMSNotifyChannelAdmin module inherits fromthe ISupplierAdmin interface defined in the IMSEventChannelAdmin module, aITypedSupplierAdmin can also create and manage OMG Event service style untyped proxy consumerobjects. Likewise, inheritance of the ITypedSupplierAdmin interface defined in theIMSTypedEventChannelAdmin module implies that an instance supporting theIMSTypedNotifyChannelAdmin’s version of ITypedSupplierAdmin can create and manage OMGEvent Service style typed proxy consumer objects as well. Thus, instances supporting the



ITypedSupplierAdmin interface defined in the IMSTypedNotifyChannelAdmin module canpotentially create and manage instances supporting any of the proxy consumer interfaces defined in theIMSEventChannelAdmin, IMSNotifyChannelAdmin, IMSTypedEventChannelAdmin, andthe IMSTypedNotifyChannelAdmin (due to locally defined factory operations) modules. Theimplication of this is that a Notification Service style typed event channel can support OMG Event Servicestyle untyped and typed suppliers, along with all variations of suppliers defined in the Notification Serviceas clients.Note also that the inherited IMSNotifyChannelAdmin::ISupplierAdmin interface provides aninstance supporting the IMSTypedNotifyChannelAdmin::ITypedSupplierAdmin interface withthe behaviors necessary to associate unique identifiers with the proxy consumer objects it creates. While theITypedSupplierAdmin interface defined here is capable of creating OMG Event Service style untypedand typed proxy supplier objects, only instances of the proxy supplier interfaces defined in the NotificationService can have associated unique identifiers.Similarly, the inheritance of the ISupplierAdmin interface defined in the IMSNotifyChannelAdminmodule provides an instance supporting the ITypedSupplierAdmin interface defined in theIMSTypedNotifyChannelAdmin module with the behaviors necessary to maintain associated QoSproperty settings and filter objects. The relationships between the QoS property settings and filter objects tothe proxy consumer objects created by a ITypedSupplierAdmin instance are identical to those describedin section 3.4.22. Note again that QoS property settings and filter objects can only be associated withNotification Service style proxy consumers, both typed and untyped.Inheritance of the ISupplierAdmin interface defined in IMSNotifyChannelAdmin also implies thatITypedSupplierAdmin also inherits from the INotifyPublish interface defined inIMSNotifyComm . This inheritance enables optimizing the notification of a group of proxy consumerobjects that have been created by the same ITypedSupplierAdmin instance of changes to the types ofevents being offered to them by suppliers, since this inheritance enables a ITypedSupplierAdmininstance to be the target of an OfferChange operation. Lastly, inheritance of the ISupplierAdmininterface defined in IMSNotifyChannelAdmin implies that an instance of theITypedSupplierAdmin interface supports readonly attributes that maintain the unique identifier of theinstance supplied to it by its creating channel, the object reference of the creating channel, and the flagwhich indicates whether AND or OR semantics will be used when combining the filter objects associatedwith a ITypedSupplierAdmin with those defined on specific proxy consumers created by theITypedSupplierAdmin. Locally, the ITypedSupplierAdmin interface supports the operations whichcreate new Notification Service style typed proxy consumer instances. Note lastly that due to inheritance ofthe ISupplierAdmin interface defined in the IMSNotifyChannelAdmin module, an instancesupporting the ITypedSupplierAdmin interface supports a readonly attribute which maintains a uniqueidentifier assigned to the instance by the channel which created it.

10.3.2.5.6.1oOtainTypedNotificationPushConsumer

The ObtainTypedNotificationPushConsumer operation is used to create a new Notification Service styleproxy consumer instance which will support a connection to the channel with which the targetITypedSupplierAdmin instance is associated by a push-style supplier of typed events. The operationaccepts as input a string which identifies the name of the strongly typed interface that the newly createdITypedProxyPushConsumer instance should support. The supplier which connects to the newITypedProxyPushConsumer would use this strongly typed interface to invoke operations to send typedevents to the channel. If the target ITypedSupplierAdmin instance cannot locate an occurrence of theITypedProxyPushConsumer interface which also supports the requested strongly typed interface, theInterfaceNotSupported exception defined the IMSTypedEventChannelAdmin module is raised. Ifthe number of suppliers currently connected to the channel with which the target ITypedSupplierAdminobject is associated exceeds the value of the maxSuppliers administrative property, theAdminLimitExceeded exception is raised. Otherwise, the target ITypedSupplierAdmin instancecreates a new instance supporting the ITypedProxyPushConsumer interface defined in theIMSTypedNotifyChannelAdmin module. This interface can subsequently be used for a push-stylesupplier of typed events to establish a connection to the Notification Service typed event channel. Upon



creating the new ITypedProxyPushConsumer instance, the target ITypedSupplierAdmin instanceassociates with it a unique identifier which it returns as an output parameter. This unique identifier couldsubsequently be used as the input parameter to the GetProxyConsumer operation inherited by the targetITypedSupplierAdmin instance in order to obtain the reference to the newly createdITypedProxyPushConsumer instance. This reference is returned as the result of theObtainTypedNotificationPushConsumer operation.

10.3.2.5.6.2ObtainTypedNotificationPullConsumer

The ObtainTypedNotificationPullConsumer operation is used to create a new Notification Service styleproxy consumer instance which will support a connection to the channel with which the targetITypedSupplierAdmin instance is associated by a pull-style supplier of typed events. The operationaccepts as input a string which identifies the name of a strongly typed interface that the newly createdITypedProxyPullConsumer instance should use when invoking operations upon its associatedITypedPullSupplier instance to receive events.If the target ITypedSupplierAdmin instance cannot locate an implementation of theITypedProxyPullConsumer interface which will use the requested strongly typed interface to receiveevents from a ITypedPullSupplier, the NoSuchImplementation exception defined theIMSTypedEventChannelAdmin module is raised.If the number of suppliers currently connected to thechannel with which the target ITypedSupplierAdmin object is associated exceeds the value of themaxSuppliers administrative property, the AdminLimitExceeded exception is raised. Otherwise, thetarget ITypedSupplierAdmin instance creates a new instance supporting theITypedProxyPullConsumer interface defined in the IMSTypedNotifyChannelAdmin module.This interface can subsequently be used for a pull-style supplier of typed events to establish a connection tothe Notification Service typed event channel. Upon creating the new ITypedProxyPullConsumerinstance, the target ITypedSupplierAdmin instance associates with it a unique identifier which it returnsas an output parameter. This unique identifier could subsequently be used as the input parameter to theGetProxyConsumer operation inherited by the target ITypedSupplierAdmin instance in order to obtainthe reference to the newly created ITypedProxyPullConsumer instance. This reference is returned as theresult of the ObtainTypedNotificationPullConsumer operation.

10.3.2.5.7 The ITypedEventChannel InterfaceThe ITypedEventChannel interface defines the behaviors supported by the Notification Service versionof a typed event channel. The previous statement that such a channel is a hybrid between the NotificationService event channel defined in the IMSNotifyChannelAdmin module, and the typed event channeldefined in the OMG Event Service, is evidenced in the fact that the ITypedEventChannel interfacedefined here inherits from the IEventChannel interface of the IMSNotifyChannelAdmin module,and the ITypedEventChannel interface of the IMSTypedEventChannelAdmin module.Inheritance of the ITypedEventChannel of the IMSTypedEventChannel module essentially impliesbackward compatibility between the Notification Service style typed event channel, and the OMG EventService style typed event channel. It means that pure OMG Event Service style typed admin instances,which can create pure OMG Event Service style typed proxy instances, which can support pure OMG EventService style typed event clients, can be associated with the Notification Service style typed event channel.As usual, none of the pure OMG style objects will support QoS property configuration, associated filterobjects, or administration by unique identifiers.Inheritance of the IEventChannel interface defined in the IMSNotifyChannelAdmin module hasseveral implications. First, since the IEventChannel interface defined in theIMSNotifyChannelAdmin module inherits the IEventChannel interface defined in theIMSEventChannelAdmin module, an instance of the ITypedEventChannel can support OMGEvent Service style untyped admin instances, proxy instances, and client instances as well. Again, none ofthese will support associated QoS property settings, filter objects, or unique identifiers.Inheritance of the IQoSAdmin and IAdminPropertiesAdmin interfaces defined in theIMSNotification module by the IEventChannel interface defined in theIMSNotifyChannelAdmin module implies that instances of the ITypedEventChannel interface can



have associated QoS property and administrative property settings. In addition, due to locally definedattributes and behaviors of the inherited IEventChannel interface of the IMSNotifyChannelAdminmodule, instances of the ITypedEventChannel have associated default IConsumerAdmin andISupplierAdmin instances, and can also create and manage both styles of admin instance defined inIMSNotifyChannelAdmin by unique identifier. Lastly, inheritance of the IEventChannel interfacedefined in the IMSNotifyChannelAdmin module implies that a ITypedEventChannel instancesupports a readonly attribute which maintains a reference to the factory that created it.Finally, the ITypedEventChannel interface defines locally the operations required to create newinstances of the ITypedConsumerAdmin and the ITypedSupplierAdmin interfaces defined in theIMSTypedNotifyChannelAdmin module. These instances also have associated unique identifiers,which can be used in conjunction with the “get*” operations inherited from the IEventChannel interfaceof the IMSNotifyChannelAdmin module. These admin instances should be used by typed NotificationService clients to establish connections to the channel.

10.3.2.5.7.1NewForTypedNotificationConsumers

The NewForTypedConsumers operation is invoked to create a new Notification Service styleITypedConsumerAdmin instance. The operation accepts as an input parameter a boolean flag whichindicates whether AND or OR semantics will be used when combining the filter objects associated with thenewly created ITypedConsumerAdmin instance with those associated with a supplier proxy which wascreated by the ITypedConsumerAdmin during the evaluation of each event against a set of filter objects.The new instance is assigned a unique identifier by the target ITypedEventChannel instance that isunique among all IConsumerAdmin and ITypedConsumerAdmin instances currently associated withthe channel. Upon completion, the operation returns the reference to the new ITypedConsumerAdmininstance as the result of the operation, and the unique identifier assigned to the newITypedConsumerAdmin instance as the output parameter.

10.3.2.5.7.2NewForTypedNotificationSuppliers

The NewForTypedSuppliers operation is invoked to create a new Notification Service styleITypedSupplierAdmin instance. The operation accepts as an input parameter a boolean flag whichindicates whether AND or OR semantics will be used when combining the filter objects associated with thenewly created ITypedSupplierAdmin instance with those associated with a consumer proxy which wascreated by the ITypedSupplierAdmin during the evaluation of each event against a set of filter objects.The new instance is assigned a unique identifier by the target ITypedEventChannel instance that isunique among all ISupplierAdmin and ITypedSupplierAdmin instances currently associated with thechannel. Upon completion, the operation returns the reference to the new ITypedSupplierAdmininstance as the result of the operation, and the unique identifier assigned to the newITypedSupplierAdmin instance as the output parameter.

10.3.2.5.8 The ITypedEventChannelFactory InterfaceThe iTypedEventChannelFactory interface defines an operation for creating new Notification Servicestyle typed event channels. This interface also inherits from the iEventChannelFactory interface definedin the IMSNotifyChannelAdmin module. This inheritance implies that an instance supporting theiTypedEventChannelFactory interface also supports an operation which can return the list of uniquenumeric identifiers assigned to all channels that have been created by the such an instance, and anotherwhich, given the unique identifier of a channel that has been created by the target instance, can return theobject reference associated with that channel. Lastly, this inheritance implies that an instance supporting theiTypedEventChannelFactory can serve as the factory and manager of both untyped and typedNotification Service style event channels.

10.3.2.5.8.1 CreateTypedChannelThe CreateTypedChannel operation is invoked to create a new instance of the Notification Service styletyped event channel. This operation accepts two input parameters. The first input parameter is a list of



name-value pairs which specify the initial QoS property settings for the new channel. The second inputparameter is a list of name-value pairs which specify the initial administrative property settings for the newchannel.If no implementation of the ITypedEventChannel interface exists that can support all of the requestedQoS property settings, the UnsupportedQoS exception defined in the IMSNotifyChannelAdminmodule is raised. This exception contains as data a sequence of data structures, each of which identifies thename of a QoS property in the input list whose requested setting could not be satisfied, along with an errorcode and a range of settings for the property which could be satisfied. The meanings of the error codes whichmight be returned are described in Table 2-4.Likewise, if no implementation of the ITypedEventChannel interface exists that can support all of therequested administrative property settings, the UnsupportedAdmin exception defined in theIMSNotifyChannelAdmin module is raised. This exception contains as data a sequence of datastructures, each of which identifies the name of an administrative property in the input list whose requestedsetting could not be satisfied, along with an error code and a range of settings for the property which couldbe satisfied. The meanings of the error codes which might be returned are described in Table 2-4.If neither of these exceptions is raised, the CreateTypedChannel operation will return a reference to a newNotification Service style typed event channel. In addition, the operation assigns to this new typed eventchannel a numeric identifier which is unique among all event channels created by the target object. Thisnumeric identifier is returned as an output parameter.

10.3.3CORBA IDL

#ifndef _EVENTCOMM_IDL_#define _EVENTCOMM_IDL_

module IMSEventComm{

exception Disconnected{};

interface IPushConsumer{

void Push( in any data )raises( Disconnected );

void DisconnectPushConsumer();

}; // IPushConsumer

interface IPushSupplier{

void DisconnectPushSupplier();

}; // IPushSupplier

interface IPullSupplier{

any Pull()raises( Disconnected );

any TryPull( out boolean hasEvent )raises( Disconnected );

void DisconnectPullSupplier();

}; // IPullSupplier



interface IPullConsumer{

void DisconnectPullConsumer();

}; // IPullConsumer

}; // IMSEventComm

#endif // _EVENTCOMM_IDL_

#ifndef _EVENTCHANNELADMIN_IDL_#define _EVENTCHANNELADMIN_IDL_

#include "EventComm.idl"

module IMSEventChannelAdmin{exception AlreadyConnected{};exception TypeError{};

interface IProxyPushConsumer : IMSEventComm::IPushConsumer{

void ConnectPushSupplier( in IMSEventComm::IPushSupplier pushSupplier )raises( AlreadyConnected );

}; // IProxyPushConsumer

interface IProxyPullSupplier : IMSEventComm::IPullSupplier{

void ConnectPullConsumer( in IMSEventComm::IPullConsumer pullConsumer )raises( AlreadyConnected );

}; // IProxyPullSupplier

interface IProxyPullConsumer : IMSEventComm::IPullConsumer{

void ConnectPullSupplier( in IMSEventComm::IPullSupplier pullSupplier )raises( AlreadyConnected,

TypeError );

}; // IProxyPullConsumer

interface IProxyPushSupplier : IMSEventComm::IPushSupplier{

void ConnectPushConsumer( in IMSEventComm::IPushConsumer pushConsumer )raises( AlreadyConnected,

TypeError );

}; // IProxyPushSupplier

interface IConsumerAdmin{

IProxyPushSupplier ObtainPushSupplier();IProxyPullSupplier ObtainPullSupplier();

}; // IConsumerAdmin

interface ISupplierAdmin



{IProxyPushConsumer ObtainPushConsumer();IProxyPullConsumer ObtainPullConsumer();

}; // ISupplierAdmin

interface IEventChannel{

IConsumerAdmin ForConsumers();ISupplierAdmin ForSuppliers();void Destroy();

}; // IEventChannel

}; // IMSEventChannelAdmin

#endif // _EVENTCHANNELADMIN_IDL_

#ifndef _TYPEDEVENTCOMM_IDL_#define _TYPEDEVENTCOMM_IDL_

#include "EventComm.idl"

module IMSTypedEventComm{interface ITypedPushConsumer : IMSEventComm::IPushConsumer{

IObject GetTypedConsumer();

}; // ITypedPushConsumer

interface ITypedPullSupplier : IMSEventComm::IPullSupplier{

IObject GetTypedSupplier();

}; // ITypedPullSupplier

}; // IMSTypedEventComm

#endif // _TYPEDEVENTCOMM_IDL_

#ifndef _TYPEDEVENTCHANNELADMIN_IDL_#define _TYPEDEVENTCHANNELADMIN_IDL_

#include "TypedEventComm.idl"#include "EventChannelAdmin.idl"

module IMSTypedEventChannelAdmin{exception InterfaceNotSupported{};exception NoSuchImplementation{};typedef string Key;

interface ITypedProxyPushConsumer : IMSEventChannelAdmin::IProxyPushConsumer,IMSTypedEventComm::ITypedPushConsumer{};

interface ITypedProxyPullSupplier : IMSEventChannelAdmin::IProxyPullSupplier,IMSTypedEventComm::ITypedPullSupplier{};



interface ITypedSupplierAdmin : IMSEventChannelAdmin::ISupplierAdmin{

TypedProxyPushConsumer ObtainTypedPushConsumer( in Key supportedInterface )raises( InterfaceNotSupported );

IProxyPullConsumer ObtainTypedPullConsumer( in Key usesInterface )raises( NoSuchImplementation );

}; // ITypedSupplierAdmin

interface ITypedConsumerAdmin : IMSEventChannelAdmin::IConsumerAdmin{

ITypedProxyPullSupplier ObtainTypedPullSupplier( in Key supportedInterface )raises( InterfaceNotSupported );

IProxyPushSupplier ObtainTypedPushSupplier( in Key usesInterface )raises( NoSuchImplementation );

}; // ITypedConsumerAdmin

interface ITypedEventChannel{

ITypedConsumerAdmin ForConsumers();ITypedSupplierAdmin ForSuppliers();void Destroy();

}; // ITypedEventChannel

}; // IMSTypedEventChannelAdmin

#endif // _TYPEDEVENTCHANNELADMIN_IDL_

#ifndef _NOTIFICATION_IDL_#define _NOTIFICATION_IDL_

#include "Trading.idl"

module IMSNotification{typedef IMSTrading::PropertySeq OptionalHeaderFields;typedef IMSTrading::PropertySeq FilterableEventBody;typedef IMSTrading::PropertySeq QoSProperties;typedef IMSTrading::PropertySeq AdminProperties;

struct EventType{

string domain_name;string type_name;

};

typedef sequence<EventType> EventTypeSeq;

struct PropertyRange{

IMSTrading::PropertyName name;IMSTrading::PropertyValue low_val;IMSTrading::PropertyValue high_val;



};

typedef sequence<PropertyRange> PropertyRangeSeq;

enum QoSError_code{

UNSUPPORTED_PROPERTY,UNAVAILABLE_PROPERTY,UNSUPPORTED_VALUE,UNAVAILABLE_VALUE,BAD_PROPERTY,BAD_TYPE,BAD_VALUE

};

struct PropertyError{

QoSError_code code;PropertyRange available_range;

};

typedef sequence<PropertyError> PropertyErrorSeq;

exception UnsupportedQoS { PropertyErrorSeq qos_err; };exception UnsupportedAdmin { PropertyErrorSeq admin_err; };

// Define the Structured Event structurestruct FixedEventHeader{

EventType event_type;string event_name;

};

struct EventHeader{

FixedEventHeader fixed_header;OptionalHeaderFields variable_header;

};

struct StructuredEvent{

EventHeader header;FilterableEventBody filterable_data;any remainder_of_body;

};

typedef sequence<StructuredEvent> EventBatch;

// The following constant declarations define the standard// QoS property names and the associated values each property// can take on. The name/value pairs for each standard property// are grouped, beginning with a string constant defined for the// property name, followed by the values the property can take on.

const string EventReliability = "EventReliability";const short BestEffort = 0;const short Persistent = 1;



const string ConnectionReliability = "ConnectionReliability";// Can take on the same values as EventReliability

const string Priority = "Priority";const short LowestPriority = -32767;const short HighestPriority = 32767;const short DefaultPriority = 0;

const string StartTime = "StartTime";// StartTime takes a value of type TimeBase::UtcT when placed// in an event header. StartTime can also be set to either// TRUE or FALSE at the Proxy level, indicating whether or not the// Proxy supports the setting of per-message start times.

const string StopTime = "StopTime";// StopTime takes a value of type TimeBase::UtcT when placed// in an event header. StopTime can also be set to either// TRUE or FALSE at the Proxy level, indicating whether or not the// Proxy supports the setting of per-message stop times.

const string Timeout = "Timeout";// Timeout take on a value of type TimeBase::TimeT

const string OrderPolicy = "OrderPolicy";const short AnyOrder = 0;const short FifoOrder = 1;const short PriorityOrder = 2;const short DeadlineOrder = 3;

const string DiscardPolicy = "DiscardPolicy";// DiscardPolicy takes on the same values as OrderPolicy plusconst short LifoOrder = 4;

const string MaximumBatchSize = "MaximumBatchSize";// MaximumBatchSize takes on a value of type long

const string PacingInterval = "PacingInterval";// PacingInterval takes on a value of type TimeBase::TimeT

interface IQoSAdmin{

QoSProperties GetQos();

void SetQos( in IQoSProperties qos )raises( UnsupportedQoS );

void ValidateQos( in IQoSProperties requiredQos,out PropertyRangeSeq available_qos )

raises( UnsupportedQoS );

}; // QoSAdmin

// Admin properties are defined in similar manner as QoS// properties. The only difference is that these properties// are related to channel administration policies, as opposed// to message quality of service

const string MaxQueueLength = "MaxQueueLength";



// MaxQueuelength takes on a value of type long

const string MaxConsumers = "MaxConsumers";// MaxConsumers takes on a value of type long

const string MaxSuppliers = "MaxSuppliers";// MaxSuppliers take on a value of type long

interface IAdminPropertiesAdmin{

IAdminProperties GetAdmin();

void SetAdmin( in IAdminProperties admin )raises( UnsupportedAdmin );

}; // IAdminPropertiesAdmin

}; //IMSNotification

#endif // _NOTIFICATION_IDL_

#ifndef _NOTIFYCOMM_IDL_#define _NOTIFYCOMM_IDL_

module IMSNotifyComm{exception InvalidEventType { IMSNotification::EventType type; };

interface INotifyPublish{

void OfferChange( in IMSNotification::EventTypeSeq added,in IMSNotification::EventTypeSeq removed )

raises( InvalidEventType );

}; // INotifyPublish

interface INotifySubscribe{

void SubscriptionChange( in IMSNotification::EventTypeSeq added,in IMSNotification::EventTypeSeq removed )

raises( InvalidEventType );

}; // INotifySubscribe

interface ITxnPushConsumer : INotifyPublish,IMSEventComm::IPushConsumer,IMSTransactions::ITransactionalObject

{}; // ITxnPushConsumer

interface ITxnPullSupplier : INotifySubscribe,IMSEventComm::IPullSupplier,IMSTransactions::ITransactionalObject

{}; // ITxnPullSupplier

interface IStructuredPushConsumer : INotifyPublish{



void PushStructuredEvent( in IMSNotification::StructuredEvent notification )raises( IMSEventComm::Disconnected );

void DisconnectStructuredPushConsumer();

}; // IStructuredPushConsumer

interface ITxnStructuredPushConsumer : IStructuredPushConsumer,IMSTransactions::ITransactionalObject

{}; // ITxnStructuredPushConsumer

interface IStructuredPullConsumer : INotifyPublish{

void DisconnectStructuredPullConsumer();

}; // IStructuredPullConsumer

interface IStructuredPullSupplier : INotifySubscribe{

IMSNotification::StructuredEvent PullStructuredEvent()raises( IMSEventComm::Disconnected );

IMSNotification::StructuredEvent TryPullStructuredEvent( out boolean hasEvent )raises( IMSEventComm::Disconnected );

void DisconnectStructuredPullSupplier();

}; // IStructuredPullSupplier

interface ITxnStructuredPullSupplier : IStructuredPullSupplier,IMSTransactions::ITransactionalObject

{}; // ITxnStructuredPullSupplier

interface IStructuredPushSupplier : INotifySubscribe{

void DisconnectStructuredPushSupplier();

}; // IStructuredPushSupplier

interface ISequencePushConsumer : INotifyPublish{

void PushStructuredEvents( in IMSNotification:EventBatch notifications )raises( IMSEventComm::Disconnected );

void DisconnectSequencePushConsumer();

}; // ISequencePushConsumer

interface ITxnSequencePushConsumer : ISequencePushConsumer,IMSTransactions::ITransactionalObject

{}; // ITxnSequencePushConsumer

interface ISequencePullConsumer : INotifyPublish{

void DisconnectSequencePullConsumer();



}; // ISequencePullConsumer

interface ISequencePullSupplier : INotifySubscribe{

IMSNotification::EventBatch PullStructuredEvents( in long maxNumber )raises( IMSEventComm::Disconnected );

IMSNotification::StructuredEvent TryPullStructuredEvents(in long maxNumber,out

boolean haEvent )raises( IMSEventComm::Disconnected );

void DisconnectSequencePullSupplier();

}; // ISequencePullSupplier

interface ITxnSequencePullSupplier : ISequencePullSupplier,IMSTransactions::ITransactionalObject

{}; // ITxnSequencePullSupplier

interface ISequencePushSupplier : INotifySubscribe{

void DisconnectSequencePushSupplier();

}; // ISequencePushSupplier

}; // IMSNotifyComm

#endif // _NOTIFYCOMM_IDL_

#ifndef _NOTIFYCHANNELADMIN_IDL_#define _NOTIFYCHANNELADMIN_IDL_

module IMSNotifyChannelAdmin{exception ConnectionAlreadyActive{};exception ConnectionAlreadyInactive{};

// Forward declarationsinterface ConsumerAdmin;interface SupplierAdmin;interface EventChannel;interface EventChannelFactory;

interface IProxyConsumer : IMSNotification::IQoSAdmin,IMSNotifyFilter::IFilterAdmin

{readonly attribute ISupplierAdmin myAdmin;

IMSNotification::EventTypeSeq ObtainSubscriptionTypes();

void ValidateEventQos(in IMSNotification::QoSProperties requiredQos,out IMSNotification::PropertyRangeSeq availableQos )

raises( IMSNotification::UnsupportedQoS );

}; // IProxyConsumer



interface IProxySupplier : IMSNotification::IQoSAdmin,IMSNotifyFilter::IFilterAdmin

{readonly attribute IConsumerAdmin myAdmin;

attribute IMSNotifyFilter::MappingFilter priorityFilter;attribute IMSNotifyFilter::MappingFilter lifetimeFilter;

IMSNotification::EventypeSeq ObtainOfferedTypes();

void ValidateEventQos(in IMSNotification::QoSProperties requiredQos,out IMSNotification::PropertyRangeSeq availableQos )

raises( IMSNotification::UnsupportedQoS );

}; // IProxySupplier

interface IProxyPushConsumer :IProxyConsumer,IMSNotifyComm::INotifyPublish,IMSEventComm::IPushConsumer

{void ConnectAnyPushSupplier( in IMSEventComm::IPushSupplier pushSupplier )

raises( IMSEventChannelAdmin::AlreadyConnected );

}; // IProxyPushConsumer

interface ITxnProxyPushConsumer : IProxyPushConsumer,IMSTransactions::ITransactionalObject

{}; // ITxnProxyPushConsumer

interface IStructuredProxyPushConsumer : IProxyConsumer,IMSNotifyComm::IStructuredPushConsumer

{void ConnectStructuredPushSupplier( in IMSNotifyComm::IStructuredPushSupplier pushSupplier )


}; // IStructuredProxyPushConsumer

interface ITxnStructuredProxyPushConsumer : IStructuredProxyPushConsumer,IMSTransactions::ITransactionalObject

{}; // ITxnStructuredProxyPushConsumer

interface ISequenceProxyPushConsumer : IProxyConsumer,IMSNotifyComm::ISequencePushConsumer

{void ConnectSequencePushSupplier( in IMSNotifyComm::ISequencePushSupplier pushSupplier )


}; // ISequenceProxyPushConsumer

interface ITxnSequenceProxyPushConsumer : ISequenceProxyPushConsumer,IMSTransactions::ITransactionalObject

{}; // ITxnSequenceProxyPushConsumer

interface IProxyPullSupplier : IProxySupplier,



IMSNotifyComm::INotifySubscribe,IMSEventComm::IPullSupplier

{void ConnectAnyPullConsumer( in IMSEventComm::IPullConsumer pullConsumer )


}; // IProxyPullSupplier

interface ITxnProxyPullSupplier : IProxyPullSupplier,IMSTransactions::ITransactionalObject

{}; // ITxnProxyPullSupplier

interface IStructuredProxyPullSupplier : IProxySupplier,IMSNotifyComm::IStructuredPullSupplier

{void ConnectStructuredPullConsumer ( in IMSNotifyComm::IStructuredPullConsumer pullConsumer )


}; // IStructuredProxyPullSupplier

interface ITxnStructuredProxyPullSupplier : IStructuredProxyPullSupplier,IMSTransactions::ITransactionalObject

{}; // ITxnStructuredProxyPullSupplier

interface ISequenceProxyPullSupplier : IProxySupplier,IMSNotifyComm::ISequencePullSupplier

{void ConnectSequencePullConsumer( in IMSNotifyComm::ISequencePullConsumer pullConsumer )


}; // ISequenceProxyPullSupplier

interface ITxnSequenceProxyPullSupplier : ISequenceProxyPullSupplier,IMSTransactions::ITransactionalObject

{}; // ITxnSequenceProxyPullSupplier

interface IProxyPullConsumer : IProxyConsumer,IMSNotifyComm::INotifyPublish,IMSEventComm::IPullConsumer

{void ConnectAnyPullSupplier( in IMSEventComm::IPullSupplier pullSupplier )

raises( IMSEventChannelAdmin::AlreadyConnected,IMSEventChannelAdmin::TypeError );

}; // IProxyPullConsumer

interface IStructuredProxyPullConsumer : IProxyConsumer,IMSNotifyComm::IStructuredPullConsumer

{void ConnectStructuredPullSupplier( in IMSNotifyComm::IStructuredPullSupplier pullSupplier )


}; // IStructuredProxyPullConsumer



interface ISequenceProxyPullConsumer : IProxyConsumer,IMSNotifyComm::ISequencePullConsumer

{void ConnectSequencePullSupplier ( in IMSNotifyComm::ISequencePullSupplier pullSupplier )


}; // ISequenceProxyPullConsumer

interface IProxyPushSupplier : IProxySupplier,IMSNotifyComm::INotifySubscribe,IMSEventComm::IPushSupplier

{void ConnectAnyPushConsumer( in IMSEventComm::IPushConsumer pushConsumer )


void SuspendConnection()raises( ConnectionAlreadyInactive );

void ResumeConnection()raises( ConnectionAlreadyActive );

}; // IProxyPushSupplier

interface IStructuredProxyPushSupplier : IProxySupplier,IMSNotifyComm::IStructuredPushSupplier

{void ConnectStructuredPushConsumer ( in IMSNotifyComm::IStructuredPushConsumer pushConsumer )


void suspendConnection()raises( ConnectionAlreadyInactive );

void resumeConnection()raises( ConnectionAlreadyActive );

}; // IStructuredProxyPushSupplier

interface ISequenceProxyPushSupplier : IProxySupplier,IMSNotifyComm::ISequencePushSupplier

{void ConnectSequencePushConsumer( in IMSNotifyComm::ISequencePushConsumer pushConsumer )


void suspendConnection()raises( ConnectionAlreadyInactive );

void resumeConnection()raises( ConnectionAlreadyActive );

}; // ISequenceProxyPushSupplier

typedef long ProxyID;typedef sequence<ProxyID> ProxyIDSeq;



enum ClientType{

ANY_EVENT,STRUCTURED_EVENT,SEQUENCE_EVENT

}; // ClientType

enum InterFilterGroupOperator { AND_OP, OR_OP };

typedef long AdminID;typedef sequence<AdminID> AdminIDSeq;

exception AdminNotFound{};exception ProxyNotFound{};

struct AdminLimit{

IMSTrading::PropertyName name;IMSTrading::PropertyValue value;

};

exception AdminLimitExceeded { AdminLimit admin_property_err; };

interface IConsumerAdmin : IMSNotification::IQoSAdmin,IMSNotifyComm:INotifySubscribe,IMSNotifyFilter::IFilterAdmin,IMSEventChannelAdmin::IConsumerAdmin

{readonly attribute AdminID myID;readonly attribute EventChannel myChannel;

readonly attribute InterFilterGroupOperator myOperator;

attribute IMSNotifyFilter::MappingFilter priorityFilter;attribute IMSNotifyFilter::MappingFilter lifetimeFilter;

readonly attribute ProxyIDSeq pullSuppliers;readonly attribute ProxyIDSeq pushSuppliers;

ProxySupplier GetProxySupplier( in ProxyID proxyId )raises( ProxyNotFound );

ProxySupplier ObtainNotificationPullSupplier( in ClientType ctype,out ProxyID proxyId )

raises( AdminLimitExceeded );

ProxySupplier ObtainNotificationPushSupplier( in ClientType ctype,out ProxyID proxyId )


ProxySupplier ObtainTxnNotificationPullSupplier(in ClientType ctype,out ProxyID proxyId )


}; // IConsumerAdmin

interface ISupplierAdmin : IMSNotification::IQoSAdmin,



IMSNotifyComm::INotifyPublish,IMSNotifyFilter::IFilterAdmin,IMSEventChannelAdmin::ISupplierAdmin

{readonly attribute AdminID myID;readonly attribute EventChannel myChannel;

readonly attribute InterFilterGroupOperator myOperator;

readonly attribute ProxyIDSeq pullConsumers;readonly attribute ProxyIDSeq pushConsumers;

ProxyConsumer GetProxyConsumer( in ProxyID proxyId )raises( ProxyNotFound );

ProxyConsumer ObtainNotificationPullConsumer(in ClientType ctype,out ProxyID proxyId )


ProxyConsumer ObtainNotificationPushConsumer(in ClientType ctype,out ProxyID proxyId )


ProxyConsumer ObtainTxnNotificationPushConsumer(in ClientType ctype,out ProxyID proxyId )


}; // ISupplierAdmin

interface IEventChannel : IMSNotification::IQoSAdmin,IMSNotification::IAdminPropertiesAdmin,IMSEventChannelAdmin::IEventChannel

{readonly attribute EventChannelFactory myFactory;

readonly attribute ConsumerAdmin defaultConsumerAdmin;readonly attribute SupplierAdmin defaultSupplierAdmin;

ConsumerAdmin NewForConsumers(in InterFilterGroupOperator op,out AdminID id );

SupplierAdmin NewForSuppliers(in InterFilterGroupOperator op,out AdminID id );

ConsumerAdmin GetConsumerAdmin( in AdminID id )raises ( AdminNotFound );

SupplierAdmin GetSupplierAdmin( in AdminID id )raises ( AdminNotFound );

AdminIDSeq GetAllConsumerAdmins();AdminIDSeq GetAllSupplierAdmins();

}; // IEventChannel

typedef long ChannelID;typedef sequence<ChannelID> ChannelIDSeq;



exception ChannelNotFound{};

interface IEventChannelFactory{

IEventChannel CreateChannel(in IMSNotification::QoSProperties intitialQos,in IMSNotification::AdminProperties initialAdmin,out ChannelID id )

raises( IMSNotification::UnusupportedQoS,IMSNotification::UnsupportedAdmin );

ChannelIDSeq GetAllChannels();

EventChannel GetEventChannel ( in ChannelID id )raises( ChannelNotFound );

}; // IEventChannelFactory

}; // IMSNotifyChannelAdmin

#endif // _NOTIFYCHANNELADMIN_IDL_

#ifndef _NOTIFYFILTER_IDL_#define _NOTIFYFILTER_IDL_

module IMSNotifyFilter{typedef long ConstraintID;

struct ConstraintExp{

IMSNotification::EventTypeSeq eventTypes;string constraintExpr;

};

typedef sequence<ConstraintID> ConstraintIDSeq;typedef sequence<ConstraintExp> ConstraintExpSeq;

struct ConstraintInfo{

ConstraintExp constraintExpression;ConstraintID constraintId;

};

typedef sequence<ConstraintInfo> ConstraintInfoSeq;

struct MappingConstraintPair{

ConstraintExp constraintExpression;any resultToSet;

};

typedef sequence<MappingConstraintPair> MappingConstraintPairSeq;

struct MappingConstraintInfo{

ConstraintExp constraintExpression;ConstraintID constraintId;any value;



};

typedef sequence<MappingConstraintInfo> MappingConstraintInfoSeq;

typedef long CallbackID;typedef sequence<CallbackID> CallbackIDSeq;

exception UnsupportedFilterableData {};exception InvalidGrammar {};exception InvalidConstraint { ConstraintExp constr; };exception DuplicateConstraintID { ConstraintID id; };

exception ConstraintNotFound { ConstraintID id; );exception CallbackNotFound {};

exception InvalidValue { ConstraintExp constr; any value; };

interface IFilter{

readonly attribute string constraintGrammar;

ConstraintInfoSeq AddConstraints( in ConstraintExpSeq constraintList )raises( InvalidConstraint );

void ModifyConstraints( in ConstraintIDSeq delList,in ConstraintInfoSeq modifyList )

raises( InvalidConstraint, ConstraintNotFound );

ConstraintInfoSeq GetConstraints( in ConstraintIDSeq idList )raises( ConstraintNotFound );

ConstraintInfoSeq GetAllConstraints();

void RemoveAllConstraints();

void Destroy();

boolean Match( in any filterableData )raises( UnsupportedFilterableData );

boolean MatchStructured ( in IMSNotification::StructuredEvent filterableData )raises( UnsupportedFilterableData );

boolean MatchTyped( in IMSTrading::PropertySeq filterableData )raises( UnsupportedFilterableData );

CallbackID AttachCallback( in IMSNotifyComm::INotifySubscribe callback );

void DetachCallback( in CallbackID callback )raises( CallbackNotFound );

CallbackIDSeq GetCallbacks();}; // IFilter

interface IMappingFilter{

readonly attribute string constraintGrammar;



readonly attribute CORBA::TypeCode valueType;

readonly attribute any defaultValue;

MappingConstraintInfoSeq AddMappingConstraints( in MappingConstraintPairSeq pairList )raises( InvalidConstraint, InvalidValue );

void ModifyMappingConstraints(in ConstraintIDSeq delList,in MappingConstraintInfoSeq modifyList )

raises( InvalidConstraint,InvalidValue,ConstraintNotFound );

MappingConstraintInfoSeq GetAllMappingConstraints();

void RemoveAllMappingConstraints();

void Destroy();

boolean Match( in any filterableData,out any resultToSet )

raises( UnsupportedFilterableData );

boolean MatchStructured( in IMSNotification::StructuredEvent filterableData,out any resultToSet )


boolean MatchTyped(in IMSTrading::PropertySeq filterableData,out any resultToSet )


}; // IMappingFilter

interface IFilterFactory{

Filter CreateFilter( in string constraintGrammar )raises( InvalidGrammar );

IMappingFilter CreateMappingFilter(in string constraintGrammar,in any defaultValue )

raises( InvalidGrammar );

}; // IFilterFactory

typedef long FilterID;typedef sequence<FilterID> FilterIDSeq;

exception FilterNotFound {};

interface IFilterAdmin{

FilterID AddFilter ( in Filter newFilter );

void RemoveFilter ( in FilterID filter )raises( FilterNotFound );

Filter GetFilter( in FilterID filter )raises( FilterNotFound );



FilterIDSeq GetAllFilters();

void RemoveAllFilters();

}; // IFilterAdmin

}; // IMSNotifyFilter

#endif // _NOTIFYFILTER_IDL_

#ifndef _TYPEDNOTIFYCHANNELADMIN_IDL_#define _TYPEDNOTIFYCHANNELADMIN_IDL_

module IMSTypedNotifyChannelAdmin{typedef string Key;

interface ITypedProxyPushConsumer : IMSNotifyChannelAdmin::IProxyConsumer,IMSNotifyComm::INotifyPublish,IMSTypedEventComm::ITypedPushConsumer

{void ConnectTypedPushSupplier( in IMSEventComm::IPushSupplier pushSupplier )


}; // ITypedProxyPushConsumer

interface ITypedProxyPullSupplier : IMSNotifyChannelAdmin::IProxySupplier,IMSNotifyComm::INotifySubscribe,IMSTypedEventComm::ITypedPullSupplier

{void ConnectTypedPullConsumer( in IMSEventComm::PullConsumer pullConsumer )


}; // ITypedProxyPullSupplier

interface ITypedProxyPullConsumer : IMSNotifyChannelAdmin::IProxyConsumer,IMSNotifyComm::INotifyPublish,IMSEventComm::IPullConsumer

{void ConnectTypedPullSupplier( in IMSTypedEventComm::ITypedPullSupplier pullSupplier )


}; // ITypedProxyPullConsumer

interface ITypedProxyPushSupplier : IMSNotifyChannelAdmin::IProxySupplier,IMSNotifyComm::INotifySubscribe,IMSEventComm::IPushSupplier

{void ConnectTypedPushConsumer( in IMSTypedEventComm::ITypedPushConsumer pushConsumer )


void SuspendConnection()raises( IMSNotifyChannelAdmin::ConnectionAlreadyInactive );



void ResumeConnection()raises( IMSNotifyChannelAdmin::ConnectionAlreadyActive );

}; // ITypedProxyPushSupplier

interface ITypedConsumerAdmin : IMSNotifyChannelAdmin::IConsumerAdmin,IMSTypedEventChannelAdmin::ITypedConsumerAdmin

{ITypedProxyPullSupplier ObtainTypedNotificationPullSupplier( in Key supportedInterface,

out IMSNotifyChannelAdmin::ProxyID proxyId )raises( IMSTypedEventChannelAdmin::InterfaceNotSupported,

IMSNotifyChannelAdmin::AdminLimitExceeded );

ITypedProxyPushSupplier ObtainTypedNotificationPushSupplier( in Key usesInterface,

out IMSNotifyChannelAdmin::ProxyID proxyId )raises( IMSTypedEventChannelAdmin::NoSuchImplementation,


}; // ITypedConsumerAdmin

interface ITypedSupplierAdmin: IMSNotifyChannelAdmin::ISupplierAdmin,IMSTypedEventChannelAdmin::ITypedSupplierAdmin

{ITypedProxyPushConsumer ObtainTypedNotificationPushConsumer( in Key supportedInterface,

out IMSNotifyChannelAdmin::ProxyID proxyId )raises( IMSTypedEventChannelAdmin::InterfaceNotSupported,


ITypedProxyPullConsumer ObtainTypedNotificationPullConsumer( in Key usesInterface,

out IMSNotifyChannelAdmin::ProxyID proxyId )raises( IMSTypedEventChannelAdmin::NoSuchImplementation,


}; // ITypedSupplierAdmin

interface ITypedEventChannel : IMSNotifyChannelAdmin::IEventChannel,IMSTypedEventChannelAdmin::ITypedEventChannel

{

ITypedConsumerAdmin NewForTypedNotificationConsumers(in IMSNotifyChannelAdmin::InterFilterGroupOperator op,outIMSNotifyChannelAdmin::AdminID id );

ITypedSupplierAdmin NewForTypedNotificationSuppliers(in IMSNotifyChannelAdmin::InterFilterGroupOperator op,outIMSNotifyChannelAdmin::AdminID id );

}; // ITypedEventChannel

interface ITypedEventChannelFactory : IMSNotifyChannelAdmin::IEventChannelFactory{

ITypedEventChannel CreateTypedChannel( in IMSNotification::QoSProperties initialQoS,in IMSNotification::AdminProperties initialAdmin,out IMSNotifyChannelAdmin::ChannelID id )



raises( IMSNotification::UnsupportedQoS,IMSNotification::UnsupportedAdmin );

}; // ITypedEventChannelFactory

}; // IMSTypedNotifyChannelAdmin

#endif // _TYPEDNOTIFYCHANNELADMIN_IDL_

10.3.4DCOM IDL

10.4Relationship Service Interfaces

10.4.1Origin of InterfacesThe following information is based entirely on the Object Management Group’s specification of theCommon Object Services Relationship Service. The end of this section contains the actual IMS contentmodel objects, which are derived versions of Nodes, Relationships, and Graph Traversals. The onlychanges that have been made, other than the addition of IMS context information, is the harmonization ofinterface signatures with the rest of the IMS and the possible removal of some low level CORBAdependencies.

10.4.2The Base Relationship ModelThe base level of the Relationship Service defines interfaces that support relationships between two or moreCORBA objects. Objects that participate in a relationship are called related objects. Relationships that sharethe same semantics form relationship types. A relationship is an instance of a relationship type and has anidentity. Each related object is connected with the relationship via a role. Roles are objects whichcharacterize a related object‘s participation in a relationship type. Role types are used for expressing therole´s characteristics by an IDL interface. Cardinality represents the number of relationship instancesconnected to a role. Degree represents the number of roles in a relationship. All characteristics are expressedby corresponding IDL interfaces. Relationship and role types are built by subtyping the Relationship andRole interfaces.

Figure 9-6 gives a graphical representation of a simple relationship type. It illustrates that documentsreference books. Documents are in the ReferencesRole and books are in the ReferencedByRole. Documents,reference, the roles and books are all types; there are interfaces (written in OMG IDL) for all five.

INSERT FIGURE 9-6

Figure 9-7, on the other hand, gives a graphical representation of an instance of a relationship type. Itillustrates that “my document”, an instance of Document, references “War and Peace”, an instance of Book.1

INSERT FIGURE 9-7“

10.4.2.1 Relationship Attributes and OperationsRelationships may have attributes and operations. For example, the reference relationship of Figure 9-6 hasan attribute indicating the date the reference from the document to the book was established.

10.4.2.1.1Rationale



If relationships are not allowed to define attributes and operations, they will have to be assigned to one ofthe related objects. This approach is prone to misunderstandings and inconsistencies. The approach to definean artificial related object, which then carries the attributes, is equally unsatisfactory.The date attribute of the example of Figure 9-7 is clearly an attribute of the relationship, not one of relatedobjects. It cannot be an attribute of “my document” since “my document” can reference many books ondifferent dates. Similarly, it cannot be an attribute of “War and Peace” since “War and Peace” can bereferenced by many books on different dates.

10.4.2.2 Higher Degree RelationshipsThe Reference relationship in Figure 9-6 is a binary relationship; that is, it is defined by two roles. TheRelationship Service can also support relationships with more than two roles. The fact that three or morerelated objects may be part of a relationship can be expressed directly by means of the same concept as inthe binary case. The degree represents the number of roles in a relationship. The Relationship Servicesupports higher degree relationships, that is relationships with degree greater than two. Figure 9-8 shows aternary “check out” relationship between books, libraries and persons. The semantics of this relationship isthat a person borrows a book from a library. The relationship also defines an attribute that indicates the datewhen the book is due to be returned by the person to the library.

INSERT FIGURE 9-8 TERNARY …...

10.4.2.2.1Rationale

The Relationship Service represents higher degree relationships directly. It clearly defines the number ofexpected related objects as well as other integrity constraints. It is more readable, more understandable andeasier to enforce consistency constraints for related objects with a direct representation than with alternativerepresentations that simulate higher degree relationships using a set of binary relationships. Whensimulating higher degree relationships, the relationship information is spread over multiple object andrelationship type definitions, as are the corresponding integrity constraints.

Figure 9-9 shows an alternative representation of the ternary relationship from Figure 9-8 using binaryrelationships. Note that the first representation is not equivalent to that of Figure 9-8 since cardinalities andother integrity constraints cannot be expressed correctly in this alternative representation.

INSERT FIGURE 9-9 UNSATIFACTORY….

Figure 9-10 illustrates a second alternative representation of the ternary relationship of Figure 9-8. It usesan additional (artificial) related object type. This representation is equivalent to Figure 9-8 if Check-out isconstrained to participate in exactly one instance of each of the three binary relationship types. However,this alternative needs three relationship types and one additional related object type (Check-out) instead ofonly one relationship type, and therefore is much more complex and harder to capture when compared to therepresentation using one relationship type with degree 3.

INSERT FIGURE 9-10 ANOTHER UNSATIS..

Since the Relationship Service supports higher order relationships directly, the user of the service need notresort to the unsatisfactory representations using binary relationships of Figure 9-9 and Figure 9-10.

10.4.2.3 OperationsThe base level of the Relationship Service provides operations to:• Create role and relationship objects• Navigate relationships• Destroy roles and relationships• Iterate over the relationships in which a role participates



10.4.2.3.1Creation

Roles are constructed independently using a role factory. Roles represent an existing related object that ispassed as a parameter to the RoleFactory::create operation. When creating a new role object, thetype of the related object can be checked by the factory. The minimum and maximum cardinality, e.g. theminimal and the maximal number of relationship instances to which the new role object may be connected,are indicated by attributes on the factory.

Figure 9-11 illustrates a newly created role.

Figure 9-11 Creating a role for an object

A new relationship is created by passing a sequence of named roles to a factory for the relationship. Theexpected degree and role types for the new relationship are indicated by attributes on the factory. During thecreation of the new relationship, the role types and the maximum cardinality can be checked. Duplicate rolenames are not allowed since the names are used to distinguish the roles in the scope of the relationship.When creating a relationship, the factory creates “links” between the roles and the relationship using thelink operation on the role. Figure 9-12 illustrates a fully established binary relationship.1

Figure 9-12 A ful ly es tabl i shed binary re lat ionship

10.4.2.3.2Navigation

Figure 9-12 illustrates the navigational functionality of a relationship. In particular,

• a relationship defines an attribute that indicates a read-only attribute that indicates the named roles of therelationship,

• a role defines a read-only attribute that indicates the related object that the role represents,• A role supports the get_other_role operation, that given a relationship object and a role name,returns the other role object,• A role supports the get_other_related_object operation, that given a relationship object and arole name, returns the related object that the named role represents in the relationship and• A role supports the get_relationships operation which returns the relationships in which the roleparticipates.

10.4.2.3.3Destruction

For both roles and relationship objects, the Relationship Services introduces a destroy operation. Thedestroy operation for relationship objects also destroys the links between the relationship and all of the roleobjects.

10.4.2.4 Consistency ConstraintsFor each role two cardinalities are defined: minimum and maximum.

• The minimum cardinality indicates the minimum number of relationship instances in which a role mustparticipate.

• The maximum cardinality indicates the maximum number of relationship instances in which a role canparticipate. Maximum cardinality constraint can be checked when relationships are created. Note that therelationship mechanism cannot, by itself, enforce the minimum cardinality constraint. However, a role canbe asked explicitly if it meets its minimum cardinality constraint using thecheck_minimum_cardinality operation.Type integrity is preserved by CORBA mechanisms because related objects, roles and relationships areinstances of CORBA object types. Type constraints can be checked when roles and relationships are created.



10.4.2.5 Implementation StrategiesFigure 9-12 illustrates the navigational functionality of a fully established binary relationship. There are avariety of implementation strategies possible. The get_other_role and theget_other_related_object operations can be:

• Implemented by caching object references to other roles and related objects, or• Computed when needed using the relationship object.

The appropriate implementation strategy typically depends on distribution boundaries. If the roles andrelationship objects are clustered, then only storing the values at the relationship object optimizes space. If,on the other hand, the roles and the related objects are clustered, caching object references to other roles andrelated objects at the roles allows the relationship to be efficiently navigated without involving a remoterelationship object.

Role implementations that cache object references to other roles and related objects need not worry aboutupdating the cache. Once the related objects and relationships are established, they cannot be changed.

10.4.2.6 The IMSObjectIdentity ModuleCORBA: Common Object Request Broker Architecture and Specification does not define a notion of objectidentity for objects. The Relationship Service requires object identity for the objects it defines. As such, theRelationship Service assumes the IMSObjectIdentity module specified in Figure 9-13 . This is defined in aseparate module; other Object Services may find this module to be generally useful.

10.4.2.6.1The IIdentifiableObject Interface

Objects that support the IdentifiableObject interface implement an attribute of type ObjectIdentifier and theis_identical operation. This mechanism provides an efficient and convenient method of supportingobject identity in a heterogeneous CORBA-based environment.

#ifndef _OBJECTIDENTITY_IDL_#define _OBJECTIDENTITY_IDL_

module IMSObjectIdentity{typedef unsigned long ObjectIdentifier;interface IdentifiableObject{

readonly attribute ObjectIdentifier constant_random_id;boolean is_identical (in IdentifiableObject other_object);

};};

#endif // _OBJECTIDENTITY_IDL_Figure 9-13 The IMSObjectIdentity Module

10.4.2.6.1.1constant_random_id

Objects supporting the IdentifiableObject interface define an attribute of type ObjectIdentifier. The value ofthe attribute must not change during the lifetime of the object.A typical client use of this attribute is as a key in a hash table. As such, the more randomly distributed thevalues are, the better.

The value of this attribute is not guaranteed to be unique; that is, another identifiable object can return thesame value. However, if objects return different identifiers, clients can determine that two identifiableobjects are not identical.



To determine if two identifiable objects are identical, the is_identical operation must be used.

10.4.2.6.1.2is_identical

The is_identical operation returns true if the object and the other_object are identical.Otherwise, the operation returns false.

10.4.2.7 The IMSRelationships ModuleThe IMSRelationships module defines the interfaces of the base level RelationshipService. In particular, itdefines

• Relationship and Role interfaces to represent relationships and roles,• RelationshipFactory and RoleFactory interfaces to create relationships and roles• RelationshipIterator interface to enumerate the relationships in which a role participates

The IMSRelationships module is shown in Figure 9-14.#ifndef _RELATIONSHIPS_IDL_#define _RELATIONSHIPS_IDL_

#include <ObjectIdentity.idl>module IMSRelationships{interface RoleFactory;interface RelationshipFactory;interface Relationship;interface Role;interface RelationshipIterator;

typedef Object RelatedObject;typedef sequence<Role> Roles;

typedef string RoleName;typedef sequence<RoleName> RoleNames;

struct NamedRole {RoleName name; Role aRole;};typedef sequence<NamedRole> NamedRoles;

struct RelationshipHandle{

Relationship the_relationship;IMSObjectIdentity::ObjectIdentifier constant_random_id;

};typedef sequence<RelationshipHandle> RelationshipHandles;

interface RelationshipFactory{

struct NamedRoleType{

RoleName name;::CORBA::InterfaceDef named_role_type;

};typedef sequence<NamedRoleType> NamedRoleTypes;

readonly attribute ::CORBA::InterfaceDef relationship_type;readonly attribute unsigned short degree;readonly attribute NamedRoleTypes named_role_types;



exception RoleTypeError {NamedRoles culprits;};exception MaxCardinalityExceeded {NamedRoles culprits;};exception DegreeError {unsigned short required_degree;};exception DuplicateRoleName {NamedRoles culprits;};exception UnknownRoleName {NamedRoles culprits;};

Relationship create (in NamedRoles named_roles)raises (RoleTypeError,

MaxCardinalityExceeded,DegreeError,DuplicateRoleName,UnknownRoleName);

};

interface Relationship : IMSObjectIdentity::IdentifiableObject{

exception CannotUnlink {Roles offending_roles;};readonly attribute NamedRoles named_roles;void destroy () raises(CannotUnlink);

};

interface Role{

exception UnknownRoleName {};exception UnknownRelationship {};exception RelationshipTypeError {};exception CannotDestroyRelationship {RelationshipHandles offenders;};exception ParticipatingInRelationship {RelationshipHandles the_relationships;};

readonly attribute RelatedObject related_object;RelatedObject get_other_related_object (in RelationshipHandle rel,

in RoleName target_name)raises (UnknownRoleName,

UnknownRelationship);

Role get_other_role ( in RelationshipHandle rel,in RoleName target_name)

raises (UnknownRoleName, UnknownRelationship);

void get_relationships (in unsigned long how_many,out RelationshipHandles rels,out RelationshipIterator iterator);

void destroy_relationships()raises(CannotDestroyRelationship);

void destroy() raises(ParticipatingInRelationship);

boolean check_minimum_cardinality ();

void link ( in RelationshipHandle rel,in NamedRoles named_roles)

raises( RelationshipFactory::MaxCardinalityExceeded,RelationshipTypeError);

void unlink (in RelationshipHandle rel)raises (UnknownRelationship);

};



interface RoleFactory{

exception NilRelatedObject {};exception RelatedObjectTypeError {};

readonly attribute ::CORBA::InterfaceDef role_type;readonly attribute unsigned long max_cardinality;readonly attribute unsigned long min_cardinality;readonly attribute sequence<::CORBA::InterfaceDef> related_object_types;

Role create_role (in RelatedObject related_object)raises (NilRelatedObject, RelatedObjectTypeError);

};

interface RelationshipIterator{

boolean next_one (out RelationshipHandle rel);

boolean next_n (in unsigned long how_many,out RelationshipHandles rels);

void destroy ();};

};

#endif // _RELATIONSHIPS_IDL_

Figure 9-14 The IMSRelationships Module

Example of Containment Relationships The example of Figure 9-15 is referred to throughout the followingsections to describe roles and relationships. The figure represents two binary, one-to-many containmentrelationships between a document and a figure and a logo.

Figure 9-15 Two binary one- to-many conta inment re lat ionships .

10.4.2.7.1The IRelationshipFactory Interface

The RelationshipFactory interface defines an operation for creating an instance of a relationship among a setof related objects. The factory also defines two attributes that specify the degree and role types of therelationships it creates.

10.4.2.7.1.1Creating a Relationship

The create operation creates a new instance of a relationship. The factory is passed a sequence of namedroles that represent the related objects in the newly created relationship. The factory, in turn, informs theroles about the new relationship using the link operation described in section .

Roles implement maximum cardinality constraints. A role may refuse to participate in a new relationshipbecause it would violate a cardinality constraint. In such a case, the MaxCardinalityExceededexception is raised and the offending roles are returned in the exception.

The number of roles passed to the create operation must be the same as the value of the degreeattribute. If not, the DegreeError exception is raised. Role names are used to associate each actual roleobject with one of the formal roles expected by the relationship to be created.



The set of role names passed to the create operation must be the same as the set of role names in thefactory’s named_role_types attribute. If not, the UnknowRoleName exception is raised, and theunrecognized names are returned in the exception. The sequence order of the named_roles parameter andthe sequence order of the named_role_types need not correspond.

The type of each role passed to the create operation must be of the same type as the type indicated forthe corresponding role name in the named_role_types attribute. If not, the RoleTypeError israised and the offending roles are returned in the exception.

The names of the roles passed to the create operation must be unique within the scope of thisrelationship type. If not, the DuplicateRoleName exception is raised.

Example of Figure 9-15 The document and the figure were related, that is relationship B was created, bypassing roles A and C to the create operation of the relationship factory. Similarly, the document andthe logo were related by passing roles C and E to the relationship factory for relationship D.

10.4.2.7.1.2Determining the Created Relationship’s Type

The relationship created by a factory may be a subtype of the Relationship interface. Therrelationship_type attribute indicates the actual types of the relationships created by the factory.

10.4.2.7.1.3Determining the Degree of a Relationship Type

The degree attribute indicates the number of roles for the relationships created by the factory.Example of Figure 9-15 The relationship factory for containment has a degree attribute whose value is 2because containment is a binary relationship.

10.4.2.7.1.4Determining Names and Types of the Roles of a Relationship Type

The named_role_types attribute indicates the required names and types of roles for the relationshipscreated by the factory. NamedRoleTypes are defined as structures where the role type is given by theIMS::InterfaceDef for the role objects.

Example of Figure 9-15 The relationship factory for containment has an attribute whose value is a sequenceof two CORBA::InterfaceDefs: one for ContainsRole and one for ContainedInRole.

10.4.2.7.2The IRelationship Interface

The Relationship interface defines an attribute whose value is the named roles of the relationship and anoperation to destroy the relationship.

10.4.2.7.2.1Determining the Roles of a Relationship and Their Names

The named_roles attribute returns the roles of the relationship. The roles have the names that wereindicated in the create operation defined by theRelationshipFactory interface.

Example of Figure 9-15 Relationship B has an attribute whose value is a sequence <“A”,InterfaceDef forContainedInRole; “C”, InterfaceDef for ContainsRole>. Similarly, relationship D has an attribute whosevalue is a sequence <“E”, InterfaceDef for ContainedInRole; “C”, InterfaceDef for ContainsRole>.

10.4.2.7.2.2Destroying a Relationship

The destroy operation destroys the relationship between the objects. The roles are unlinked by therelationship implementation before it is destroyed. If roles cannot be unlinked, the CannotUnlinkexception is raised and the roles that could not be unlinked are returned in the exception.

Example of Figure 9-15 If destroy is requested of relationship B, the unlink operation is requested ofboth roles A and C and the relationship B is destroyed.



10.4.2.7.3The IRole Interface

The Role interface defines operations to:

• navigate the relationship from one role to another,• enumerate the relationships in which the role participates,• destroy all relationships in which the role participates,• link a role to a newly created relationship and• unlink a role in the destruction process of a relationship and• destroy the role itself,

readonly attribute NamedRoles named_roles;void destroy () raises(CannotUnlink);

10.4.2.7.3.1Determining the Related Object That a Role Represents

The related_object attribute indicates the related object that the role represents. The related objectthat the role represents is specified as a parameter to the create operation defined by the RoleFactoryinterface.

10.4.2.7.3.2Getting Another Related Object

The get_other_related_object operation navigates the relationship rel to the related objectrepresented by the role named target_name. If the role does not know about a role namedtarget_name, the UnknownRoleName exception is raised. If the role does not know about therelationship rel, the UnknownRelationship exception is raised.

Example of Figure 9-15 Assuming role A is named “A”, requestingget_other_related_object(B,”A”) of role C returns the figure. On the other hand, requestingget_other_related_object(D,”E”) of role C returns the logo.

10.4.2.7.3.3Getting Another Role

The get_other_role operation navigates the relationship rel to the role named target_name.The role is returned. If the role does not know about a role named target_name for the relationshiprel, the UnknownRoleName exception is raised. If the role does not know about the relationship rel,the UnknownRelationship exception is raised.

Example of Figure 9-15 Assuming role A is named “A”, requesting get_other_role(B,”A”) ofrole C returns role A. On the other hand, requesting get_other_role(D,”E”) of role C returns roleE.

10.4.2.7.3.4Getting All Relationships in Which a Role Participates

The get_relationships operation returns the relationships in which the role participates.The size of the list is determined by the how_many argument. If there are more relationships thanspecified by the how_many argument, an iterator is created and returned with the additional relationships.If there are no more relationships, a nil object reference is returned for the iterator. (The RelationshipIteratorinterface is a standard iterator described in the next section. )

Example of Figure 9-15 Requesting get_relationships on role C would return the relationships Band D.

10.4.2.7.3.5Destroying All Relationships in Which a Role Participates

The destroy_relationships operation destroys all relationships in which the role participates.The destroy_relationships operation is semantically equivalent to requesting destroy of eachrelationship in which the role participates. The operation is not required to be implemented in that fashion.



If the destroy_relationships operation cannot destroy one of the relationships, then theCannotDestroyRelationship exception is raised and the relationships that could not be destroyedare returned in the exception.

Example of Figure 9-15 Requesting destroy_relationships of role A causes relationship B to bedestroyed. On the other hand, requesting destroy_relationships of role C causes relationships Band D to be destroyed.

10.4.2.7.3.6Destroying a Role

The destroy operation destroys the role. The role must not be participating in any relationships. If it is,the ParticipatingInRelationship exception is raised and the relationships in which the role participates arereturned in the exception.

Example of Figure 9-15 Requesting destroy_role of role A destroys relationship B and role A.

10.4.2.7.3.7Checking Minimum Cardinality of a Role

The check_minimum_cardinality operation returns true if a role satisfies its minimum cardinalityconstraints. Otherwise, the operation returns false.

Example of Figure 9-15 Requesting check_minimum_cardinality of role A would return truesince it is participating in relationship B.

10.4.2.7.3.8Linking a Role in a Newly Created Relationship

Note – The link operation is not intended for general purpose clients that create, navigate and destroyrelationships. Instead, it is an operation intended for implementations of the relationship factory createoperation.

The link operation informs the role that a new relationship is being created. The role is passed arelationship and a set of named roles that represent related objects in the relationship.

A role can have a maximum cardinality, that is it may limit the number of relationships in which itparticipates. If the link request would cause the maximum to be exceeded, theMaxCardinalityExceeded exception is raised. If the type of the relationship does not agree with therelationship type that the role expects, the RelationshipTypeError exception is raised.

Example of Figure 9-15 When creating relationship B, the factory for B requested the link (B, A,C)operation on roles A and C. This allows roles A and C to support the navigation and administrationoperations for relationship B.

10.4.2.7.3.9Removing a Role from a Relationship

Note – The unlink operation is not intended for general purpose clients that create, navigate and destroyrelationships. Instead, it is an operation intended for implementations of the relationship destroyoperation.The unlink operation causes the role to delete its record of the relationship. If the relationship passed asan argument is unknown to the role, the UnknownRelationship exception is raised.

Example of Figure 9-15 The implementation of the destroy operation on relationship B requestsunlink(B) of roles A and C. This causes roles A and C to forget their participation in relationship B.

10.4.2.7.4The IRoleFactory Interface

The RoleFactory interface defines attributes describing the roles that it creates and a single operation tocreate a role.



10.4.2.7.4.1Creating a Role

The create_role operation creates a role for the related object passed as a parameter. A role mustrepresent a related object. If a nil object reference is passed to the factory for the related object, theNilRelatedObject exception is raised. Role factories can restrict the type of objects the roles theycreate will represent. If the interface of the related object does not conform, theRelatedObjectTypeError exception is raised.

Example of Figure 9-15 Clients that created roles A, C and E used the create operation of factories thatsupport the RoleFactory interface.

10.4.2.7.4.2Determining the Created Role’s Type

The role created by a factory may be a subtype of the Role interface. The role_type attribute indicatesthe actual types of the roles created by the factory.

10.4.2.7.4.3Determining the Maximum Cardinality of a Role

The max_cardinality attribute indicates the maximum number of relationships in which a role(created by the factory) participates.

Example of Figure 9-15 The factory for role A returns 1, since a ContainedIn role can be in no more thanone relationship. Attempts to add role A to more than one relationship result inMaxCardinalityExceeded exceptions. (See the create operation of the RelationshipFactoryinterface and the link operation of the Role interface.)

10.4.2.7.4.4Determining the Minimum Cardinality of a Role

The min_cardinality attribute indicates the minimum number of relationships in which a role(created by the factory) participates.

Note, that unlike maximum cardinality, minimum cardinality cannot be enforced since roles will be belowtheir minimum during relationship construction. Roles do support thecheck_minimum_cardinality operation to report if they are below their minimum.

Example of Figure 9-15 The factory for role A returns 1, since a ContainedIn role should be in onerelationship.

10.4.2.7.4.5Determining the Related Object Types for a Role

The factory creates roles that represent related objects in relationships. The related objects must support atleast one of the interfaces indicated by the related_object_type attribute.

Example of Figure 9-15 The factory for role C returns the CORBA::InterfaceDef for a document.

10.4.2.7.5The IRelationshipIterator Interface

The RelationshipIterator interface is returned by the get_relationships operation defined by theRole interface. It allows clients to iterate through any additional relationships in which the role participates.

10.4.2.7.5.1next_one

The next_one operation returns the next relationship; if no more relationships exist, it returns false.

10.4.2.7.5.2next_n

The next_n operation returns at most the requested number of relationships; if no more relationshipsexist, it returns false.

10.4.2.7.5.3destroy



The destroy operation destroys the iterator.

10.4.39.4 Graphs of Related ObjectsWhen objects are related using the Relationship Service, graphs of related objects are formed. This sectionfocuses on how the Relationship Service supports graphs of related objects. We first describe the grapharchitecture supported by the service, describe support for traversing the graph and implementing compoundoperations and then specify the IMSGraphs module in detail.

Graphs are important for distributed, object-oriented applications. A few examples of graphs are:

10.4.3.1 Distributed DesktopsFolders and objects are connected together. Folders contain some objects and reference others. Folders maycontain or reference other folders. The objects are distributed; they span multiple machines. The distributeddesktop is a distributed graph.

10.4.3.2 Composed ApplicationsApplications are built out of existing objects that are connected together. An example of such a composedapplication is a shared white board. The composed application is a graph.

10.4.3.3 User Interface HierarchiesPresentation objects visualize semantic objects for users. Presentations contain other presentation objects.For example, a window might contain a button. The user interface hierarchy is a graph.

10.4.3.4 Compound DocumentsA compound document architecture allows graphics, animation, sound, video, etc. to be connected togetherto give the user the impression of a single document. The compound document is a graph.

10.4.3.5 9.4.1 Graph ArchitectureA graph is a set of nodes and a set of edges, involving those nodes. Nodes are related objects that supportthe Node interface and edges are represented by the relationships that relate nodes.Figure 9-3 on page 9-9 illustrates an example of a graph.Figure 9-16 An example graph of related objects .

The folder, book, document, figure, library, person and logo are nodes in the graph. The edges of the graphare represented by the relationships:

• containment: the folder and document,• containment: the document and the figure• containment: the document and the logo• reference: the figure and the logo• reference: the document and the book,• check_out: the book, the library and the person

The graph architecture supports multiple kinds of relationships. For example, in Figure 9-3, there arecontainment, reference and check_out relationships. The small circles depict roles for a referencerelationship, the solid circles depict roles for a containment relationship and the shaded circles represent theroles of the check_out relationship.

A node can participate in more than one kind of relationship and thus have more than one role. In theexample the document has three kinds of roles:



• The ContainsRole• The ContainedInRole• The ReferencesRole

10.4.3.5.1Nodes

Nodes are identifiable objects that support the Node interface. Nodes collect roles of a related object and therelated object itself. A node enables standard traversals of graphs of related objects because it supports thefollowing:• A readonly attribute defining all of its roles• An operation allowing roles of a particular type to be returned• Operations to add and remove rolesThe Node interface can be inherited by related objects or an object implementing the Node interface can beinstantiated and interposed in front of related objects. Interposition is particularly useful in these cases:• When connecting immutable objects, which are objects that are not aware of the Relationship Service• In order to traverse graphs of related objects without activating the related objects As such, the Nodeinterface defines an attribute whose value is the related object it represents.

10.4.3.6 Traversing Graphs of Related ObjectsThe Relationship Service defines a traversal object that, given a starting node, produces a sequence ofdirected edges of the graph. A directed edge corresponds to a relationship. In particular, it consists of:

• An instance of a relationship,• A starting node and a starting named role of the edge to indicate direction and• A sequence containing the remaining nodes and named roles. For binary relationships, there is a singleremaining node and role. For n-ary relationships, there are n-1 remaining nodes and roles.

The traversal object works like an iterator, where directed edges are the items being returned. The traversalobject, the nodes and the roles cooperate in traversing the graph. Through the operations of the Nodeinterface, the node reveals its roles to the traversal object. Through the operations of the IMSGraphs::Roleinterface, a role reveals its directed edges to other nodes. (The IMSGraphs::Role interface defines anoperation allowing a role to reveal directed edges.) In traversing a graph, the traversal object must detect andrepresent cycles, and determine the relevant nodes and edges.

10.4.3.6.1Detecting and Representing Cycles

In order to terminate, a traversal must be able to detect a cycle in the graph. In the example of Figure 9-3,the document, the figure, and the logo form a cycle. To detect cycles in the graph, the traversal objectdepends on the fact that nodes are identifiable objects, that is they support the IdentifiableObject interfacedefined in section 9.3.6.

To represent cycles in the graph, the traversal object defines a scope of identifiers for the nodes andrelationships in the graph. That is, a given traversal assigns identifiers to the nodes and relationships thatare guaranteed to be unique within the scope of the traversal.

10.4.3.6.2Determining the Relevant Nodes and Edges

A traversal begins at the starting node, emits directed edges and may continue to other related nodes. Thetraversal object is programmable in the criteria it uses for determining the edges to emit and the nodes tovisit. The traversal object depends on a “call-back” object supporting the TraversalCriteria interface.Given a node, the traversal criteria computes a sequence of directed edges to include in the traversal. For eachedge, the traversal criteria can indicate whether the traversal should continue to an adjacent node. Based onthe results of the traversal criteria, the traversal object emits edges and visits other nodes. The processcontinues until there are no more edges to emit and no more nodes to visit.



Three standard traversal modes are defined to allow clients flexibility in controlling the search order: depthfirst, breadth first, and best first. In order to understand the differences between the modes, consider that thetraversal maintains an ordered list of the edges which have been produced by visiting nodes. This listinitially contains the edges which result from visiting the root node. In each iteration the first edge isremoved from the list to be returned and its destination nodes are visited. Depending upon the traversalmode, these edges are: inserted in the beginning of the list (depth first), appended to the end of the list(breadth first), or inserted into the list which is sorted by the edge’s weight (best first).

10.4.3.7 Compound OperationsTraversal objects are especially important in implementing compound operations on graphs of relatedobjects. By compound operations, we mean operations that apply to some subset of the nodes and edges inthe graph. Examples of compound operations include operations, such as copy, move, remove, externalize,print, and so forth.

Note – The Relationship Service defines a framework for compound operations but does not definespecific compound operations. The Life Cycle and the Externalization Service specifications definecompound operations that depend on the Relationship Service.

A compound operation may be implemented either in one or two passes. A compound operationimplemented in one pass traverses the graph itself and applies the operation as it proceeds.A compound operation implemented in two passes uses the traversal object defined by the RelationshipService to determine the relevant nodes and detect and represent cycles. The second pass simply applies theoperation to the results of the first pass. A compound operation implemented in two passes provides aTraversalCriteria object for the traversal service.

10.4.3.8 An Example Traversal CriteriaConsider a traversal of a graph with a traversal criteria object that uses propagation values defined by therelationships to determine whether to emit an edge and whether to proceed to another node. The traversalcriteria is given a node by the traversal. The traversal criteria then requests propagation values from each ofthe node’s roles. Figure 9-17 illustrates a traversal of a graph using a traversal criteria for a compoundcopy operation. Using the propagation_for operation defined by CompoundLifeCycle::Roleinterface, the traversal criteria obtains the propagation value for the copy operation from each of the node’sroles.Figure 9-17 A traversal of a graph for compound copy operation.

10.4.3.8.1Propagation

Compound operations may propagate from one node to another depending on the semantics of therelationship between the nodes. The propagation semantics of a relationship depend on the direction therelationship is being traversed. A propagation value is either deep, shallow, inhibit or none.

Deep means that the operation is applied to the node, to the relationship and to the related objects. In theexample of Figure 9-17, the propagation value for the copy operation is deep from the document to thelogo; the copy propagates from the document to the logo across the containment relationship. The traversalcriteria for copy that encounters a deep propagation value would instruct the traversal object to emit the edgeand visit the logo.

Shallow means that the operation is applied to the relationship but not to the related objects. In theexample of Figure 9-17, the propagation value for the copy operation from the logo to the document isshallow. The traversal criteria for copy that encounters a shallow propagation value would instruct thetraversal object to emit the edge but the document is not visited.



None means that the operation has no effect on the relationship and no effect on the related objects. Atraversal criteria that encounters a none propagation value would not return any edges and related nodes arenot visited.

Figure 9-18 summarizes how deep, shallow and node propagation values affect nodes, roles andrelationships.

Figure 9-18 How deep, shal low and none propagation values affect nodes , roles andr e l a t i o n s h i p s .Inhibit means that the operation should not propagate to the node via any of the node’s roles. Inhibit isparticularly meaningful for the remove operation to provide so-called “existence-ensuring relationships”. Formore discussion of propagation values, see [1.].

10.4.3.9 9.4.5 The IMSGraphs ModuleThe IMSGraphs module defines the support for graphs of related objects. It defines the following interfaces:

• TraversalFactory interface for creating traversal objects• Traversal interface for enumerating directed edges of a graph,• TraversalCriteria “call-back” interface to allow programmability of the traversal object• Node interface for collecting the roles of a related object• NodeFactory interface for creating nodes• Role interface to support traversals

The IMSGraphs module is shown in Figure 9-14#ifndef _GRAPHS_IDL_#define _GRAPHS_IDL_

#include <Relationships.idl>#include <ObjectIdentity.idl>

module IMSGraphs{interface TraversalFactory;interface Traversal;interface TraversalCriteria;interface Node;interface NodeFactory;interface Role;interface EdgeIterator;

struct NodeHandle{

Node the_node;

::IMSObjectIdentity::ObjectIdentifier constant_random_id;};

typedef sequence<NodeHandle> NodeHandles;

struct NamedRole{

Role the_role;::IMSRelationships::RoleName the_name;

};

typedef sequence<NamedRole> NamedRoles;



struct EndPoint{

NodeHandle the_node;NamedRole the_role;

};typedef sequence<EndPoint> EndPoints;

struct Edge{

EndPoint from;::IMSRelationships::RelationshipHandle the_relationship;EndPoints relatives;

};typedef sequence<Edge> Edges;

enum PropagationValue {deep, shallow, none, inhibit};

enum Mode {depthFirst, breadthFirst, bestFirst};

interface TraversalFactory{

Traversal create_traversal_on ( in NodeHandle root_node,in TraversalCriteria the_criteria,in Mode how);

};

interface Traversal{

typedef unsigned long TraversalScopedId;

struct ScopedEndPoint{

EndPoint point;TraversalScopedId id;

};typedef sequence<ScopedEndPoint> ScopedEndPoints;

struct ScopedRelationship{

::IMSRelationships::RelationshipHandle scoped_relationship;TraversalScopedId id;

};

struct ScopedEdge{

ScopedEndPoint from;ScopedRelationship the_relationship;ScopedEndPoints relatives;

};typedef sequence<ScopedEdge> ScopedEdges;

boolean next_one (out ScopedEdge the_edge);

boolean next_n (in short how_many,out ScopedEdges the_edges);

void destroy ();



};

interface TraversalCriteria{

struct WeightedEdge{

Edge the_edge;unsigned long weight;sequence<NodeHandle> next_nodes;

};typedef sequence<WeightedEdge> WeightedEdges;

void visit_node(in NodeHandle a_node,in Mode search_mode);

boolean next_one (out WeightedEdge the_edge);

boolean next_n (in short how_many,out WeightedEdges the_edges);

void destroy();};

interface Node: ::IMSObjectIdentity::IdentifiableObject{

typedef sequence<Role> Roles;

exception NoSuchRole {};exception DuplicateRoleType {};

readonly attribute ::IMSRelationships::RelatedObject related_object;readonly attribute Roles roles_of_node;

Roles roles_of_type (in ::CORBA::InterfaceDef role_type);

void add_role (in Role a_role)raises (DuplicateRoleType);

void remove_role (in ::CORBA::InterfaceDef of_type)raises (NoSuchRole);

};

interface IResource: INode{

IMSGroup::IGroup group;IMSSession::ISession session;

};

interface NodeFactory{

Node create_node (in Object related_object);};

interface Role : ::IMSRelationships::Role{

void get_edges ( in long how_many,out Edges the_edges,out EdgeIterator the_rest);



};

interface EdgeIterator{

boolean next_one (out Edge the_edge);

boolean next_n ( in unsigned long how_many,out Edges the_edges);

void destroy ();};

};

#endif // _GRAPHS_IDL_

Figure 9-19 The IMSGraphs Module

10.4.3.9.1The ITraversalFactory InterfaceThe TraversalFactory interface creates traversal objects. The Traversal interface is used byclients that want to traverse graphs of related objects according to some traversal criteria.

10.4.3.9.1.1create_traversal_on

The create_traversal_on operation creates a traversal object starting at the root_node. Thecreated traversal object uses the TraversalCriteria object to determine which directed edges to emit and whichnodes to visit. The mode parameter indicates whether the traversal will proceed in a depth first, breadthfirst or best first fashion.

10.4.3.9.2The ITraversal Interface

Traversal objects iterate through ScopedEdges of the graph according to the traversal criteria and themode established when the traversal was created. The traversal also defines a scope for the nodes and edges itreturns; that is, it assigns identifiers to the nodes and edges it returns. The identifiers are unique within thescope of a given traversal. ScopedEdges are given by the following structure: A ScopedEdgeconsists of a distinguished scoped end point, a scoped relationship and a sequence of scoped end points. Thedistinguished scoped end point indicates the direction of the edge. The scoped end point consists of a node, arole, and an identifier for the node that is unique within the scope of the traversal.

10.4.3.9.2.1next_one

The next_one operation returns the next scoped edge; if no more scoped edges exist, it returns false.

10.4.3.9.2.2next_n

The next_n operation returns at most the requested number of scoped edges.

10.4.3.9.2.3destroy

The destroy operation destroys the traversal.

10.4.3.9.3The ITraversalCriteria Interface

The TraversalCriteria interface is used by the traversal object to determine which edges to emit and whichnodes to visit from a given node. The traversal criteria behaves like an iterator of weighted edges. Weightededges are given by the following structure:

A WeightedEdge consists of an edge, a weight and a sequence of nodes indicating if the traversal shouldcontinue to the nodes. The weight is only meaningful for the best first traversal.

10.4.3.9.3.1next_one



The next_one operation returns the next weighted edge; if no more weighted edges exist, it returns false.

10.4.3.9.3.2next_n

The next_n operation returns at most the requested number of weighted directed edges.

10.4.3.9.3.3destroy

The destroy operation destroys the traversal criteria.

10.4.3.9.3.4visit_node

The visit_node operation establishes the node for which the traversal criteria will iterate and indicatesthe current search mode. As the traversal object traverses the graph, it visits nodes by requesting thevisit_node operation of the traversal criteria, followed by next_one/next_n requests to obtain theoutgoing edges from the node.

For depthFirst and breadthFirst modes, the weight field in the weighted edges is ignored. In the bestFirstmode, the weight value is utilized to order the traversal’s edges list which is sorted by this value inascending order.

If weighted edges from a previous node remain when visit_node is requested, the traversal criteriadiscards the previous edges.

10.4.3.9.4The INode Interface

The Node interface defines operations that are useful in navigating graphs of related objects. In particular, itdefines:

• Areadonly attribute giving all of the node’s roles• An operation allowing roles conforming to a particular type to be returned• Operations to add and remove roles

Roles are distinguished in nodes in the OMG IDL of their interfaces. A node cannot posses two roles whereone role is a subtype of the other. This is precluded by the add_role operation.A node can posses two or more roles that have a common supertype. The set of roles can be obtained bypassing the common supertype to the roles_of_type operation.

10.4.3.9.4.1related_object

The related_object attribute gives the related object that the node represents. This is useful whenrelating immutable objects.

10.4.3.9.4.2roles_of_node

The roles_of_node attribute gives all of the node’s roles.

10.4.3.9.4.3roles_of_type

The roles_of_type operation returns the node’s roles that conform to the role_type parameter. Arole conforms to role_type if it’s interface is the same or is a subtype of role_type.

10.4.3.9.4.4add_role

The add_role operation adds a role to the node. If the node posses a role of the same type, a supertypeor a subtype of a_role, the DuplicateRoleType exception is raised.

10.4.3.9.4.5remove_role

The remove_role operation removes all the roles that conform to the of_type parameter. If no rolesconform to the of_type parameter, the NoSuchRole exception is raised.



10.4.3.9.5The INodeFactory Interface

The NodeFactory interface defines a single operation for creating nodes.

10.4.3.9.5.1create_node

The create_node operation creates a node whose related_object attribute is initialized to therelated_object parameter.

10.4.3.9.6The IRole Interface

The IMSGraphs::Role interface extends the IMSRelationships::Role interface with a single operation toreturn a role’s view of it’s relationships. The role’s view of a relationship is given by the following Edgestructure:

The edge structure is defined by an end point, a relationship and the other end points. The from end point isthe role and its related object.

10.4.3.9.6.1get_edges

The get_edges operation returns the edges in which the role participates. The size of the list isdetermined by the how_many argument. If there are more edges than specified by the how_manyargument, an iterator is created and returned. If there are no more edges, a nil object reference is returned forthe iterator.

10.4.3.9.7The IEdgeIterator Interface

The EdgeIterator interface is returned by the get_edges operation defined by the IMSGraphs::Roleinterface. It allows clients to iterate through any additional relationships in which the role participates.

10.4.3.9.7.1next_one

The next_one operation returns the next edge; if no more edges exist, it returns false.

10.4.3.9.7.2next_n

The next_n operation returns at most the requested number of edges.

10.4.3.9.7.3destroy

The destroy operation destroys the iterator.

10.4.4Specific RelationshipsThe Relationship Service defines two important relationships, containment and reference as part of itsspecification. The example used throughout this specification has been in terms of these two relationships.

10.4.4.1 Containment and ReferenceContainment is a one-to-many relationship. A container can contain many containees; a containee iscontained by one container. Reference, on the other hand, is a many-to-many relationship. An object canreference many objects; an object can be referenced by many objects.Containment and reference are examples of relationships. However, since containment and reference are verycommon relationships, the Relationship Service defines them as standard.Containment is defined by interfaces for a relationship and two roles: the IMSContainment::Relationshipinterface, the IMSContainment::ContainsRole interface, and the IMSContainment::ContainedInRoleinterface. Relationship is a subtype of IMSRelationships::Relationship and ContainedInRole andContainsRole are subtypes of IMSGraphs::Role.Similarly, reference is defined by interfaces for a relationship and two roles: the IMSReference::Relationshipinterface, the IMSReference::ReferencesRole interface, and the IMSReference::ReferencedByRole interface.



Relationship is a subtype of IMSRelationships::Relationship and ReferencesRole and ReferencedByRole aresubtypes of IMSGraphs::Role.

10.4.4.2 The IMSContainment ModuleThe IMSContainment module is shown in Figure 9-14.

#ifndef _CONTAINMENT_IDL_#define _CONTAINMENT_IDL_

#include <Graphs.idl>

module IMSContainment{interface Relationship : ::IMSRelationships::Relationship {};

interface ContainsRole : ::IMSGraphs::Role {};

interface ContainedInRole : ::IMSGraphs::Role {};};

#endif _CONTAINMENT_IDL

Figure 9-20 The IMSContainment ModuleThe IMSContainment module does not define new operations. It introduces new IDL types to representcontainment. Although it does not add any new operations, it refines the semantics of these attributes andoperations:RelationshipFactoryattribute

Value

Relationship_type IMSContainment::RelationshipDegree 2Named_role_types “ContainsRole”, IMSContainment::ContainsRole;

“ContainedInRole”, IMSContainment::ContainedInRole

The IMSRelationships::RelationshipFactory::create operation will raise DegreeError if the numberof roles passed as arguments is not 2. It will raise RoleTypeError if the roles are notIMSContainment::ContainsRole and IMSContainment::ContainedInRole. It will raiseMaxCardinalityExceeded if the IMSContainment::ContainedInRole is already participating in arelationship.RoleFactory attribute forContainsRole

Value

Role_type IMSContainment::ContainsRoleMaximum_cardinality UnboundedMinimum_cardinality 0Related_object_types IMSGraphs::NodeThe IMSRelationships::RoleFactory::create_role operation will raise theRelatedObjectTypeError if the related object passed as a parameter does not support theIMSGraphs::Node interface. The IMSRelationships::RoleFactory::link operation will raiseRelationshipTypeError if the rel parameter does not conform to theIMSContainment::Relationship interface.RoleFactory attribute forContainedInRole

Value

Role_type IMSContainment::ContainedInRoleMaximum_cardinality 1Minimum_cardinality 1



Related_object_types IMSGraphs::Node

The IMSRelationships::RoleFactory::create_role operation will raise theRelatedObjectTypeError if the related object passed as a parameter does not support theIMSGraphs::Node interface. The IMSRelationships::RoleFactory::link operation will raiseRelationshipTypeError if the rel parameter does not conform to theIMSContainment::Relationship interface. The IMSRelationships::RoleFactory::link operation will raiseMaxCardinalityExceeded if it is already participating in a containment relationship.

10.4.4.3 The IMSReference ModuleThe IMSReference module is given in Figure 9-21.

#ifndef _REFERENCE_IDL_#define _REFERENCE_IDL_


module IMSReference{interface Relationship : ::IMSRelationships::Relationship {};

interface ReferencesRole : IMSGraphs::Role {};

interface ReferencedByRole : ::IMSGraphs::Role {};

};

#endif _REFERENCE_IDL_

Figure 9-21 The IMSReference ModuleThe IMSReference module does not define new operations. It introduces new IDL types to representreference. Although it does not add any new operations, it refines the semantics of these attributes andoperations:RelationshipFactoryattribute

Value

Relationship_type IMSReference::RelationshipDegree 2Named_role_types “ReferencesRole”, IMSReference::ReferencesRole;

“ReferencedByRole”, CoReference::ReferencedByRoleThe IMSRelationships::RelationshipFactory::create operation will raise DegreeError if the numberof roles passed as arguments is not 2. It will raise RoleTypeError if the roles are notIMSReference::ReferencesRole and IMSReference::ReferencedByRole.RoleFactory attribute forReferencesRole

Value

Role_type IMSReference::ReferencesRoleMaximum_cardinality UnboundedMinimum_cardinality 0Related_object_types IMSGraphs::NodeThe IMSRelationships::RoleFactory::create_role operation will raise theRelatedObjectTypeError if the related object passed as a parameter does not support theIMSGraphs::Node interface. The IMSRelationships::RoleFactory::link operation will raiseRelationshipTypeError if the rel parameter does not conform to the IMSReference::Relationshipinterface.RoleFactory attribute for Value



ReferencedByRoleRole_type IMSReference::ReferencedByRoleMaximum_cardinality UnboundedMinimum_cardinality 0Related_object_types IMSGraphs::NodeThe IMSRelationships::RoleFactory::create_role operation will raise theRelatedObjectTypeError if the related object passed as a parameter does not support theIMSGraphs::Node interface. The IMSRelationships::RoleFactory::link operation will raiseRelationshipTypeError if the rel parameter does not conform to theIMSRelationship::Relationship interface.

10.4.5 References1. James Rumbaugh, “Controlling Propagation of Operations using Attributes onRelations.” OOPSLA 1988 Proceedings, pg. 285-296.2. James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy and WilliamLorensen, “Object-oriented Modeling and Design.” Prentice Hall, 1991.

10.4.6CORBA IDL

#ifndef _OBJECTIDENTITY_IDL_#define _OBJECTIDENTITY_IDL_

module IMSObjectIdentity{typedef unsigned long ObjectIdentifier;interface IdentifiableObject{

readonly attribute ObjectIdentifier constant_random_id;boolean is_identical (in IdentifiableObject other_object);

};};

#ifndef _RELATIONSHIPS_IDL_#define _RELATIONSHIPS_IDL_

#include <ObjectIdentity.idl>module IMSRelationships{interface RoleFactory;interface RelationshipFactory;interface Relationship;interface Role;interface RelationshipIterator;

typedef Object RelatedObject;typedef sequence<Role> Roles;

typedef string RoleName;typedef sequence<RoleName> RoleNames;

struct NamedRole {RoleName name; Role aRole;};typedef sequence<NamedRole> NamedRoles;

struct RelationshipHandle{

Relationship the_relationship;



IMSObjectIdentity::ObjectIdentifier constant_random_id;};typedef sequence<RelationshipHandle> RelationshipHandles;

interface RelationshipFactory{

struct NamedRoleType{

RoleName name;::CORBA::InterfaceDef named_role_type;

};typedef sequence<NamedRoleType> NamedRoleTypes;

readonly attribute ::CORBA::InterfaceDef relationship_type;readonly attribute unsigned short degree;readonly attribute NamedRoleTypes named_role_types;

exception RoleTypeError {NamedRoles culprits;};exception MaxCardinalityExceeded {NamedRoles culprits;};exception DegreeError {unsigned short required_degree;};exception DuplicateRoleName {NamedRoles culprits;};exception UnknownRoleName {NamedRoles culprits;};

Relationship create (in NamedRoles named_roles)raises (RoleTypeError,

MaxCardinalityExceeded,DegreeError,DuplicateRoleName,UnknownRoleName);

};

interface Relationship : IMSObjectIdentity::IdentifiableObject{

exception CannotUnlink {Roles offending_roles;};readonly attribute NamedRoles named_roles;void destroy () raises(CannotUnlink);

};

interface Role{

exception UnknownRoleName {};exception UnknownRelationship {};exception RelationshipTypeError {};exception CannotDestroyRelationship {RelationshipHandles offenders;};exception ParticipatingInRelationship {RelationshipHandles the_relationships;};

readonly attribute RelatedObject related_object;RelatedObject get_other_related_object (in RelationshipHandle rel,

in RoleName target_name)raises (UnknownRoleName,

UnknownRelationship);

Role get_other_role ( in RelationshipHandle rel,in RoleName target_name)

raises (UnknownRoleName, UnknownRelationship);

void get_relationships (in unsigned long how_many,out RelationshipHandles rels,



out RelationshipIterator iterator);

void destroy_relationships()raises(CannotDestroyRelationship);

void destroy() raises(ParticipatingInRelationship);

boolean check_minimum_cardinality ();

void link ( in RelationshipHandle rel,in NamedRoles named_roles)

raises( RelationshipFactory::MaxCardinalityExceeded,RelationshipTypeError);

void unlink (in RelationshipHandle rel)raises (UnknownRelationship);

};

interface RoleFactory{

exception NilRelatedObject {};exception RelatedObjectTypeError {};

readonly attribute ::CORBA::InterfaceDef role_type;readonly attribute unsigned long max_cardinality;readonly attribute unsigned long min_cardinality;readonly attribute sequence<::CORBA::InterfaceDef> related_object_types;

Role create_role (in RelatedObject related_object)raises (NilRelatedObject, RelatedObjectTypeError);

};

interface RelationshipIterator{

boolean next_one (out RelationshipHandle rel);

boolean next_n (in unsigned long how_many,out RelationshipHandles rels);

void destroy ();};

};

#endif // _RELATIONSHIPS_IDL_

#ifndef _GRAPHS_IDL_#define _GRAPHS_IDL_

#include <Relationships.idl>#include <ObjectIdentity.idl>

module IMSGraphs{interface TraversalFactory;interface Traversal;interface TraversalCriteria;interface Node;interface NodeFactory;



interface Role;interface EdgeIterator;

struct NodeHandle{

Node the_node;

::IMSObjectIdentity::ObjectIdentifier constant_random_id;};

typedef sequence<NodeHandle> NodeHandles;

struct NamedRole{

Role the_role;::IMSRelationships::RoleName the_name;

};

typedef sequence<NamedRole> NamedRoles;

struct EndPoint{

NodeHandle the_node;NamedRole the_role;

};typedef sequence<EndPoint> EndPoints;

struct Edge{

EndPoint from;::IMSRelationships::RelationshipHandle the_relationship;EndPoints relatives;

};typedef sequence<Edge> Edges;

enum PropagationValue {deep, shallow, none, inhibit};

enum Mode {depthFirst, breadthFirst, bestFirst};

interface TraversalFactory{

Traversal create_traversal_on ( in NodeHandle root_node,in TraversalCriteria the_criteria,in Mode how);

};

interface Traversal{

typedef unsigned long TraversalScopedId;

struct ScopedEndPoint{

EndPoint point;TraversalScopedId id;

};typedef sequence<ScopedEndPoint> ScopedEndPoints;

struct ScopedRelationship



{::IMSRelationships::RelationshipHandle scoped_relationship;TraversalScopedId id;

};

struct ScopedEdge{

ScopedEndPoint from;ScopedRelationship the_relationship;ScopedEndPoints relatives;

};typedef sequence<ScopedEdge> ScopedEdges;

boolean next_one (out ScopedEdge the_edge);

boolean next_n (in short how_many,out ScopedEdges the_edges);

void destroy ();};

interface TraversalCriteria{

struct WeightedEdge{

Edge the_edge;unsigned long weight;sequence<NodeHandle> next_nodes;

};typedef sequence<WeightedEdge> WeightedEdges;

void visit_node(in NodeHandle a_node,in Mode search_mode);

boolean next_one (out WeightedEdge the_edge);

boolean next_n (in short how_many,out WeightedEdges the_edges);

void destroy();};

interface Node: ::IMSObjectIdentity::IdentifiableObject{

typedef sequence<Role> Roles;

exception NoSuchRole {};exception DuplicateRoleType {};

readonly attribute ::IMSRelationships::RelatedObject related_object;readonly attribute Roles roles_of_node;

Roles roles_of_type (in ::CORBA::InterfaceDef role_type);

void add_role (in Role a_role)raises (DuplicateRoleType);

void remove_role (in ::CORBA::InterfaceDef of_type)



raises (NoSuchRole);};

interface IResource: INode{

IMSGroup::IGroup group;IMSSession::ISession session;

};

interface NodeFactory{

Node create_node (in Object related_object);};

interface Role : ::IMSRelationships::Role{

void get_edges ( in long how_many,out Edges the_edges,out EdgeIterator the_rest);

};

interface EdgeIterator{

boolean next_one (out Edge the_edge);

boolean next_n ( in unsigned long how_many,out Edges the_edges);

void destroy ();};

};

#ifndef _CONTAINMENT_IDL_#define _CONTAINMENT_IDL_


module IMSContainment{interface Relationship : ::IMSRelationships::Relationship {};

interface ContainsRole : ::IMSGraphs::Role {};

interface ContainedInRole : ::IMSGraphs::Role {};};

#endif _CONTAINMENT_IDL

#ifndef _REFERENCE_IDL_#define _REFERENCE_IDL_


module IMSReference{interface Relationship : ::IMSRelationships::Relationship {};

interface ReferencesRole : IMSGraphs::Role {};



interface ReferencedByRole : ::IMSGraphs::Role {};

};

#endif _REFERENCE_IDL_

10.4.7DCOM IDL

10.5Property Service Interface

10.5.1Origin of InterfacesThe following information is based entirely on World Wide Web Consortium’s ( W3C ) Document ObjectModel. The only changes that have been made, other than the addition of IMS context information, is theharmonization of interface signatures with the rest of the IMS and the possible removal of some low levelW3C dependencies.


10.5.2.1.1.1Module Property

10.5.2.1.2The IProperty Interface

The IProperty interface allows an object to maintain a dynamically associated property set. The contents ofthis property set does not change the fundamental type of the object it is attached to. This interface carriesthe features of simple get/set/add property methods as well as the RDF property methods being developedby the W3C. This will allow an object to carry arbitrarily complex dynamic properties. This is especiallyusefull for attaching the value of Metadata to an instance of the Metadata interface. Every instance ofMetadata could include a different schema of data, but it is still of the type Metadata.

10.5.2.1.2.1mUserThis is a reference to the IMSUser that owns this PersonalData

10.5.2.1.2.2GetPropertyThis method returns a named property.

10.5.2.1.2.3SetPropertyThis method sets a named property. If the property already exists, the implementation of the method mustupdate the existing property.

10.5.2.1.2.4AddPropertyThis method adds the named property. The property is always added as new, regardless if there is already aproperty of the same name. In this case there will end up two properties named the same.

10.5.2.1.2.5ParseThis method parses an XML only stream, or an RDF description expressed in XML, into a Documentobject which can then be manipulated via the methods exposed by the IDocument Interface.

10.5.2.2 Module DocumentThis module contains the W3C Document Object Model. This model is being adopted by the IMS for themanipulation of complex property sets. Both the Metadata and the Property interfaces utilize this module.



10.5.2.2.1The IAttribute Interface

The Attribute object represents an attribute in an Element object. Typically the allowable values for theattribute are defined in a document type definition.

10.5.2.2.1.1valueThe children of this Node define the effective value of this attribute. ( The attribute's effective value isdetermined as follows: if this attribute has been explicitly assigned any value, that value is the attribute'seffective value; otherwise, if there is a declaration for this attribute, and that declaration includes a defaultvalue, then that default value is the attribute's effective value; otherwise, the attribute has no effective value.) Note, in particular, that an effective value of the null string would be returned as a Text node instancewhose toString method will return a zero length string ( as will toString invoked directly on this Attributeinstance). If the attribute has no effective value, then this method will return null. Note the toString methodon the Attribute instance can also be used to retrieve the string version of the attribute's value(s). There canbe multiple objects defined as the value of an attribute because the raw attribute value can contain entityreferences. Thus the value of the attribute could be represented by a single Text node, ( and always will inHTML ) or a series of Text nodes interspersed with EntityReference nodes ( in XML ).

10.5.2.2.1.2specifiedIf this attribute was explicitly given a value in the original document, this will be true; otherwise it will befalse.

10.5.2.2.1.3GetNameReturns the name of this attribute.

10.5.2.2.1.4ToStringReturns the value of the attribute as a string. Character and general entity references will have been replacedwith their values in the returned string.

10.5.2.2.2The IAttributeDefinition interface

The IAttributeDefinition interface is used to access information about a particular attribute definition on agiven element. Objects supporting this interface are available from the ElementDefinition object through theattributeDefinitions attribute.

10.5.2.2.2.1nameThe name of the attribute.

10.5.2.2.2.2StringListThis list of tokens that are allowed as values.

10.5.2.2.2.3declaredTypeThis attribute indicates the type of values the attribute may contain. Taken from the first set of constantdeclarations in this interface.

10.5.2.2.2.4defaultTypeThis specifies whether the attribute must be specified in the instance, and if it is not, what the attributevalue will be if not provided.

10.5.2.2.2.5defaultValueThis provides an interface to a Node whose children make up the default value for an attribute. This valueis used if the attribute was not given an explicit value in the document instance.

10.5.2.2.2.6attributeListThe AttributeList object represents a collection of Attribute objects, indexed by attribute name.AttributeList objects are used to represent collections of Attribute objects which can be accessed by name.



The Attribute objects contained in a AttributeList may alos be accessed by ordinal index. In most cases,AttributeList objects are created from Element objects.

10.5.2.2.2.7getAttributeRetrieve an Attribute instance from the list by its name. If it is not present, a null is returned.

10.5.2.2.2.8setAttributeAdd a new attribute to the end of the list and associate it with the given name. If the name already exists,the previous Attribute object is replaced, and returned. If no object of the same name exists, null isreturned, and the named Attribute is added to the end of the AttributeList object; that is, it is accessible viathe item method using the index one less than the value returned by getLength.

10.5.2.2.2.9RemoveRemoves the Attribute instance named from the list and and returns it. If the name provided does not exist,the NoSuchAttributeException is thrown.

10.5.2.2.2.10 ItemReturns the (zero-based) indexed Attribute item in the collection. If index is greater than or equal to thenumber of nodes in the list, a NoSuchAttributeException is thrown.

10.5.2.2.2.11 GetLengthReturns the number of Attributes in the AttributeList instance.

10.5.2.2.3The ICDATASection interface

CDATA sections are used in the document instance, and provide a region in which most of the XMLdelimiter recognition does not take place. The primary purpose is for including material such as XMLfragments, without needing to escape all the delimiters. The data attribute of the Text node holds the textthat was contained by the CDATA section. Note that this may contain characters that need to be escapedoutside of CDATA sections.

10.5.2.2.4The IComment interface

Represents the content of a comment, i.e. all the characters between the starting ''. Note that this is thedefinition of a comment in XML, and, in practice, HTML, although some HTML tools may implementthe full SGML comment structure.

10.5.2.2.4.1dataThe content of the comment, exclusive of the comment begin and end sequence.

10.5.2.2.5The IDOM interface

The "DOM" interface provides a number of methods for performing operations that are independent of anyparticular instance of the document object model. Although IDL does not provide a mechanism forexpressing the concept, the methods supplied by the DOM interface will be implemented as "static", orinstance independent, methods. This means that a client application using the DOM does not have tolocate a specific instance of the DOM object; rather, the methods are will be available directly on the DOMclass itself and so are directly accessible from any execution context.

10.5.2.2.5.1CreateDocumentCreates a document of the specified type.

10.5.2.2.5.2HasFeatureReturns TRUE if the current DOM implements a given feature, FALSE otherwise.

10.5.2.2.6The IDocFragment interface

The IDocFragment object represents the root of a lightweight document or document fragment.



10.5.2.2.6.1masterDocThis provides access to the Document object associated with this DocumentFragment.

10.5.2.2.7The IDocument interface

The IDocument object extends the DocFragment interface to represent the root node of a standalonedocument. The IDocument object represents the entire HTML or XML document. Conceptually, it is theroot of the document tree, and provides the primary access to the document's data. Since IDocumentinherits from DocumentFragment, its children are contents of the Document, e.g., the root Element, theXML prolog, any processing instructions and or comments, etc. Since Elements, Text nodes, Comments,PIs, etc. cannot exist outside a Document, the Document interface also anchors the "factory" methods thatcreate these objects.

10.5.2.2.7.1documentTypeFor XML, this provides access to the Document Type Definition ( see DocumentType ) associated withthis XML document. For HTML documents and XML documents without a document type definition thisreturns the value null.

10.5.2.2.7.2documentElementThis is a "convenience" attribute to jump directly to the child node that is the root element of thedocument.

10.5.2.2.7.3contextInfo

10.5.2.2.7.4CreateDocumentContextCreate and return a new DocumentContext.

10.5.2.2.7.5CreateElementCreate an element based on the tagName. Note that the instance returned may implement an interfacederived from Element. The attributes parameter can be null if no attributes are specified for the newElement.

10.5.2.2.7.6CreateTextNodeCreate a Text node given the specified string.

10.5.2.2.7.7CreateCommentCreate a Comment node given the specified string.

10.5.2.2.7.8CreatePICreate a PI node given the specified name and data strings.

10.5.2.2.7.9CreateAttributeCreate an Attribute of the given name and specified value. Note that the Attribute instance can then be seton an Element using setAttribute method.

10.5.2.2.7.10 CreateAttributeListCreate an empty AttributeList.

10.5.2.2.7.11 GetElementsByTagNameReturns an iterator through all subordinate Elements with a given tag name.

10.5.2.2.8The IDocumentContext interface



The IDocumentContext object is repository for meta-data about a document, such as source, creation date,and other creation context information. This object will be fully specified in the level two DOMspecification.

10.5.2.2.8.1document

10.5.2.2.9The IDocumentType interface

Each document has a ( possibly null ) attribute that contains a reference to an IDocumentType object. TheIDocumentType class provides an interface to access all of the entity declarations, notation declarations, andall the element type declarations. NOTE: There is no way currently of accessing the list of entities declaredwithin a DTD. The W3C will add this once discussion about entity representation is completed.

10.5.2.2.9.1nameThe name attribute holds the name of the DTD, i.e. the name immediately following the DOCTYPEkeyword.

10.5.2.2.9.2externalSubsetThis attribute's children reference the list of nodes ( definitions ) that occurred in the external subset of adocument.

10.5.2.2.9.3internalSubsetThe internal subset's children constitute all the definitions that occurred within the internal subset of adocument ( the part that appears within the document instance).

10.5.2.2.9.4generalEntitiesThis is a Node whose children constitute the set of general entities that were defined within the external andthe internal subset.

10.5.2.2.9.5parameterEntitiesThis is a Node whose children constitute the set of parameter entities that were defined within the externaland the internal subset. All objects supporting the INode interface that are accessed through this attributewill also support the IEntity interface.

10.5.2.2.9.6notationsThis is a Node whose children constitute the set of notations that were defined within the external and theinternal subset. All objects supporting the INode interface that are accessed through this attribute will alsosupport the Entity interface.

10.5.2.2.9.7elementTypesThis is a Node whose children constitute the set of element types that were defined within the external andinternal subset. All objects supporting the INode interface that are accessed through this attribute will alsosupport the IElementDefinition interface.

10.5.2.2.10 The IElement interface

Element objects represent the elements in the HTML or XML document. Elements contain, as child nodes,all the content between the start tag, and the end tag of an element. Additionally, Element objects have alist of Attribute objects which represent the combination of those attributes explicitly specified in thedocument, and those defined in the document type definition which have default values. By far the vastmajority ( apart from text ) of node types that authors will generally encounter when traversing a documentwill be Element nodes. These objects represent both the element itself, as well as any contained nodes.

10.5.2.2.10.1 GetTagNameThis method returns the string that is the element's name.



10.5.2.2.10.2 attributesThe attributes for this element. The attributes will include the actual values of the element as well as anyattributes defined in this element's document type definition with have default values.

10.5.2.2.10.3 SetAttributeAdds a new attribute/value pair to an Element node object. If an attribute by that name is already present inthe element, it's value is changed to be that of the Attribute instance.

10.5.2.2.10.4 NormalizePuts all Text nodes sub-tree underneath this element into "DOM Normal Form", i.e., Text nodes aremerged so that only markup ( e.g. tags and entity references ) separates Text nodes.

10.5.2.2.10.5 GetElementsByTagNameReturns an iterator through all subordinate Elements with a given tag name.

10.5.2.2.11 The IElementDefinition interface

The definition of each element defined within the external or internal subset ( providing it is parsed ), willbe available through the elementTypes attribute of the DocumentType object. The name, attribute list, andcontent model are all available for inspection.

10.5.2.2.11.1 EMPTYThe element is an empty element, and cannot have content

10.5.2.2.11.2 ANYThe element may have character data, or any of the other elements defined within the DTD as content, inany order and sequence.

10.5.2.2.11.3 PCDATAThe element can have only PCDATA ( Parsed Character Data ) as content.

10.5.2.2.11.4 MODEL_GROUPThe element has a specific content model associated with it. The model is accessible through thecontentModel attribute.

10.5.2.2.11.5 NAMEThis is the name of the type of element being defined.

10.5.2.2.11.6 contentTypeThis attribute, one of the constant declarations in this interface, specifies the type of content of the element.

10.5.2.2.11.7 contentModelIf the contentType is MODEL_GROUP, then this will provide access to a ModelGroup object that is theroot of the content model object heirarchy for this element. For other content types, this will be null.

10.5.2.2.11.8 attributeDefinitionsThis children of this Node consist of the attributes that were defined to be on an ElementDefinition. Eachobject supporting the INode interface that is access through this attribute will also support theIAttributeDefinition interface.

10.5.2.2.11.9 inclusionsThe children of this Node define a list of element type names that are included in the content model of thiselement by the SGML inclusion/exception mechanism ( not available from XML, but used in HTML ).



10.5.2.2.11.10 exceptionsThis children of this node define a list of element type names that are excluded from the content model ofthis element by the SGML inclusion/exception mechanism ( not available from XML, but used in HTML).

10.5.2.2.12 The IElementToken interface

Token for an element declaration.

10.5.2.2.12.1 OPTThe ? occurrence indicator.

10.5.2.2.12.2 PLUSThe + occurrence indicator.

10.5.2.2.12.3 REPThe * occurrence indicator.

10.5.2.2.12.4 nameThe element type name.

10.5.2.2.12.5 occurrenceThe number of times this element can occur.

10.5.2.2.13 The IEntityDeclaration interface

10.5.2.2.13.1 replacementStringThe string that a reference to this entity is replaced with. It may contain markup and entity references. Itdoes not apply to un-parsed entities.

10.5.2.2.13.2 replacementSubtreeThe parsed subtree that references to this entity would logically point to. All markup in the replacementstring is represented as sub-trees, and entity references are expanded.

10.5.2.2.14 The IEntityReference interface

EntityReference objects are inserted into the initial structure model by the XML processor. XML does notmandate that a non-validating XML processor read and process entity declarations make in the externalsubset or that are declared in external parameter entities. This means that parsed entities that are declared inthe external subset need not be expanded by some classes of applications. XML contains the notion of"parsed entities" that are declared in the DTD, defined either internally in a document or in an external file,and referenced one or more places in the document. In any event, parsed entities allow an abstract referenceto some arbitrarily large or complex piece of text and markup. Parsed entities are one type of general entity.The other type of general entity that XML defines is the unparsed entity, used for embedding data that isnot in XML format in an XML document. It is commonly used for images. Parameter entities are used inDTDs for similar purposes as parsed entities in document instances; namely they allow an abstract referenceto some part of the DTD. XML defines a number of rules about the allowed content of a parameter entity;the reader is referred to the XML specification for details.

10.5.2.2.14.1 IsExpandedThe default view of the entities is to be expanded.

10.5.2.2.14.2 Expand

10.5.2.2.15 The IModelGroup interface



The ModelGroup object represents the content model of an ElementDefinition. The content model isrepresented as a tree, where each node specifies how its children are connected, and the number of times thatit can occur within its parent. Leaf nodes in the tree are either PCDATAToken or ElementToken.

10.5.2.2.15.1 OPTThe ? occurrence indicator.

10.5.2.2.15.2 PLUSThe + occurrence indicator.

10.5.2.2.15.3 REPThe * occurrence indicator.

10.5.2.2.15.4 ORThe | connection indicator.

10.5.2.2.15.5 SEQThe , connection indicator.

10.5.2.2.15.6 ANDThe ?? connection indicator.

10.5.2.2.15.7 occurrenceThe number of times this model can occur.

10.5.2.2.15.8 connectorDescribes how the tokens are connected together.

10.5.2.2.15.9 tokensThe children of this node define the list of tokens in this model group.

10.5.2.2.16 The INode interface

The Node object is the primary datatype for the entire Document Object Model. It represents a single nodein the document tree. Nodes may have, but are not required to have, an arbitrary number of child nodes.

10.5.2.2.16.1 GetNodeTypeReturns an indication of the underlying Node object's type. The actual type of the returned data is languagebinding dependent; the IDL specification uses an enum, and it is expected that most language bindings willrepresent this runtime-queryable Node type using an integral data type. The names of the node typeenumeration literals are straightforwardly derived from the names of the actual Node subtypes, and are fullyspecified in the IDL definition of Node in the IDL definition in Appendix A of the W3C Document ObjectModel (Core) Level 1 document.

10.5.2.2.16.2 GetParentNodeReturns the parent of the given Node instance. If this node is the root of the document object tree, or if thenode has not been added to a document tree, null is returned.

10.5.2.2.16.3 GetChildNodesReturns a NodeIterator object that will enumerate all children of this node. If there are no children, aniterator that will return no nodes is returned. The content of the returned NodeIterator is "live" in the sensethat changes to the children of the Node object that it was created from will be immediately reflected in thenodes returned by the iterator; it is not a static snapshot of the content of the Node. Similarly, changesmade to the nodes returned by the iterator will be immediately reflected in the tree, including the set ofchildren of the Node that the NodeIterator was created from.



10.5.2.2.16.4 HasChildNodesReturns true if the node has any children, false if the node has no children at all. This method exists bothfor convenience as well as to allow implementations to be able to bypass object allocation, which mayrequired for implementing getChildNodes.

10.5.2.2.16.5 GetFirstChildReturns the first child of a node. If there is no such node, null is returned.

10.5.2.2.16.6 GetPreviousSiblingReturns the node immediately preceding the current node in a breadth-first traversal of the tree. If there is nosuch node, null is returned.

10.5.2.2.16.7 GetNextSiblingReturns the node immediately following the current node in a breadth-first traversal of the tree. If there is nosuch node, null is returned.

10.5.2.2.16.8 InsertBeforeInserts a child node ( newChildbefore the existing child node refChild. If refChild is null, insert newChildat the end of the list of children. If refChild is not a child of the Node that insertBefore is being invoked on,a NotMyChildException is thrown.

10.5.2.2.16.9 ReplaceChildReplaces the child node oldChild with newChild in the set of children of the given node, and returns theoldChild node. If oldChild was not already a child of the node that the replaceChild method is beinginvoked on, a NotMyChildException is thrown.

10.5.2.2.16.10 RemoveChildRemoves the child node indicated by oldChild from the list of children and returns it. If oldChild was not achild of the given node, a NotMyChildException is thrown.

10.5.2.2.17 The INodeIterator interface

The NodeIterator object is used for iterating over a set of nodes specified by a "filter". Iterators are describedin detail in the book Design Patterns, pages 257-271, from which the following sections are quoted: IntentProvide a way to access elements of an aggregate object sequentially without exposing its underlyingrepresentation. Applicability Use the Iterator pattern to access an aggregate object's content withoutexposing its internal representation. to support multiple traversals of aggregate objects. to provide auniform interface for traversing different aggregate structures (that is, to support polymorphic iteration). ANodeIterator is a very simple iterator class that can be used to provide a simple linear view of the documenthierarchy.

10.5.2.2.17.1 GetLengthThis method returns the number of items that will be iterated over if the iterator is started at the beginning,and toNext() is called repeatedly until the end of the sequence is encountered. Note: This may be anexpensive operation. NOTE: This method will always return the correct number of items in a singlethreaded environment, but may return misleading results in a multi-threaded, multi-user situations.

10.5.2.2.17.2 GetCurrentThis method returns the Node over which the iterator currently rests. NOTE: This may be unsafe inuncontrolled multi-user or multi-threaded applications.

10.5.2.2.17.3 ToNextThis method alters the internal state of the iterator such that the node it references is the next in thesequence the iterator is presenting relative to the current position. Null is returned if it is not possible toiterate any further.



10.5.2.2.17.4 ToPreviousThis method alters the internal state of the iterator such that the node it references is the previous node inthe sequence the iterator is presenting relative to the current position. Null will be returned when it is notpossible to iterate any further.

10.5.2.2.17.5 ToFirstThis method alters the internal state of the iterator such that the node it references is the first node in thesequence the iterator is presenting relative to the current position. Null will be returned if there are no itemsto iterate over.

10.5.2.2.17.6 ToLastThis method alters the internal state of the iterator such that the node it references is the last node in thesequence the iterator is presenting relative to the current position. Null will be returned only when there areno items to iterate over.

10.5.2.2.17.7 ToNthThis method alters the internal state of the iterator such that the node it references is the Nth node in thesequence the iterator is presenting relative to the current position. If the value specified by Nth is greaterthan the number that would be returned from getLength() a NoSuchNodeException is thrown. NOTE: Thismay be a slow operation.

10.5.2.2.17.8 ToNodeThis method alters the internal state of the iterator such that it references the destNode node as the currentposition. If the node does not exist in the iterator, a NoSuchNodeException is thrown. NOTE: This maybe a slow operation.

10.5.2.2.18 The INotation interface

This object is used to represent the definition of a notation within a DTD.

10.5.2.2.18.1 nameThis is the name of the notation.

10.5.2.2.18.2 IsPublicIf a public identifier was specified in the notation declaration, this will be true, and the publicIdentifierattribute will contain the string for the public identifier.

10.5.2.2.18.3 publicIdentifierIf a public identifier was specified in the notation declaration, this will hold the public identifier string,otherwise it will be null.

10.5.2.2.18.4 systemIdentifierIf a system identifier was specified in the notation declaration, this will hold the system identifier string,otherwise it will be null.

10.5.2.2.19 The IPCDATAToken Interface

Token type for the string #PCDATA

10.5.2.2.20 The IPI interface

A PI node is a "processing instruction". The content of the PI node is the entire content between thedelimiters of the processing instruction

10.5.2.2.20.1 nameXML defines a name as the first token following the the markup that begins the processing instruction, andthis attribute returns that name. Form HTML, the returned value is null.



10.5.2.2.20.2 dataThe content of the processing instruction, from the character immediately after the .

10.5.2.2.21 The IStringList interface

A sequence of wstring types.

10.5.2.2.22 The IText interface

The Text object contains the non-markup content of an Element. If there is no markup inside an Element'scontent, the text will be contained in a single Text object that is the child of the Element. Any markupwill parse into child elements that are siblings of the Text nodes on either side of it, and whose contentwill be represented as Text node children of the markup element.

10.5.2.2.22.1 dataThis holds the actual content of the text node. Text nodes contain just plain text, without markup andwithout entities, both of which are represented as separate objects in the DOM.

10.5.2.2.22.2 AppendAppend the string to the end of the character data in this Text node.

10.5.2.2.22.3 InsertInsert the string at the specified character offset.

10.5.2.2.22.4 DeleteRemove the number of characters specified by count starting at the specified character offset.

10.5.2.2.22.5 ReplaceReplace the number of characters specified by count starting at the specified character offset with the stringspecified in data.

10.5.2.2.22.6 SpliceInsert the specified Element in the tree as a sibling of the Text node. The result of this operation may bethe creation of up to 2 new Text nodes: The character data specified by the offset and count will form oneText node that will become the child of the inserted element and the remainder of the character data ( afterthe offset and count ) will form another Text node become a sibling of the original Text node.

10.5.2.2.23 The ITreeIterator interface

A TreeIterator is a NodeIterator that has additional methods that are specific to tree navigation.

10.5.2.2.23.1 NumChildrenThis method returns the number of children that lie below the current node. NOTE: This method willalways return the correct number of items in a single threaded environment, but may return misleadingresults in multi-threaded, multi-user situations.

10.5.2.2.23.2 NumPreviousSiblingsThis method returns the number of siblings that lie previous to the current node. NOTE: This method willalways return the correct number of items in a single threaded environment, but may return misleadingresults in multi-threaded, multi-user situations.

10.5.2.2.23.3 NumNextSiblingsThis method returns the number of siblings that lie after the current node. NOTE: This method will alwaysreturn the correct number of items in a single threaded environment, but may return misleading results inmulti-threaded, multi-user situations.

10.5.2.2.23.4 ToParent



Move the iterator to the parent of the current node, if there is a parent. This method will return a null whenthere is no parent for the current node.

10.5.2.2.23.5 ToPreviousSiblingMove the iterator to the previous sibling of the current node, if there is one. This method will return null ifthere is no previous sibling for the current node.

10.5.2.2.23.6 ToNextSiblingMove the iterator to the next sibling of the current node, if there is one. This method will return null whenthere is no next sibling for the current node.

10.5.2.2.23.7 ToFirstChildMove the iterator to the first child of the current node, if there is one. This method will return null whenthere is no children for the current node.

10.5.2.2.23.8 ToLastChildMove the iterator to the last child of the current node, if there is one. This method will return null whenthere are no children for the current node.

10.5.2.2.23.9 ToNthChildThis method alters the internal state of the iterator such that the node it references is the Nth child of thecurrent node. NOTE: The current draft W3C spec has no parameters on this method. This is impossible.IMS has added a parameter, Nth, for the time being. It is also ambiguous as to whether the method shouldreturn null or throw an exception when the value provided is greater than the number that would bereturned from numChildren.

10.5.2.2.24 The IXMLNode interface

The XML implementation of the Node interface adds some methods that are needed to manipulate specificfeatures of XML documents.

10.5.2.2.24.1 GetParentXMLNodeReturns the parent of the given Node instance. If this node is the root of the document object tree, or if thisnode is not part of a document tree, null is returned. The expandEntities parameter should be true if theview of the tree with parsed entities expanded should be navigated, false if the view without parsed entitiesexpanded should be navigated.

10.5.2.2.24.2 GetChildXMLNodesReturns a NodeIterator object that will enumerate all children of this node. If there are no children, aniterator that will return no nodes is returned. The content of the returned NodeIterator is "live" in the sensethat changes to the children of the Node object that it was created from will be immediately reflected in thenodes returned by the iterator; it is not a static snapshot of the content of the Node. Similarly, changesmade to the nodes returned by the iterator will be immediately reflected in the tree, including the set ofchildren of the Node that the NodeIterator was created from. The expandEntities parameter should be true ifthe view of the tree with parsed entities expanded should be navigated, false if the view without parsedentities expanded should be navigated.

10.5.2.2.24.3 HasChildXMLNodesReturns true if the node has any children, false if hte node has no children at all. This method exists bothfor convenience as well as to allow implementations to be able to bypass object allocation, which may berequired for implementing getChildNodes(). The expandEntities parameter should be true if the view of thetree with parsed entities expanded should be navigated, false if the view without parsed entities expandedshould be navigated.

10.5.2.2.24.4 GetFirstXMLChild



Returns the first child of a node. If there is no such node, null is returned. The expandEntities parametershould be true if the view of the tree with parsed entities expanded should be navigated, false if the viewwithout parsed entities expanded should be navigated.

10.5.2.2.24.5 GetPreviousXMLSiblingReturns the node immediately preceding the current node in a breadth-first traversal of the tree. If there is nosuch node, null is returned. The expandEntities parameter should be true if the view of the tree with parsedentities expanded should be navigated, false if the view without parsed entities expanded should benavigated.

10.5.2.2.24.6 GetNextXMLSiblingReturns the node immediately following the current node in a breadth-first traversal of the tree. If there is nosuch node, null is returned. The expandEntities parameter should be true if the view of the tree with parsedentities expanded should be navigated, false if the view without parsed entities expanded should benavigated.

10.5.2.2.24.7 GetEntityReferenceWhen navigating XML trees with expandedEntities set to true, the DOM programmer will on occasion getNodes returned that are part of the expansion of an entity rather than actual nodes in the tree. This methodreturns the entity reference that generated a particular node, or null if it was not part of an entity referenceexpansion.

10.5.2.2.24.8 GetEntityDeclarationWhen navigating XML trees with expandedEntities set to true, the DOM programmer will on occasion getNodes returned that are part of the expansion of an entity rather than actual nodes in the tree. This methodreturns the declaration for the entity reference that generated a particular node, or null if it was not part of anentity reference expansion.

10.5.3CORBA IDL

#ifndef _DOCUMENT_IDL_#define _DOCUMENT_IDL_

module Document{

typedef sequence<wstring> StringList;

exception NoSuchNodeException {};exception NotMyChildException {};

// Enumerator class for a node listinterface INodeEnumerator{

INode GetFirst();INode GetNext();INode GetPrevious();INode GetLast();

INode GetCurrent();

// The rationale for their existence is that the enumerator may be used// internally to a method, which may return some interesting value, and// therefore cannot also indicate whether the start or end of enumeration// was reached. Any of the traversal methods affects the state, and// so are not suitable for usage as predicates (unless possible state// manipulation is acceptable).



boolean AtStart();boolean AtEnd();

};

// Define the type for a sequence of nodesinterface INodeList{

INodeEnumerator getEnumerator();

INode Item(in unsigned long index)raises(NoSuchNodeException);

// This may be expensive to computeunsigned long GetLength();

};

// Define the type for a sequence of nodesinterface IEditableNodeList : INodeList{

void Replace(in unsigned long index, in INode replacedNode)raises (NoSuchNodeException);

void Insert(in unsigned long index, in INode newNode)raises (NoSuchNodeException);

INode Remove(in unsigned long index)raises (NoSuchNodeException);

};

interface IDocumentType : INode{

attribute wstring name;

attribute INodeList externalSubset;attribute INodeList internalSubset;

attribute INamedNodeList notations;attribute INamedNodeList elementTypes;

};

enum OccurrenceType{

OPT, // ?PLUS, // +REP // *

};

interface IElementDefinition : INode{

enum ContentType{

EMPTY,ANY,PCDATA,MODEL_GROUP

};




attribute ContentType contentType;attribute IModelGroup contentModel;

attribute INamedNodeList attributeDefinitions;attribute StringList inclusions;attribute StringList exceptions;

};

interface IModelGroup : INode{

enum ConnectionType{

OR, // |SEQ, // ,AND

};

attribute ConnectionType connector;attribute OccurrenceType occurrence;attribute INodeList tokens;

};

interface IPCDATAToken : INode{

// Token type for the string #PCDATA};

interface IElementToken: INode{

attribute wstring name;attribute OccurrenceType occurrence;

};

interface IAttributeDefinition : INode{

enum DeclaredValueType{

CDATA,ID,IDREF,IDREFS,ENTITY,ENTITIES,NMTOKEN,NMTOKENS,NOTATION,NAME_TOKEN_GROUP

};

enum DefaultValueType{

VALUE, // The default value was an attribute value// specification without #FIXED.

FIXED,REQUIRED,IMPLIED

};



attribute wstring name;attribute StringList allowedTokens;attribute DeclaredValueType declaredType;attribute DefaultValueType defaultType;attribute INodeList defaultValue;

};

interface INotation : INode{


attribute boolean isPublic;

attribute wstring publicIdentifier;attribute wstring systemIdentifier;

};

typedef sequence<octet> buffer;

interface IEntity : INode{

attribute wstring name;attribute boolean isParameterEntity;

};

interface IInternalEntity : IEntity{

attribute wstring content;};

interface IExternalEntity : IEntity{

attribute boolean isNDATA;attribute boolean isPublic;

attribute string publicIdentifier;attribute string systemIdentifier;

};

interface IExternalTextEntity : IExternalEntity{

attribute wstring content;};

interface IExternalNDATAEntity : IExternalEntity{

attribute Notation notation;attribute buffer content;

};

interface INDATA : INode{

attribute buffer content;};

interface IDOM



{IDocument CreateDocument(in wstring type);boolean HasFeature(in wstring feature);

};

interface IDocumentContext{

attribute IDocument document;};

interface IDocumentFragment : INode{

attribute IDocument masterDoc;};

interface IDocument : IDocumentFragment{

attribute INode documentType;attribute IElement documentElement;attribute IDocumentContextcontextInfo;IDocumentContext CreateDocumentContext();IElement CreateElement( in wstring tagName,

in IAttributeList attributes);IText CreateTextNode(in wstring data);IComment CreateComment(in wstring data);IPI CreatePI(in wstring name,

in wstring data);IAttribute CreateAttribute(in wstring name,

in INode value);IAttributeList CreateAttributeList();ITreeIterator CreateTreeIterator(in INode node);INodeIterator GetElementsByTagName(in wstring tagname);

};

interface INode{ // NodeType

const int DOCUMENT = 1;const int ELEMENT = 2;const int ATTRIBUTE = 3;const int PI = 4;const int COMMENT = 5;const int TEXT = 6;

int GetNodeType();INode GetParentNode();INodeIterator GetChildNodes();boolean HasChildNodes();INode GetFirstChild();INode GetPreviousSibling();INode GetNextSibling();INode InsertBefore(in INode newChild, in INode refChild );INode ReplaceChild(in INode newChild,

in INode oldChild)raises (NotMyChildException);

INode RemoveChild(in INode oldChild)raises(NotMyChildException);



};

exception NotMyChildException {};

interface INodeIterator{

unsigned long GetLength();unsigned long GetCurrentPos();boolean AtFirst();boolean AtLast();INode ToNextNode();INode ToPrevNode();INode ToFirstNode();INode ToLastNode();INode MoveTo(in int n);

};

interface ITreeIterator : INodeIterator{

unsigned long NumChildren();unsigned long NumPreviousSiblings();unsigned long NumNextSiblings();INode ToParent();INode ToPreviousSibling();INode ToNextSibling();INode ToFirstChild();INode ToLastChild();INode ToNthChild(in int n)

raises( NoSuchNodeException );};

interface IAttribute{

wstring GetName();wstring GetValue();attribute boolean specified;wstring ToString();

};

interface IAttributeList{

IAttribute GetAttribute(in wstring attrName);IAttribute SetAttribute(in Attribute attr);IAttribute Remove(in wstring attrName)

raises( NoSuchAttributeException );

IAttribute Item(in unsigned long index)raises( NoSuchAttributeException );

unsigned long GetLength();};

interface IElement : INode{

wstring GetTagName();INodeIterator GetAttributes();wstring GetAttribute(in name name);void SetAttribute(in string name,



in string value);void RemoveAttribute(in wstring name);IAttribute GetAttributeNode(in name name);void SetAttributeNode(in IAttribute newAttr);void RemoveAttributeNode(in IAttribute oldAttr);void GetElementsByTagName(in wstring tagname);void Normalize();

};

interface IText : INode{

attribute wstring data;void Append(in wstring data);void Insert(in int offset,

in wstring data);void Delete(in int offset,

in int count);void Replace(in int offset,

in int count, in wstring data);

void Splice(in Element element, in int offset,

in int count);};

interface IComment : INode{

attribute wstring data;};

interface IPI : INode{

attribute wstring name;attribute wstring data;

};

interface IXMLNode{

INode GetParentXMLNode(in boolean expandEntities);INodeIterator GetChildXMLNodes(in boolean expandEntities);boolean HasChildXMLNodes(in boolean expandEntities);INode GetFirstXMLChild(in boolean expandEntities);INode GetPreviousXMLSibling(in boolean expandEntities);INode GetNextXMLSibling(in boolean expandEntities);IEntityReference GetEntityReference();IEntityDeclaration GetEntityDeclaration();

};

interface IDocumentType{

attribute wstring name;attribute INode externalSubset;attribute INode internalSubset;attribute INode generalEntities;attribute INode parameterEntities;attribute INode notations;attribute INode elementTypes;

};



interface IElementDefinition : INode{

// ContentTypeconst int EMPTY = 1;const int ANY = 2;const int PCDATA = 3;const int MODEL_GROUP = 4;

attribute wstring name;attribute int contentType;attribute IModelGroup contentModel;attribute INode attributeDefinitions;attribute INode inclusions;attribute INode exceptions;

};

interface IPCDATAToken : INode{};

interface IElementToken : INode{

// OccurrenceTypeconst int OPT = 1;const int PLUS = 2;const int REP = 3;

attribute wstring name;attribute int occurrence;

};

interface IModelGroup : INode{

// OccurrenceTypeconst int OPT = 1;const int PLUS = 2;const int REP = 3;

// ConnectionTypeconst int OR = 1;const int SEQ = 2;const int AND = 3;

attribute int occurrence;attribute int connector;attribute INode tokens;

};

interface IAttributeDefinition : INode{

// DeclaredValueTypeconst int CDATA = 1;const int ID = 2;const int IDREF = 3;const int IDREFS = 4;const int ENTITY = 5;const int ENTITIES = 6;



const int NMTOKEN = 7;const int NMTOKENS = 8;const int NOTATION = 9;const int NAME_TOKEN_GROUP = 10;

// DefaultValueTypeconst int FIXED = 1;const int REQUIRED = 2;const int IMPLIED = 3;

attribute wstring name;attribute StringList allowedTokens;attribute int declaredType;attribute int defaultType;attribute INode defaultValue;

};

interface INotation : INode{

attribute wstring name;attribute boolean isPublic;attribute string publicIdentifier;attribute string systemIdentifier;

};

interface IEntityDeclaration{

attribute wstring replacementString;attribute IDocumentFragment replacementSubtree;

};

interface IEntityReference{

attribute boolean IsExpanded;void Expand(in );

};

interface ICDATASection : IText{};

};

#endif // _DOCUMENT_IDL_

#ifndef _HTMLDOCUMENT_IDL_#define _HTMLDOCUMENT_IDL_

#include "Document.idl"

module HTMLDocument{

interface IHTMLStyle{

// Hook for level two



};

interface IHTMLCollection : INodeList{

INode namedItem(in wstring name);// Same interface, different semantics

};

interface IHTMLDocument : IDocument{

// These are all methods, because they do some processing// of the documentIHTMLCollection GetImages();IHTMLCollection GetApplets();IHTMLCollection GetLinks();IHTMLCollection GetForms();IHTMLCollection GetAnchors();IHTMLCollection GetScripts();

// These are methods because we have not defined a list// of cookies anywhere in the modelwstring GetCookie();wstring SetCookie(in wstring cookie);

readonly attribute wstring referrer;readonly attribute wstring fileSize;readonly attribute wstring fileCreatedDate;readonly attribute wstring fileModifiedDate;readonly attribute wstring fileUpdatedDate;readonly attribute IHTMLLocation location;

attribute IHTMLElement body;};

interface IHTMLLocation{

attribute wstring href;

attribute wstring protocol;attribute wstring host;attribute wstring hostname;attribute wstring port;attribute wstring pathname;attribute wstring query;attribute wstring fragment;

void Reload(in boolean flag);void Replace(in wstring url);

};

interface IHTMLElement : IElement{

attribute wstring tagName;attribute wstring className;attribute wstring id;attribute IHTMLStyle style;attribute IHTMLElement parentElement;attribute wstring title;



attribute wstring lang;attribute wstring dir;attribute wstring onClick;attribute wstring onDblClick;attribute wstring onKeyDown;attribute wstring onKeyUp;attribute wstring onKeypress;attribute wstring onMouseOut;attribute wstring onMouseOver;attribute wstring onMouseMove;attribute wstring onMouseUp;attribute wstring onMouseDown;

attribute IHTMLCollection all;

readonly attribute IHTMLDocument document;

boolean Contains(in IHTMLElement pChild);

// Note the use of Object here!!!!void AddAttribute(in wstring name, in IObject value, in long lFlags);IObject GetAttribute(in wstring name,in long lFlags);boolean RemoveAttribute(in wstring name, in long lFlags);

};

interface IHTMLLinkElement : IHTMLElement{

attribute wstring href;attribute wstring rel;attribute wstring rev;attribute wstring type;attribute wstring media;

wstring GetReadyState();};

interface IHTMLTitleElement : IHTMLElement{

attribute wstring text;};

interface IHTMLMetaElement : IHTMLElement{

attribute wstring httpEquiv;

attribute wstring content;attribute wstring name;attribute wstring text;attribute wstring url;attribute wstring charset;

};

interface IHTMLBaseElement : IHTMLElement{

attribute wstring href;attribute wstring target;

};



interface IHTMLIsIndexElement : IHTMLElement{

attribute wstring prompt;attribute wstring action;

};

interface IHTMLStyleElement : IHTMLElement{

attribute wstring type;attribute boolean disabled;attribute wstring media;

};

interface IHTMLBodyElement : IHTMLElement{

attribute wstring background;attribute wstring bgColor;attribute wstring text;attribute wstring link;attribute wstring vlink;attribute wstring alink;

};

interface IHTMLFormElement : IHTMLElement{

attribute wstring action;attribute wstring method;attribute wstring target;attribute wstring name;attribute long length;

attribute IHTMLFormElement elements;

// Note the use of Object here!!!!IHTMLElement GetItem(in IObject name, in IObject index);

IHTMLCollection GetTags(in wstring name);};

interface IHTMLSelectElement : IHTMLElement{

attribute long selectedIndex;attribute long size;attribute boolean multiple;attribute wstring name;attribute wstring type;attribute wstring value;attribute boolean disabled;attribute long length;

readonly attribute IHTMLFormElement form;attribute IHTMLCollection options;

void Add(in IHTMLElement element, in IHTMLElement before);void Remove(in long index);

IHTMLElement GetItem(in wstring name);IHTMLCollection GetTags(in wstring tagname);



};

interface IHTMLOptionElement : IHTMLElement{

attribute wstring text;attribute long index;attribute boolean selected;attribute wstring value;attribute boolean defaultSelected;

readonly attribute IHTMLFormElement form;};

interface IHTMLFieldSetElement : IHTMLElement{

attribute wstring align;};

interface IHTMLLegendElement : IHTMLElement{


interface IHTMLInputTextElement : IHTMLElement{

attribute wstring value;attribute wstring name;attribute boolean disabled;attribute wstring defaultValue;attribute long size;attribute long maxLength;attribute boolean readOnly;attribute boolean checked;attribute boolean defaultChecked;


interface IHTMLTextAreaElement : IHTMLElement{

attribute wstring type;attribute wstring value;attribute wstring name;attribute boolean disabled;attribute wstring defaultValue;attribute boolean readOnly;attribute long rows;attribute long cols;attribute wstring wrap;


interface IHTMLButtonElement : IHTMLElement{

attribute wstring type;attribute wstring value;attribute wstring name;



attribute boolean disabled;


interface IHTMLLabelElement : IHTMLElement{

attribute wstring htmlFor;attribute wstring accessKey;

};

interface IHTMLAnchorElement : IHTMLElement{

attribute wstring target;attribute wstring href;attribute wstring rel;attribute wstring rev;attribute wstring name;attribute wstring accessKey;attribute long tabIndex;attribute wstring charset;

};

interface IHTMLBaseFontElement : IHTMLElement{

attribute wstring color;attribute wstring face;attribute long size;

};

interface IHTMLBRElement : IHTMLElement{

attribute wstring clear;};

interface IHTMLImgElement : IHTMLElement{

attribute boolean isMap;attribute wstring useMap;attribute wstring border;attribute long vspace;attribute long hspace;attribute wstring alt;attribute wstring src;attribute wstring lowSrc;attribute wstring align;attribute long width;attribute long height;

};

interface IHTMLFontElement : IHTMLElement{

attribute wstring color;attribute wstring face;attribute long size;

};



interface IHTMLModElement : IHTMLElement{

attribute wstring cite;attribute wstring dateTime;

};

interface IHTMLObjectElement : IHTMLElement{

// Note the use of Object here!!!!attribute IObject object;

attribute wstring classId;attribute wstring data;attribute wstring align;attribute wstring name;attribute wstring codeBase;attribute wstring codeType;attribute wstring code;attribute wstring type;attribute long width;attribute long height;attribute wstring altHtml;attribute long vspace;attribute long hspace;attribute long tabIndex;


interface IHTMLQuoteElement : IHTMLElement{

attribute wstring cite;};

interface IHTMLScriptElement : IHTMLElement{

attribute wstring src;attribute wstring text;attribute wstring type;attribute wstring language;

};

interface IHTMLUListElement : IHTMLElement{

attribute boolean compact;attribute wstring type;

};

interface IHTMLOListElement : IHTMLElement{

attribute boolean compact;attribute wstring type;attribute long start;

};

interface IHTMLLIElement : IHTMLElement{

attribute wstring type;



attribute long value;};

interface IHTMLDListElement : IHTMLElement{

attribute boolean compact;};

interface IHTMLDivElement : IHTMLElement{


interface IHTMLHRElement : IHTMLElement{

attribute wstring align;attribute boolean noShade;attribute long width;attribute long size;

};

interface IHTMLParaElement : IHTMLElement{


interface IHTMLHeaderElement : IHTMLElement{


interface IHTMLMapElement : IHTMLElement{

IHTMLCollection GetAreas();

attribute wstring name;};

interface IHTMLAreaElement : IHTMLElement{

attribute wstring shape;attribute wstring coords;attribute wstring href;attribute wstring target;attribute wstring alt;attribute boolean noHref;attribute long tabIndex;

};

interface IHTMLTableCaption : IHTMLElement{


interface IHTMLTable : IHTMLElement{

attribute long cols;attribute wstring border;



attribute wstring frame;attribute wstring rules;attribute long cellSpacing;attribute long cellPadding;attribute wstring bgColor;attribute wstring align;attribute long width;attribute IHTMLTableCaption caption;attribute IHTMLTableSection head;attribute IHTMLTableSection tfoot;

IHTMLCollection GetRows();IHTMLCollection GetBodies();

IHTMLElement CreateTHead();void DeleteTHead();

IHTMLElement CreateTFoot();void DeleteTFoot();

IHTMLTableCaption CreateCaption();void DeleteCaption();

IHTMLElement InsertRow(in long index);void DeleteRow(in long index);

};

interface IHTMLTableCol : IHTMLElement{

attribute long span;attribute wstring align;attribute wstring valign;attribute long width;

};

interface IHTMLTableSection : IHTMLElement{

IHTMLCollection GetRows();

IHTMLElement InsertRow(in long index);void DeleteRow(in long index);

attribute wstring align;attribute wstring valign;

};

interface IHTMLTableRow : IHTMLElement{

attribute long rowIndex;attribute long sectionRowIndex;attribute wstring align;attribute wstring valign;attribute wstring bgColor;

IHTMLCollection GetCells();

IHTMLElement InsertCell(in long index);



void DeleteCell(in long index);};

interface IHTMLTableCell : IHTMLElement{

attribute long cellIndex;attribute long rowSpan;attribute long colSpan;attribute wstring align;attribute wstring valign;attribute wstring bgColor;attribute boolean noWrap;attribute long width;attribute long height;

};

interface IHTMLCommentElement : IHTMLElement{

attribute wstring text;};

interface IHTMLFrameSetElement : IHTMLElement{

attribute wstring rows;attribute wstring cols;

};

interface IHTMLFrameElement : IHTMLElement{

attribute wstring src;attribute wstring name;attribute boolean noResize;attribute wstring scrolling;attribute wstring frameBorder;attribute long marginWidth;attribute long marginHeight;

};

interface IHTMLIFrameElement : IHTMLElement{

attribute wstring src;attribute wstring name;attribute wstring scrolling;attribute wstring align;attribute long marginWidth;attribute long marginHeight;attribute long width;attribute long height;

};

};

#endif // _HTMLDOCUMENT_IDL_



10.5.4

10.5.5DCOM IDL

10.6Security Service Interfaces

10.6.1Origin of InterfacesThe following information is based entirely on National Institute of Standards and Technology’s RoleBased Access Control model. The only changes that have been made, other than the addition of IMScontext information, is the harmonization of interface signatures with the rest of the IMS and the possibleremoval of some low level NIST dependencies.


10.6.2.1 Module RBAC

10.6.2.1.1The IActiveRoleSet interface

This is a subset of the authorized role set. Beyond RBAC 0, principles of mutual exclusion are introduced.Roles in the authorized role set may be mutually exclusive with other roles in that set. The active role setis a subset that contains no mutually exclusive roles.

10.6.2.1.2The IAssignedRoleSet interface

This is the set of roles directly assigned to the user. This is the role set that the role administrator edits togrant/revoke priviledges.

10.6.2.1.3The IAuthorizedRoleSet interface

This is the set of roles associated with the subject. This is a superset of the assigned role set. This setincludes any roles inherited by roles belonging to the assigned role set. For RBAC 0 the authorized roleset is the same as the assigned role set.

10.6.2.1.4The IInherit interface

This type maps a role to the set of roles from which it inherits.

10.6.2.1.4.1role

10.6.2.1.4.2inheritedRoles

10.6.2.1.5The IOperation interface

10.6.2.1.5.1operationIDThe identifier of an operation which will apply to the objects in targets.

10.6.2.1.5.2targetsThe target objects that an operation applies to.

10.6.2.1.6The IOperationDB interface

This is the operations database

10.6.2.1.7The IRBAC0 interface



RBAC 0 is the most basic type of role based access control service. It defines the functionality to defineusers and roles without the use of inheritance or separation of duty. These basic services are built on by theother classes of RBAC service.

10.6.2.1.7.1ActiveRolesRetrieve the active role set (ARS) for the subject.

10.6.2.1.7.2AddRoleAdd a role to the role and explanatory text to the database. If the database already has that role defined thenreturn the database unchanged.

10.6.2.1.7.3AddUserAdd a role to the user and explanatory text to the database. If the database already has that user defined thenreturn the database unchanged.

10.6.2.1.7.4AssignRoleAssign a role to a particular user.

10.6.2.1.7.5AuthUserCountReturn the number of users currently authorized to a role.

10.6.2.1.7.6CardinalityReturn the cardinality of a role. Role cardinality is the maximum number of users that can be authorized toa role.

10.6.2.1.7.7DeassignRoleRemove a role assignment from a user.

10.6.2.1.7.8GetRoleRetrieve a role from the role database. It is assumed that the existence of the role has already been checked.

10.6.2.1.7.9GetUserRetrieve a user from the user database. It is assumed that the existence of the user has already been checked

10.6.2.1.7.10 ExistsRoleVerify that a given role id exists in the role database. The method returns true if the role exists. NOTE:The first parameter of this method may be changed from type String to type Role.

10.6.2.1.7.11 ExistsUserVerify that a given user id exists in the user database. The method returns true if the user exists. NOTE:The first parameter of this method may be changed from type String to type User.

10.6.2.1.7.12 HasARSDetect whether the subject currenty has an active role set (ARS) defined.

10.6.2.1.7.13 HasAssignedRoleTest whether a user has a particular role. This call assumes that the existence of the user has already beenverified.

10.6.2.1.7.14 HasAnyAssignedRolesTest whether a user is assigned any roles. If the user exists in the user database, then check that theuserRoles attribute of the User is not empty.



10.6.2.1.7.15 HasAuthorizedRolepublic abstract Boolean hasAuthorizedRole(String roleID)Test whether a subject is authorized to a particular role.

10.6.2.1.7.16 MutuallyExclusiveActivationReturn the set of roles that are mutually exclusive of the given role for purposes of activating roles.

10.6.2.1.7.17 OperationObjectsRetrieve the objects on which a particular operation is permitted.

10.6.2.1.7.18 RmRoleRemove a role from the role database.

10.6.2.1.7.19 RmUserRemove a user from the user database.

10.6.2.1.7.20 RoleAssignedTest whether a role is currently assigned to any users.

10.6.2.1.7.21 RoleMembersRetrieve the users that are associated with a particular role.

10.6.2.1.7.22 RoleOperationsRetrieve the operations permitted by a particular role.

10.6.2.1.7.23 SetCardinalitySet the cardinality of a role to n. The parameter is an integer so that the value can be set to -1 to signal thatcardinality restrictions do not apply.

10.6.2.1.7.24 SetPermittedOperationAssign an operation to a particular role.

10.6.2.1.7.25 SubjectUserReturn the user associated with the given subject.

10.6.2.1.7.26 UserAuthorizedRolesThis is the set of authorized roles for a given user. In RBAC 0, this is the same as the assigned roles for auser since role inheritance and role separation is not available.

10.6.2.1.7.27 UserAssignedRolesRetrieve the roles assigned to a particular user.

10.6.2.1.7.28 UserHasAssignedRoleTest whether the user has a particular role assigned.

10.6.2.1.7.29 VerifyRBACaccessVerify that the subject can perform a given operation. Remember that a particular operation includes thetarget object being acted upon.

10.6.2.1.7.30 MutuallyExclusiveAuthorizationReturn the set of roles that are mutually exclusive of the given role for purposes of authorizing roles




RBAC 1 takes RBAC 0 and adds the notion of inheritance relationships between roles

10.6.2.1.8.1AuthorizedRolesReturns all of the roles authorized to a subject. ( More precisely to a subject's assigned role set and itsinheritance database. )

10.6.2.1.8.2EstablishInheritanceEstablish that role 1 inherits from role 2.

10.6.2.1.8.3HasAuthorizedRoleTests whether a given role is an authorized role given the assigned role set and the inheritance databaseinherit.

10.6.2.1.8.4InheritsTests whether a role inherits from another role with up to three intermediate objects in between.

10.6.2.1.8.5InheritsDirectTests whether a role inherits directly from another role.

10.6.2.1.8.6RemoveInheritanceRemove role 2 as a role inherited by role 1. If the inheritance relationship does not exist, removing it willhave no effect on the system.


RBAC 2 takes RBAC 0 and adds the notion of separation of duty. Separation of duty establishes mutualexclusion between roles on two levels. Static separation of duty controls how roles are assigned to users. Auser cannot be assigned two roles which are labeled statically separate. Dynamic separation of duty controlshow the active role set is formed for the user. Two roles with dynamic separation cannot both end up in theactive role set.

10.6.2.1.9.1AssignRoleStatic separation of duty affects the operation of assignRole. Therefore it is overloaded here to provide tonecessary functionality. In attempting to assign role 1, the entire contents of the assigned role set is checkedfor a role which is statically separate from role 1. If the assignment is successful, the new assigned role setis returned.

10.6.2.1.9.2EstablishStaticSeparationEstablish a static separation of duty between two roles. The fourth argument is the dynamic separationdatabase. This is because only a single separation of duty relationship between two roles is allowed.

10.6.2.1.9.3RemoveStaticSeparationRemove a static separation of duty between two roles.

10.6.2.1.9.4RemoveDynamicSeparationRemove a dynamic separation of duty between two roles.

10.6.2.1.10 The IRBAC3 interface

RBAC 3 takes RBAC 0 and includes both inheritance and separation of duty.

10.6.2.1.10.1 AssignRoleThis override of assignRole converges the features from RBAC 1 and RBAC2. If the assignment issuccessful, the new assigned role set is returned.

10.6.2.1.10.2 EstablishInheritance



This override of establishInheritance allows for the checking of any separation of duty conflicts.

10.6.2.1.10.3 EstablishStaticSeparationThis override of RBAC 2 incorporates inheritance into the method.

10.6.2.1.10.4 EstablishDynamicSeparationThis override of RBAC 2 incorporates inheritance into the method.

10.6.2.1.11 The IRole interface

The basic definition of a role is a structure maintaining cardinality information about the role: themembership limit and current number of users assigned the role. The isFull flag allows easy modeling ofdelete functions. Negative values for membershipLimit indicate that no membership limit has beenimposed.

10.6.2.1.11.1 roleID

10.6.2.1.11.2 IsFull

10.6.2.1.11.3 MembershipLimit

10.6.2.1.12 The IRoleDB interface

This is the collection of all roles defined in the security system.

10.6.2.1.13 The IRoleUserDB interface

This is the mapping of users to the roles that they are assigned

10.6.2.1.14 The ISecurity interface

10.6.2.1.14.1 authorizedRoles

10.6.2.1.14.2 digitalCertificate

10.6.2.1.14.3 InvokeSecure

10.6.2.1.15 The ISeparationOfDuty interface

This type maps a role to the set of roles that conflict with it. It is defined generally so as to apply to bothstatic and dynamic separation.

10.6.2.1.15.1 role

10.6.2.1.15.2 roleSet

10.6.2.1.16 The ISubject interface

This is the label given to a user session.

10.6.2.1.16.1 userID

10.6.2.1.16.2 activeRoleSetThe active role set is a subset of the authorized role set. Its contents are restricted by dynamic separation ofduty relationships between roles.

10.6.2.1.16.3 authorizedRoleSet



The set of roles associated with the subject. This includes all roles inherited by the roles in the assignedrole set.

10.6.2.1.17 The IUser interface

This is the security system's definition of a user. It contains the user identifier and the roles that the user isassigned, along with a flag indicating if the user is able to take on more roles.

10.6.2.1.17.1 userID

10.6.2.1.17.2 IsFull

10.6.2.1.17.3 UserRolesThe set of roles directly assigned to the user. This is the role set that the role administrator edits togrant/revoke priviledges.

10.6.3

10.6.4CORBA IDL

10.6.5DCOM IDL

10.7Commerce Service Interfaces


10.7.1.1 Module IMSCommerce

10.7.1.1.1The IMeter Interface

10.7.1.1.1.1LoginThis method attaches a meterable product to the commerce environment and identifiers the microaccount tobe charged for subsequent transacdtions.

10.7.1.1.1.2LogoutThe method marks the completion of a product’s usage of a microaccount. No further usages areallowed until a Login starts a new commerce session.

10.7.1.1.1.3QueryThe Query method reports whether this product will be allowed another usage. The method is able toutilize information stored in the cache during the prior cache upload session. The method returns true ifanother usage is allowed, false if not. If metering logic is not installed on the system, false should bereturned. If the account is out of balance, false should be returned.

10.7.1.1.1.4CommitThe Commit method finalizes a usage of the product in the cache.

10.7.1.1.1.5FlushThe Flush method empties all information in the cache to the back office and downloads a fresh reading ofthe enclosing Login account status. This method is for the ( hopefully ) rare products that cannot rely onthe normal cache flush logic, which uploads the cache automatically when the cache fills or monthy. In



addition, this may be used by high value products whose value is sufficiently high that an immediateredetermination of the user’s micro-account status must be obtained before accepting another transaction.

10.7.1.1.2The IBackOffice interface

10.7.1.1.2.1UploadCacheThis method is called by the IMeter::Flush method to flush the meter’s cache to the back office. AStatusTable is an encrypted key/value table containing the account status of all customer login records inthis batch of cache. The keys are customer ids and the values are booleans. The cache will decrypt thiswith the back office’s public key and store it internally to provide the values for all subsequent Query callsfor the corresponding customer id.The MeterReadings string contains all of the meter readings from this meter’s cache, encrypted fortransmission with the meter id’s public key. This string decrypts into an array of code/value pairs:Code Meaning Value1 Login Customer id2 Logout Customer id3 Query Product id4 Commit Product id

10.7.1.1.2.2DownloadBalanceThis method internally calls UploadCache and returns a FinancialAmount, the current balance in the CID’smicroaccount.

10.7.2CORBA IDL

10.7.3DCOM IDL

11 Appendix B: The Role of RMIThis document lays out the API specifications for IMS systems at a core level. The IDL descriptions ofobjects and method calls at this level are meant to be sufficient for developing IMS systems based onCORBA or DCOM distributed object technologies. A subset of these objects and methods which areparticularly useful to developers of runtime applications who need to communicate with an IMS system toget information on resources, users and groups will be made available through RMI interfaces. This willincrease the availability of useful core services across different browser platforms that may not be able tosupport communication with either of the underlying CORBA or DCOM object technologies.

Many application level programmers may still find the IMS core interfaces intimidating with or withoutRMI interfaces. To meet the needs of these programmers we will be developing a set of higher applicationlevel APIs which use RMI indirectly but shield the user from the complexities of server lookup andbinding protocols. These object facades will organize and recast the underlying RMI server calls in waysthat make sense to content developers and users, exposing the most convenient calls and providingadditional services. An example of such a user convenient façade is the Resource Agent described in theProof of Concept Section of this document. The Resource Agent is a Java class that exposes the mostuseful methods and data of the prototype's Message Channel Manager and Coordinator. When it isinstantiated it makes an RMI connection to both the Message Channel Manager and the SystemCoordinator object from which it gathers information that is useful to the application at run time. Theapplication is unaware that RMI has been invoked and is running in the background.

The Proof of Concept Implementation has made use of RMI to:• provide convenient access to the IMS Message Channel• provide convenient access to the IMS Coordinator object to get information• on users, groups and resources• implement convenient façade objects for application level programming



The question arises, to what extent will RMI continue to be supported in the evolution of theSpecifications and reference implementation? The answer is that:

• The prototype API in general will be enhanced to harmonize with the developing Specifications andpublic comment.

• The revised Specifications will contain official RMI bindings.• The straightforward RMI bindings to the MessageChannel will remain much the same, with

extensions to support a Notification layer and the more elaborate form of Message objects.• The RMI bindings to the IMS Coordinator will be deprecated in subsequent releases of the prototype.

Services provided by the Coordinator will now be performed by calls to methods on the Resourceobject itself.

• The façade objects such as the Messenger and Resource Agent will almost certainly come under closescrutiny and be redesigned to reflect changing design, best practices and user critiques. Developersshould not rely on continued support for the method APIs in these façade objects, however convenient.They should use RMI calls directly which are less subject to change.

In summary application developers may feel reasonably confident in using the APIs described in theChannel Manager RMI Interface section of this document but should use the Messenger, Message, andResource Agent objects guardedly in anticipation of possible deprecations as the prototype is revised inaccordance with the evolving specifications.


11.1.2CORBA IDL

11.1.3DCOM IDL

%XLOGLQJ�D�0LJUDWLRQ�3DWK�IURP�$,&&�%DVHG�&RPSXWHU�%DVHG�7UDLQLQJ�WR,QWHUQHW�EDVHG�,QVWUXFWLRQDO�0DQDJHPHQW

7KH�,QWHUQHW�FUHDWHV�D�FRPPRQ�QHWZRUN�LQIUDVWUXFWXUH�OLQNLQJ�WUDLQLQJ�RUJDQL]DWLRQV�ZRUNSODFHV��VFKRROV��FROOHJHV�DQG�SXEOLVKHUV�DQG�PDNLQJ�LW�HDVLHU�WR�GLVWULEXWH�WUDLQLQJ�WRWKH�ZRUNSODFH��WR�GUDZ�RQ�PXOWLSOH�UHVRXUFHV�LQ�EXLOGLQJ�WUDLQLQJ�PDWHULDOV��DQG�WR�PHUJHWUDLQLQJ�ZLWK�MXVW�LQ�WLPH�SHUIRUPDQFH�VXSSRUW�

7KH�,06�SURMHFW��KWWS��ZZZ�LPVSURMHFW�RUJ��D�QRQSURILW�LQGXVWU\�FRRSHUDWLYH��LVDGGUHVVLQJ�WKHVH�RSSRUWXQLWLHV�WKURXJK�WHFKQLFDO�VSHFLILFDWLRQV�IRU�LQWHURSHUDELOLW\��7RDVVXUH�WKDW�DOO�FXVWRPHUV�DQG�YHQGRUV�RI�WUDLQLQJ�WHFKQRORJ\�FDQ�WDNH�DGYDQWDJH�RI�WKHVHRSSRUWXQLWLHV��WKH�,06�SURMHFW�LV�FUHDWLQJ�D�PLJUDWLRQ�SDWK�IRU�FXUUHQW�SURGXFWV�DQGSURSRVLQJ�H[WHQVLRQV�WR�H[LVWLQJ�LQWHURSHUDELOLW\�VWDQGDUGV�VR�HVWDEOLVKHG�SURGXFWV�WDNHIXOO�DGYDQWDJH�RI�WKH�,QWHUQHW��,Q�SDUWLFXODU��WKH�$YLDWLRQ�,QGXVWU\�&%7�&RPPLWWHH��$,&&�KDV�HVWDEOLVKHG�DQ�LPSRUWDQW�VSHFLILFDWLRQ�IRU�FRPSXWHU�EDVHG�WUDLQLQJ��&%7��LQ�LWVJXLGHOLQHV�DQG�UHFRPPHQGDWLRQV�IRU��FRXUVH�VWUXFWXUH��DQG��WUDFNLQJ��ZKLFK�DOORZ�$,&&FRQWHQW�DQG�PDQDJHPHQW�V\VWHPV�WR�LQWHURSHUDWH��$,&&�KDV�GHYHORSHG�WUDFNLQJVSHFLILFDWLRQ�IRU�/$1�EDVHG�DQG��PRUH�UHFHQWO\��,QWHUQHW�EDVHG�FRQWHQW�

%HIRUH�RXWOLQLQJ�DQ�DSSURDFK�WR�PLJUDWLQJ�WKH�DYLDWLRQ�LQGXVWU\�FRQWHQW�DQG�V\VWHPV��LW�LVLPSRUWDQW�WR�RXWOLQH�VRPH�PDMRU�QHZ�UHTXLUHPHQWV�WKDW�WKH�,QWHUQHW�RSSRUWXQLWLHV�EULQJ�WRWKH�IRUHIURQW��7KH�IROORZLQJ�DUH�DPRQJ�WKH�UHTXLUHPHQWV�EHLQJ�DGGUHVVHG�E\�WKH�,06SURMHFW��Ã�

&RPSUHKHQVLYH�VHFXULW\�ZKLFK�LV�DGHTXDWH�IRU�RSHUDWLQJ�SULYDWH�WUDLQLQJ�VHVVLRQV�RYHUWKH�RSHQ�,QWHUQHW�ZLWKRXW�WKH�WUDLQLQJ�FRQWHQW��DGPLQLVWUDWLYH�LQWHUDFWLRQV��WKHLGHQWLW\�RI�WKH�SDUWLFLSDQWV�RU�WKHLU�SHUIRUPDQFH�EHLQJ�FRPSURPLVHG��Ã�(QWHUSULVH�LQWHJUDWLRQ�RI�WUDLQLQJ�ZLWK�OLEUDULHV�RI�SHUIRUPDQFH�UHODWHG�LQIRUPDWLRQ�VWXGHQW�UHFRUG�DGPLQLVWUDWLRQ��DQG�HOHFWURQLF�FRPPHUFH�IXQFWLRQV��Ã�)OH[LEOH�GLVWULEXWLRQ�RI�FRQWHQW�LQ�IRUPV�VXLWDEOH�IRU�NQRZOHGJH�PDQDJHPHQW�DQGMXVW�LQ�WLPH�OHDUQLQJ�0HWD�GDWD�ZKLFK�LV�D�ODEHOLQJ�V\VWHP�IRU�OHDUQLQJ�REMHFWV�LQ�,QWHUQHW�EDVHGUHSRVLWRULHV��Ã�3RUWDEOH�SURILOH�LQIRUPDWLRQ�PDNLQJ�LW�SRVVLEOH�IRU�VWXGHQWV�WR�WDNH�WKHLU�FHUWLILFDWLRQVZLWK�WKHP�DV�WKH\�PRYH�IURP�IRUPDO�WUDLQLQJ�WR�ZRUNSODFH�SHUIRUPDQFH�VXSSRUWV\VWHPV��Ã�,QWHURSHUDELOLW\�DPRQJ�WUDLQLQJ��KLJKHU�HGXFDWLRQ��KRPH�EDVHG�OHDUQLQJ��DQG�RWKHUOHDUQLQJ�VHWWLQJV�VXFK�DV�.��VFKRROV��$V�WKH�,QWHUQHW�OLQNV�PXOWLSOH�VHWWLQJV�SXEOLVKHUV�DUH�ORRNLQJ�WR�H[SDQG�WKHLU�PDUNHWV�ZKLOH�WUDLQLQJ�RUJDQL]DWLRQV�KRSH�WRWDS�LQWR�FRQWHQW�GHYHORSHG�IRU�KLJKHU�HGXFDWLRQ�DQG�RWKHU�QRQ�WUDGLWLRQDO�WUDLQLQJVHWWLQJV��Ã�,QWHJUDWLRQ�RI�FROODERUDWLRQ�DQG�FRPPXQLFDWLRQ�ZLWK�DFFHVV�WR�FRQWHQW��WKXVVXSSRUWLQJ�D�EURDGHU�UDQJH�RI�OHDUQLQJ�VW\OHV�DQG�SHGDJRJLHV�WKDQ�FDQ�EHDFFRPPRGDWHG�WKURXJK�WUDGLWLRQDO�&0,�PRGHOV�

7KHVH�UHTXLUHPHQWV�SRLQW�WR�WKH�QHHG�IRU�DQ�H[WHQVLEOH�DUFKLWHFWXUH�WKDW�ZLOO�HQFRPSDVVPDQ\�VSHFLILF�LPSOHPHQWDWLRQV��&RQVLVWHQW�ZLWK�WKH�0HPRUDQGXP�RI�8QGHUVWDQGLQJEHWZHHQ�WKH�$,&&�DQG�,06��WKH�,06�SURMHFW�KDV�VHW�DV�D�UHTXLUHPHQW�WKDW�$,&&�FRQWHQWVKRXOG�UHSUHVHQW�D�SDUWLFXODU�LPSOHPHQWDWLRQ�RI�,06�FRQWHQW�DQG�EH��SOD\DEOH��RQ�QHZLQVWUXFWLRQDO�PDQDJHPHQW�V\VWHPV�WKDW�PHHW�WKH�EURDGHU�UHTXLUHPHQWV�IRU�RSHUDWLQJ�RQ

��RI�� $0

%XLOGLQJ�D�0LJUDWLRQ�3DWK�IURP�$,&��QHW�EDVHG�,QVWUXFWLRQDO�0DQDJHPHQW KWWS��ZZZ�LPVSURMHFW�RUJ�DLFF�LPVPLJUDWLRQ��KWPO

WKH�,QWHUQHW��7KH�WUDLQLQJ�LQGXVWU\�DV�D�ZKROH�ZLOO�EHQHILW�LI�WKH�$,&&�DSSURDFK�LV�LQFOXGHGZLWKLQ�D�EURDGHU�VHW�RI�VWDQGDUGV�DLPHG�DW�WDNLQJ�IXOO�DGYDQWDJH�RI�WKH�:RUOG�:LGH�:HEDQG�HPHUJLQJ�FRPSRQHQW�DQG�,QWHUQHW�WHFKQRORJLHV��:RUNLQJ�ZLWK�WKH�YHQGRUV�RI�$,&&V\VWHPV��WKH�,06�SURMHFW�KDV�GHYHORSHG�D�WZR�SKDVH�VWUDWHJ\�IRU�DGGUHVVLQJ�WKLVUHTXLUHPHQW�

7KH�ILUVW�SKDVH�RI�WKH�VWUDWHJ\�UHTXLUHV�QR�FKDQJH�WR�$,&&�FRQWHQW��7KH�,06�SURMHFW�ZLOOZRUN�ZLWK�WKH�WRRO�YHQGRUV��ZKLFK�VXSSRUW�$,&&�VSHFLILFDWLRQV��WR�GHYHORS�VSHFLILFDWLRQV�IRUUXQQLQJ�$,&&�FRQWHQW�RQ�,06�FRQIRUPLQJ�LQVWUXFWLRQDO�PDQDJHPHQW�V\VWHPV��7KH�SOD\HUZLOO�FRQYHUW�FRXUVH�VWUXFWXUH��WUDFNLQJ�DQG�VHTXHQFLQJ�LQIRUPDWLRQ�EHWZHHQ�WKH�FXUUHQW$,&&�IRUPDWV�DQG�WKH�,06�IRUPDWV��ZKLFK�XVH�;0/�DQG�SURJUDPDWLF�LQWHUIDFHV��,06�ZLOOPDNH�WKHVH�VSHFLILFDWLRQV�SXEOLFO\�DYDLODEOH�VR�WKDW�DQ\�YHQGRU�GHYHORSLQJ�D�QHZPDQDJHPHQW�WRRO�ZLOO�EH�DEOH�WR�KDQGOH�H[LVWLQJ�$,&&�ZHE�SOD\DEOH�FRQWHQW��7KLV�DSSURDFKZLOO�DOORZ�,06�PDQDJHPHQW�V\VWHPV�WR�WDNH�IXOO�DGYDQWDJH�RI�WKH�SURYHQ�PRGHO�GHYHORSHGE\�$,&&�IRU�GHSOR\LQJ�&%7��0DQDJHPHQW��6\VWHPV�ZLWK�WKHVH�IHDWXUHV�DUH�H[SHFWHG�WRDSSHDU�LQ�WKH�PDUNHWSODFH�LQ�HDUO\��

,Q�WKH�VHFRQG�SKDVH�RI�WKH�VWUDWHJ\��YHQGRUV�RI�$,&&�DXWKRULQJ�DQG�PDQDJHPHQW�V\VWHPVZLOO�PRGLI\�WKHLU�SURGXFWV�WR�XVH�WKH�;0/�VSHFLILFDWLRQV�DQG�SURJUDPDWLF�LQWHUIDFHV�XVHG�LQSKDVH��LQ�WKH�SOD\HU��:LWK�WKLV�FKDQJH��WKH�SOD\HU�ZLOO�QRW�EH�QHHGHG�WR�UXQ�WKH�FRQWHQWZLWK�DQ�,06�FRQIRUPLQJ�PDQDJHPHQW�V\VWHP��$Q�H[WHQVLRQ�RI�WKH�$,&&�VSHFLILFDWLRQV�ZLOOEH�QHHGHG�WR�DGGUHVV�WKLV�DSSURDFK��,QGXVWU\�VXSSRUW�H[LVWV�IRU�DXWKRULQJ�DQGPDQDJHPHQW�SURGXFWV�EXLOW�WR�WKLV�VSHFLILFDWLRQ�WR�DSSHDU�LQ��

%\�DGGUHVVLQJ�WKH�LVVXHV�RI�PLJUDWLRQ�RI�$,&&��WKH�LQGXVWU\�FDQ�WDNH�DGYDQWDJH�RI�WKH�IXOOVWUHQJWKV�RI�WKH�,QWHUQHW��KDQGOH�QHZ�UHTXLUHPHQWV�VXFK�DV�VHFXULW\��DQG�FRQWLQXH�WR�WDNHDGYDQWDJH�RI�H[LVWLQJ�OLEUDULHV�RI�FRXUVHZDUH�DV�ZHOO�DV�VRIWZDUH�DQG�SHRSOH�VNLOOV�IRUFRXUVHZDUH�DXWKRULQJ��7KLV�PLJUDWLRQ�SDWK�UHSUHVHQWV�DQ�LQFOXVLYH�VWUDWHJ\�WKDW�DVVXUHVZLGH�LQGXVWU\�FRRSHUDWLRQ�DQG�DYRLGV�WKH�GHYHORSPHQW�RI�PXOWLSOH�FRPSHWLQJ�VWDQGDUGV�LQWKLV�DUHD�

��RI�� $0

%XLOGLQJ�D�0LJUDWLRQ�3DWK�IURP�$,&��QHW�EDVHG�,QVWUXFWLRQDO�0DQDJHPHQW KWWS��ZZZ�LPVSURMHFW�RUJ�DLFF�LPVPLJUDWLRQ��KWPO

IMS Project - instructional media + magic

Documents

Transcript of IMS Project - instructional media + magic