REGISTER  |  SIGN IN
United States Patent Application20020073236
Kind CodeA1
Helgeson, Christopher S. ; et al.June 13, 2002
Method and apparatus for managing data exchange among systems in a network
Abstract
The present invention provides a solution to the needs described above through a system and method for managing data exchange among systems in a network. The systems and methods of the present invention translate data from a system specific local format to a generic interchange format object, and vice versa, with predefined stylesheets using generic components and a system specific service components which utilize a native application programming interface of the specific local system.
Inventors:Helgeson; Christopher S. (Mountain View, CA), Lipkin; Daniel S.  (Belmont, CA), Larson; Robert S.  (Redwood City, CA), Panuganti; Srinivas  (Sunnyvale, CA)
Correspondence Name and Address:425 Market Street
Morrison & Foerster LLP
San Francisco
CA
94105-2482
US
Series Code:759678
Filed:January 12, 2001
U.S. Current Class:709/246; 709/217
U.S. Class at Publication:709/246; 709/217
Intern'l Class:G06F 015/16
Claims

1. A method for managing data exchange between systems connected via a network, comprising: creating a plurality of predefined stylesheets, each said stylesheet of said plurality of stylesheets describing a mapping between a system specific local format and a generic interchange format; receiving a data object from a first system in a first system specific local format; translating said data object from a first system specific local format to a generic interchange format object with said predefined stylesheets using a system specific service component which utilizes a native application programming interface of said first system; translating said data object from said generic interchange format to a second system specific local format object with said predefined stylesheets using a system specific service component which utilizes a native application programming interface of said second system; and transferring said translated data object to said second system.

2. The method of claim 1, wherein said step of receiving a data object from a first system in a first system specific local format comprises: receiving a request to export a data object from a first system; identifying a local data object identifier utilizing a mapper component; identifying a document type utilizing a mapper component; identifying a stylesheet and transformer using said document type; and extracting said data object from said first system.

3. The method of claim 2, further comprising converting said local data object identifier to a platform object identifier.

4. The method of claim 1, wherein said step of translating said data object from said generic interchange format to a second system specific local format object with said predefined stylesheets using a system specific service component which utilizes a native application programming interface of said second system comprises: receiving a request to import a data object to a second system; receiving a data object in a generic interchange format, a document type, and a platform object identifier; identifying a stylesheet and transformer using said document type; and translating said data object from said generic interchange format to a second system specific local format object with said stylesheet using a system specific service component which utilizes a native application programming interface of said second system.

5. The method of claim 4, further comprising: scanning for foreign platform object identifiers; and resolving said foreign platoforn object identifiers to a local identifier.

6. The method of claim 1, further comprising returning a local identifier for said data object transferred to said second system.

7. The method of claim 1, further comprising the step: monitoring a first system for changes to a data object at said first system

8. The method of claim 1, wherein said step of receiving a data object from a first system in a first system specific local format comprises extracting said data object from said first system with a system specific service component which utilizes a native programming interface of said first system.

9. The method of claim 1, wherein said step of transferring said translated data object may be performed using a plurality of communication protocols.

10. The method of claim 1, wherein said stylesheet is an xsl stylesheet.

11. The method of claim 1, wherein said data objects are in xml format.

12. The method of claim 1, wherein said step of translating said data object from a first system specific local format to a generic interchange format object with said predefined stylesheets using a system specific service component which utilizes a native application programming interface of said first system comprises: translating said data object into a serialized local XML representation; and translating said serialized local XML representation to a generic interchange format utilizing a predefined stylesheet.

13. The method of claim 1, wherein said step of translating said data object from said generic interchange format to a second system specific local format object with said predefined stylesheets using a system specific service component which utilizes a native application programming interface of said second system comprises: mapping said data object in generic interchange format to one or more objects required to be transferred to said second system; and translating said generic interchange format data into said second system specific local format using a predefined stylesheet.

14. An apparatus for managing data exchange between systems connected via a network, comprising: a network interface; memory storing data and programs of instructions; a processor coupled to the memory which executes the programs of instructions and accesses the stored data, wherein the programs of instructions comprise: a first translator component for translating a data object from a first system specific local format to a generic interchange format object, said first component comprising: a system independent service subcomponent; and a system specific service component utilizing a native API of said first system to translate said data object to a generic interchange format object using a predefined stylesheet; a second translator component for translating said data object from said generic interchange format to a second system specific local format object, said second component comprising: a system independent service subcomponent; and a system specific service component utilizing a native API of said first system to translate said data object from a generic interchange format object to a second system specific local format object using a predefined stylesheet; and a delivery component for transferring said data object between said first and second system.

15. The apparatus of claim 14, wherein said programs of instructions further comprise: a monitor component for monitoring changes of a data object at a first system, said monitor component comprising: a system independent service subcomponent; and a system specific service component utilizing a native API of said first system to monitor changes of said data object at said first system;

16. The apparatus of claim 14, wherein said programs of instructions further comprise a mapper component for identifying a local object identifier and a document type.

17. The apparatus of claim 14, wherein said delivery component for transferring said data object between said first and second system utilizes a pluggable communication protocol.

18. The apparatus of claim 17, wherein said pluggable communication protocol comprises TCP/IP Sockets.

19. The apparatus of claim 17, wherein said pluggable communication protocol comprises HTTP.

20. The apparatus of claim 17, wherein said pluggable communication protocol comprises SMTP.

21. The apparatus of claim 17, wherein said pluggable communication protocol comprises database logging tables.

22. The apparatus of claim 14, wherein said predefined stylesheet is an xsl stylesheet.

23. The apparatus of claim 14, wherein said data objects are in xml format.
Description


RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 60/176,084 filed Jan. 14, 2000. This application is also related to the following utility applications which are filed on the same day as this application:

[0002] Ser. No. ______ Filed ______, titled "A Method and Apparatus for a Business Server";

[0003] Ser. No. ______ Filed ______, titled "A Method and Apparatus for a Web Content Platform";

[0004] Ser. No. ______ Filed ______, titled "A Method and Apparatus for an Information Server.";

[0005] Ser. No. ______ Filed ______, titled "A Method and Apparatus for Managing Data Exchange Among Systems in a Network"; and

[0006] Ser. No. ______ Filed ______, titled "A Method and Apparatus for an Improved Security System Mechanism in a Business Applications Management System platform".

COPYRIGHT NOTICE

[0007] A portion of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

TECHNICAL FIELD

[0008] The present invention relates to the general field of computers, telecommunications, and computer and Internet related systems. More specifically the invention relates to systems and processes to be used in a business systems platform generally used to integrate disparate business applications systems in an efficient manner, across multiple hardware platforms.

BACKGROUND

[0009] The Internet and other communications networks provide a mechanism for communication and transfer of data between a wide variety of systems and platforms. There is a need for a system for managing the exchange of data and information among applications which may be housed on disparate hardware platforms and in diverse locations. Moreover, there is a need for a system that provides standardized access to connectivity with other systems and platforms in a users network.

[0010] Prior art systems of this type typically have an infrastructure which is tightly coupled to application products, specific hardware platforms and specific Operating systems and related services. Such systems are difficult to maintain, difficult to upgrade and difficult to extend to other applications as well as usually requiring redundant data input for their specific applications. In the past, developers have turned to object-oriented programming (OOP) to improve programming and code maintenance efficiency for such systems and to the use of hardware platform independent languages like Sun Microsystems.TM. JAVA.TM. language and system, as tools for developing such platform independent applications support systems. Until recently, the use of Java has been focused on the client side of the client-server system architecture with the development of JavaBeans.TM. and Java servelet generation. More recently, the technology required to allow distributed objects to communicate with each other across either the client-server or server-server boundary has been provided by the EnterpriseJavaBeans (EJB).TM. component architecture. This new architectural system and related tools and systems are well documented and well known to those skilled in these arts.

[0011] Attempts continue to be made to employ these new systems and architectures in the process of building generic applications systems platforms, in an attempt to make the applications platform independent of a given hardware and software platform, and to make them easier to use by developers and end-users. For example, U.S. Pat. No. 6,125,363 issued on Sep. 26, 2000 to Eugene Buzzeo et al provides an object-oriented, multi-threaded application development system and method for developing resource information software, wherein a three tier framework (web client and web browser--web server--application server) is disclosed. The system disclosed uses JAVA objects as connectors, components, agents, event servers, common objects with which to build applications for database related applications which are hardware platform independent. The system described in this Patent tries to solve the problems of distributed object communications through the use of the Common Object Request Broker Architecture (CORBA) and the InternetInterORB Protocol (IIOP). Such platform independent languages, tools and sub-systems, while ostensibly making it easy for applications developers to create new business applications, nevertheless present an overwhelming technical problem for a user with a need for an efficient, integrated business system. A system using one framework is unable to transfer data to a different framework, as systems implementing one framework will have a different application programming interface API than the application programming interface API of another system.

[0012] Accordingly, there is a need in the art for a modular interconnect system containing data import, export and event monitoring and reporting facilities which are protocol independent of related applications. There is a need for an interconnect system which implements a generic connector framework with pluggable system specific components utilizing native application programming interfaces of systems to manage export and import of data from external systems. There is also a need for such an interconnect system utilizing XML, and there is a need for reliable monitoring mechanisms for changes to data in external systems. The current invention provides these facilities and others in various new and novel ways as more fully described below.

SUMMARY OF THE INVENTION

[0013] The present invention presents a method for managing data exchange among systems connected via a network. A plurality of predefined stylesheets are generated, with each stylesheet describing a mapping between a system specific local format and a generic interchange format. A data object is received from a first system in a first system specific local format. This data object is translated from the first system specific local format to a generic interchange format object with the predefined stylesheets using a system specific service component which utilizes a native application programming interface of said first system. The data object is then translated from the generic interchange format to a second system specific local format object with the predefined stylesheets using a system specific service component which utilizes a native application programming interface of said second system. The translated data object is then transferred to the second system.

[0014] In one embodiment of the invention, the step of receiving a data object from a first system in a first system specific local format includes receiving a request to export a data object from a first system, identifying a local data object identifier utilizing a mapper component, identifying a document type utilizing a mapper component, identifying a stylesheet and transformer using said document type, and extracting the data object from the first system.

[0015] The present invention presents a system for managing data exchange among a plurality of systems connected via a network. The system comprises a network interface, memory storing data and programs of instructions, and a processor coupled to the memory which executes the programs of instrucitons and accesses the stored data. The programs of instructions comprise a first component for translating a data object from a first system specific local format to a generic interchange format object, a second component for translating the data object from the generic interchange format to a second system specific local format object, and a third component for transferring the data object between the first and second system. The first component further comprises a system independent service subcomponent and a system specific service subcomponent utilizing a native API of said first system to translate said data object to a generic interchange format object using a predefined stylesheet. The second component further comprises a system independent service subcomponent and a system specific service subcomponent utilizing a native APi of said first system to translate said data object from a generic interchange format object to a second system specific local format object using a predefined stylesheet.

[0016] The system may also include a monitor component for monitoring changes of a data object at a system, with the monitoring component having both a system independent service subcomponent and a system specific service component utilizing a native API of the monitored system to monitor changes of the data object. The system may also include a mapper component for identifying a local object identifier and a document type.

[0017] Still other embodiments of the present invention will become apparent to those skilled in the art from the following detailed description, wherein is shown and described only the embodiments of the invention by way of illustration of the best modes contemplated for carrying out the invention. As will be realized, the invention is capable of modification in various obvious aspects, all without departing from the spirit and scope of the present invention. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not restrictive.

DESCRIPTION OF THE DRAWINGS

[0018] The features and advantages of the system and method of the present invention will be apparent from the following description in which:

[0019] FIG. 1 illustrates a typical configuration of Internet connected systems representative of the preferred embodiment of the present invention.

[0020] FIG. 2 illustrates a typical general purpose computer system of the type representative of the preferred embodiment.

[0021] FIG. 3 illustrates the general three tier relationship between user, web-servers and their related applications-server, and the database management system.

[0022] FIG. 4 illustrates a more detailed depiction of the applications-server portion of such a system as shown in FIG. 3
illustrating the business applications platform system of the present invention.

[0023] FIG. 5 illustrates an alternative configuration of the system which contains the invention.

[0024] FIG. 6 is an alternative depiction of the platform of the present invention.

[0025] FIG. 7 illustrates a more detailed configuration of an exemplary business server portion of the current invention.

[0026] FIG. 8A illustrates a more detailed configuration of an exemplary Web Content Server portion of the current invention.

[0027] FIG. 8B shows a process flow diagram illustrating how to produce dynamic web content.

[0028] FIG. 8C shows a process flow diagram illustrating the page development process.

[0029] FIG. 9 illustrates a preferred embodiment of the Interconnect Backbone.

[0030] FIG. 10 shows a process flow diagram illustrating a purchase order delivered from a Source site to a target system through Interconnect.

[0031] FIG. 11 illustrates one embodiment of the structural overview of an IDK.

[0032] FIG. 12 illustrates one embodiment of a functional overview of an Information Distributor.

[0033] FIG. 13 illustrates an exemplary view of APIs associated with the Information Distributor.

[0034] FIG. 14 illustrates an exemplary view of using Information Distributor or IDK.

[0035] FIG. 15 illustrates an exemplary overview of Query Objects.

[0036] FIG. 16 illustrates an exemplary overview of the Implement Custom Delivery Service.

[0037] FIG. 17 illustrates a preferred embodiment of the Business Applications Management System Platform.

DETAILED DESCRIPTION

[0038] The present invention provides a solution to the needs described above through a system and method for integrating the disparate applications, and managing the applications processes in a hardware resource and user effort efficient manner. The automated system of the present invention uses a business systems platform architecture comprised of several unique servers in a base platform (the "Platform") to efficiently manage multiple applications which may themselves generally be distributed across a network. The platform makes use of a collection of Core Services which provide additional security, internationalization services, and reporting services which are applicable to all applications. The Core Services are made available to a multitude of common business objects, which themselves are made available to various applications.

[0039] The present invention is a Business Applications Management System Platform Architecture (the "Platform" or alternatively the "SABA architecture") which is designed to maintain and use a set of unique servers and common objects to generate the set of tasks required to be performed to complete a designated business transaction in a concrete, and useful way. In the preferred embodiment, the platform permits application developers to work on the business aspects of the application without having to focus on transaction management, security, persistence of data or life cycle management of the object itself. The servers and other aspects of the Platform are described in more detail below. However, a general overview of a preferred embodiment of the invention is first described.

[0040] (1) General Overview

[0041] The technology used as part of the system currently is, and will be, able to interface with many other industry standard software programs to make the exchange and flow of data easy and accurate.

[0042] The system is predominantly web-enabled, which extends its use to all industry professionals connected to the Internet. The Platform provides a unified set of interfaces, an application Framework, that encompass Business Object development, Web-application development, external connectivity development, and information distribution development.

[0043] The system is predominantly based on object-oriented programming principles is described in "Object-Oriented Software Construction" by Bertrand Meyer, Prentiss-Hall, 1988, ISBN 0-13-629049-3 and the Sun Microsystems.TM. developed JAVA.TM. systems described in the following publications:

[0044] Enterprise JavaBeans Specification, v1.1 (can be found at java.sun.com/products/ejb/docs.html)

[0045] Enterprise JavaBeans, Richard Monson-Haefel, O'Reilly.

[0046] Enterprise JavaBeans: Developing Component-Based Distributed Applications, Tom Valesky, Addison-Wesley.

[0047] Enterprise JavaBeans Developer's Guide (Beta Version) at

[0048] //developer.java.sun.com/developer/earlyAccess/j2sdkee/doc-beta/gui- des/ejb/html/TOC.html

[0049] J2EE Application Programming Model (Beta Release), at //developerjava.sun.com/developer/earlyAccess/j2sdkee/download-docs.html

[0050] all of which are incorporated fully herein by reference. The system makes use of some third party modules which are described in more detail below also. The terminology as used and described in these references for object, class, inheritance, component, container, bean, JavaBean, EJB, etc., are well known in these arts and are used herein generally without definition except where a specific meaning is assigned to a term herein.

[0051] Overview of the Platform Architecture

[0052] The following describes an overview of the preferred embodiment of the SABA architecture, and includes:

[0053] A discussion of the system-level architecture and the modules that comprise the SABA system. This includes a high-level overview of each module, and lists the principle interfaces and functionality defined by each module.

[0054] A discussion of the application-level architecture, covering both the application-level architecture as exposed to different categories of users and some of the core business objects and their relationships.

[0055] Referring now to FIG. 5, in the preferred embodiment, Saba's architecture consists of four layers of APIs:

[0056] 1. The Platform layer 501 provides underlying infrastructure for enterprise applications, including standards-based functionality for persistence and distributed logic, application integration, content generation, and metadata queries.

[0057] 2. The Core Services layer 503 is a module that provides a set of common functionality for enterprise application. It includes services such as security, internationalization, and reporting.

[0058] 3. The Common Business Objects layer 505 is a module that defines a set of business objects shared across all SABA applications. It includes objects such as Party and Plan. Vertical applications may each also contribute a set of common business objects.

[0059] 4. The Applications layer 507 provides objects and services particular to a given application. There are multiple modules contained within the Applications layer, including modules for Learning 525, Content 527, Performance 529, and Sales & Marketing 531. The specific applications modules indicated are shown by way of example.

[0060] In the preferred embodiment, applicants have standardized their APIs around Session Bean Managers, interfaces that expose a common set of functionality. Each module therefore consists of several Session Bean interfaces. Thus, while SABA implements its managers using Entity Beans corresponding to persistent database objects, the interface as exposed to clients is solely that of the Managers.

[0061] This architecture also helps avoid circular dependencies by requiring that all dependencies be directed downwards. That is, a vertical application 507 may have dependencies on one or more sets of common business objects 505, but not on other applications. Similarly, common business objects 505 may depend on core services 503, and on other common business objects 505, but not on applications 507.

[0062] Platform

[0063] The Platform model 501 defines applicants' application platform, on top of which all additional business logic and functionality are implemented. Platform 501 provides the full set of standards-based services required for building modem enterprise applications.

[0064] Platform 501 consists of the following services:

[0065] BDK (Business Development Kit) Business applications server 519 is Saba's EJB compatibility layer. It extends the standard Java business component model with SABA-specific enhancements, such as improved security and caching, as well as providing an abstraction layer to improve portability between EJB servers. The BDK 519 defines the following base interfaces:

[0066] ISabaEntityBean--The abstraction of a persistent object

[0067] ISabaSessionBean--The abstraction of a transactional service

[0068] WDK (Web Development Kit) server 523 is Saba's web content generation engine. Using web standards for XML and XSL, it provides a customizable framework for decoupling data from presentation, and generating web content in a variety of formats, from standard HTML to WML. The WDK 523 provides the following base interfaces:

[0069] IWDKObject--An object capable of serializing itself as XML

[0070] Interconnect is Saba's application integration platform. Using XML and open standards for ERP integration, it provides a scalable and reliable solution for batch and period import, export, and monitoring. Interconnect defines the following base interfaces:

[0071] IAccessor--Service for exporting objects from SABA

[0072] IImporter--Service for importing objects into SABA

[0073] IMonitor--Service for monitoring object changes

[0074] Information Distributor Server 521 is applicants' query and delivery mechanism. Based on XML and RDF metadata standards, it defines a high-level query language and a set of agents for implementing information services. Interconnect provides the following services:

[0075] MetadataRepository--A datastore for querying metadata

[0076] ImportAgent--An agent for generating metadata

[0077] MatchAgent--An agent for locating metadata-based matches

[0078] DeliveryAgent--An agent for delivering match results

[0079] Core Services 503

[0080] The Core Services module 503 provides the common business services needed by applicants' system. These services are not specific to any industry, such as learning; instead, they provide the support and functionality required by applicants to meet generic enterprise requirements.

[0081] Core Services consist of the following Session Managers:

[0082] AuditManager--Tracks changes to objects in the system. Can return a complete history of changes, including date, username, and reason.

[0083] BusinessRuleManager--Manage system business rules, that is, company policies defining the system's behavior in given situations.

[0084] ComponentManager--Manage installed business objects for naming and instantiation.

[0085] CurrencyManager--Manage currencies and exchange rates.

[0086] DataDictionaryManager--Manage metadata about business objects. This metadata is used to generate user interfaces, specify constraints, and define object behavior.

[0087] DomainManager--Manage domains. Domains are hierarchical groupings of business objects that can be used for a variety of purposes.

[0088] FinderManager--Create and invoke Finders. Finders provide a flexible mechanism for defining and executing database queries.

[0089] HandleManager--Centralize access to managers available to all business objects.

[0090] i18nManager--Manage internationalization. Track information about locales, languages, timezones, and display formats associated with business objects.

[0091] LicenseManager--Manage software licensing. Track installed modules, license keys, and version numbers.

[0092] LOVManager--Define lists of values.

[0093] NLevelHierarchyManager--Support for nested folders.

[0094] FolderManager

[0095] FolderElementManager

[0096] NoteManager--Define notes (long text attachments).

[0097] PreferenceManager--Set user preferences.

[0098] SecurityManager--Manage user privileges. Assign permitted operations on objects to users and groups.

[0099] ServiceHolderManager--Enable and disable common services (discussion, chat, etc.)

[0100] ReportManager--Create and execute reports. Reporting engines currently supported include Brio and Crystal Reports 7.

[0101] LetterManager--Generate form letters.

[0102] TaxManager--Calculate sales taxes.

[0103] NotificationManager--Manage notifications. Associate actions, such as sending an email or executing a Java method, with predefined system and periodic events.

[0104] ActionManager

[0105] AttachmentManager

[0106] EventManager

[0107] ParamManager

[0108] RecepientManager

[0109] TextBlockManager

[0110] UserManager--Manage user preferences and allow used to switch between roles.

[0111] Common Business Objects

[0112] The Common Business Objects module 505 defines the set of business abstractions that are shared across more than one vertical application. These objects may be either generic business concepts, such as a Party, or shared concepts specific to Saba's application domain, such as Calendar.

[0113] Common Business Objects 505 comprise the following Session Managers:

[0114] AccountabilityManager--Used to manage a variety of relationships, such as reporting and organization membership, between entities in the system

[0115] CalendarManager--Manage calendars and schedules.

[0116] CorporateCalendarManager

[0117] PersonalCalendarManager

[0118] SfaCalendarManager

[0119] SfaCalendarOwnerManager

[0120] CheckListItemManager

[0121] PartyManager--Manage entities within a business. Includes employees, clients, companies, departments, and business units.

[0122] LocationManager--Manage locations, including addresses and contact information.

[0123] RoleManager--Manage a function/job type within the value chain.

[0124] PlanManager--Manage plans, that is, proposed course of actions.

[0125] ProfileManager--Manage profiles, that is, comprehensive histories, goals, and plans for entities within a business.

[0126] ValueChainManager--Manage value chain relationships between entities in an extended organization.

[0127] Learning

[0128] The exemplary Learning module 525 within the Applications layer 507
defines the services used to build learning management systems. It provides APIs for defining learning offerings, which include classes, courses, on-line learning, and physical inventory, registering for and consuming learning, and tracking transcripts, certifications, and other results of learning.

[0129] The following Learning Session Managers are delivered as part of Common Business Objects 505:

[0130] CatalogManager--Browse a learning catalog.

[0131] OfferingTemplateManager--The core abstraction of a learning intervention.

[0132] The following Learning Session Managers are only available with the Learning application:

[0133] CertificationManager--Track certifications.

[0134] CertificationActionManager

[0135] CertificationCompetencyManager

[0136] HeldCertificationManager

[0137] LearningManager--Manage learning offerings. Extends the concept of offering templates to include managing delivery types and delivery modes, offering instances, audience types, and offering modes.

[0138] AudienceTypeManager

[0139] DeliveryManager

[0140] DeliveryModeManager

[0141] EquivalentManager--Defines equivalent offering templates.

[0142] OfferingActionManager

[0143] OfferingManager

[0144] OfferingPolicyManager

[0145] OfferingTemplateDeliveryManager

[0146] ProductGroupManager

[0147] RosterManager

[0148] PrerequisiteManager

[0149] LearningResourceManager--Manage resources used by classes, such as classrooms, faculty, and equipment.

[0150] InventoryManager

[0151] QualifiedInstructorManager

[0152] RegistrarManager--Request and order a learning resource. Includes shipping and registration information.

[0153] CourseRequestManager

[0154] PackageOrderManager

[0155] PricingManager

[0156] RegistrationManager--Track completion and grading of learning offerings

[0157] Content

[0158] The Content module 527 within the Applications layer 507 defines the services used for all forms on on-line learning. It includes creating and launching WBT and VOD courseware, virtual classrooms, testing and assessment, community services, and analysis and tracking.

[0159] The following Content Session Manager is delivered as part of Common Business Objects:

[0160] ContentHolderManager--Allows any business object to be a content holder

[0161] CourseContentManager--Associate content such as attachments and exams with learning offerings.

[0162] The following Content Session Managers are only available with the Content application:

[0163] ContentManager--Manage learning content.

[0164] TestManager

[0165] AnalysisManager--Analyze test results.

[0166] CommunityManager--Create and manage learning communities.

[0167] Performance

[0168] The Performance module 529 within the Applications layer 507
defines the services available for managing human performance. It includes competencies and goals.

[0169] The following Performance Session Managers are delivered as part of Common Business Objects:

[0170] CompetencyManager--Assign competencies to roles, entities, and learning resources. Includes

[0171] CompetencyHolderManager

[0172] CompetencyProviderManager

[0173] OfferingCompetencyManager--Associate competencies with offering templates and find learning interventions that provide competencies.

[0174] The following Performance Session Managers are only available with the Performance application:

[0175] Advanced competency definition, manipulation, and analysis, including:

[0176] CompetencyAnalysisManager

[0177] CompetencyGroupManager

[0178] CompetencyMethodManager

[0179] CompetencyModelManager

[0180] GoalManager--Manage and track goals. Includes assigning goals and observations on goals.

[0181] GoalLibraryManager

[0182] GoalObservationManager

[0183] GoalStateManager

[0184] Sales and Marketing

[0185] The Sales and Marketing module 531 within the Applications layer 507 defines the services available for the running the finances and logistics of a learning content provider. It includes the purchase of learning resources and tools for managing sales and marketing campaigns.

[0186] The following Sales and Marketing Session Managers are delivered as part of Common Business Objects:

[0187] OrderManager--Generate orders. Includes invoicing and shipping options.

[0188] PurchaseManager--Track the pricing of learning resources. Includes getting and setting prices and managing price lists.

[0189] The following Sales and Marketing Session Managers are only available with the Sales and Marketing application:

[0190] AccountManager--Manage client accounts.

[0191] Advanced order management, including:

[0192] TrainingUnitManager

[0193] PurchaseOrderManager

[0194] MarketingManager--Manage marketing campaigns.

[0195] RoyaltyInfoManager

[0196] ShipperManager

[0197] SalesMktManager--Order a learning resource. Similar functionality to RegistrarManager, but designed for use in a call center to fulfill external orders.

[0198] TargetMarketManager--Manage target markets and associate them with offering templates.

[0199] TerritoryManager--Manage territories.

[0200] Applications Architecture

[0201] An exemplary version of an application architecture which can make use of applicants' invention could consist of four distinct applications that interoperate to provide a complete Human Capital Development and Management solution. Each of these applications is based around a core set of metadata; the applicants' architecture's value lies in the effective management of this metadata. The diagram in FIG. 6 describes this core metadata and how it is employed by different types of users in this exemplary implementation of this architecture. Those skilled in the art will recognize that this architecture can be used with various other kinds of applications systems, such as: financial product sales & marketing systems; retail store management systems; various kinds of maintenance & repair management & dispatch systems; etc.

[0202] Referring now to FIG. 6, SABA Learning manages Catalog Metadata 609
that describes a set of available learning interventions and Profile Metadata 611 that describes a learner in the system, including learning history and enrollments.

[0203] SABA Performance manages Profile Metadata 611 that describes individual and group goals, competencies, and development plans. Together, the Profile Metadata 611 in Learning 607 and Performance 605
provide a complete description of the human capital in an extended organization.

[0204] SABA Information 603 and SABA Content 601 manage metadata about a variety of on-line resources. SABA Information 603 uses this metadata to construct information services targeted to individual's information needs, whereas SABA Content 601 uses this metadata to manage learning content throughout its lifecycle and construct intelligent, reusable Learning Objects.

[0205] Users work with this metadata as follows:

[0206] Individual learners 619 query Learning Metadata (that is, the learning catalog) 609 to locate appropriate learning interventions. The system uses Learning Object Metadata 613 to deliver and track learning interventions and updates the Profile Metadata 611 as appropriate.

[0207] Team managers 621 work with Profile Metadata 611 to define, update, and track progress towards goals. They can analyze the metadata to identify problem areas and generate plans for meeting their goals.

[0208] Learning providers 617 use import and administration tools to create and update Catalog 609 and Learning Object Metadata 613.

[0209] One of the principal tasks users perform in such a system is finding performance interventions--resources and services that can be applied to improve human capital performance. The diagram in FIG. 7
details the business objects that support this process and their relationships.

[0210] There are multiple, complementary mechanisms for identifying interventions.

[0211] Competency gap analysis can be applied to either an individual's goals 713 or roles 715. The analysis compares the required competencies for reaching a goal 713 or filling a role 715 (either held or targeted) to actual held competencies and generates a competency gap 721. Learning interventions (offerings 723) that fill the competency gap 721 are the identified. A variety of other intervention types are planned, including information 733 and community services 735.

[0212] Certification gap 719 analysis compares a role's certification requirements associated to the actual learning profile of the individual in the role. It then identifies the quickest certification track to completion and recommends appropriate learning offerings 723 from the catalog.

[0213] Having described an exemplary application we now describe the invention in additional context.

[0214] In a preferred embodiment, the Platform can support both Application and Business component development, as well as integration with development tools, connectivity to external systems (import/export/exchange), and information delivery. The architecture of the present invention adopts a three-tier model and is shown in the diagram in FIG. 3. In FIG. 3 a tier 1 web user 301 is connected electronically to a tier 2 web server 305 which is connected to a tier 3
applications server 307. Also in Tier 1 a dedicated user 311 may be directly connected to a tier 3 applications server 307. And the tier 3
applications server 307 may be connected to a database management system 309.

[0215] Referring now to FIG. 4, the tier 3 applications server 307 is expanded in FIG. 4 to illustrate the Business Applications Platform 415
of the present invention. In FIG. 4, the Platform contains an Interface Server 417, an Information Server 419, an Interconnect Server 423 and a Business Server 421. All of these Servers 417, 419, 421 and 423 may physically resign on the same hardware platform (such as a UNIX box or a Microsoft.TM. NT.TM. platform), or each server may reside on a separate hardware box, or any combination of servers and hardware boxes. Each of the servers may have included a JAVA Virtual Machine.TM. and the related runtime support. The electronic communications between these servers may use the XML protocol (409, 425, 427) with each server having services for translating XML into the particular Applications Programming Interface (API) language required by the server and for translating its internal language into XML prior to transmission to another server. In a preferred embodiment, all of these servers are contained in a single tier 3
platform, and may communicate with each other directly without the necessity of changing the interfacing protocol format. The Interface Server 417 (also alternatively designated herein as the WDK), communicates through a web server 405 via the internet 403 to web clients 401 via the HTML protocol. The Interface Server 417, also may communicate to a directly connected client 407 via other protocols such as XSL/XSLT etc., and may communicate to Personal Data Assistants 411 such as cell phones or Palm Pilots.TM. or other such wireless devices using wireless protocols such as WAP/WML, etc. The Interface Server 417, contains mechanisms to manipulate various kinds of display style sheets, to generate and execute web links, to manage dynamic content generation and dynamic generation of Javascript, all of which is described in more detail below in the section on the Interface Server/WDK 417.

[0216] These servers and related facilities and others are described in more detail below.

Operating Environment

[0217] The environment in which the present invention is used encompasses the use of general purpose computers as client or input machines for use by business users of various kinds, including clerks, managers, teachers, and/or systems administrators. Such client or input machines may be coupled to the Internet (sometimes referred to as the "Web") through telecommunications channels which may include wireless devices and systems as well.

[0218] Some of the elements of a typical Internet network configuration arc shown in FIG. 1, wherein a number of client machines 105 possibly in a branch office of a large enterprise, a manufacturer, a financial enterprise, etc., are shown connected to a Gateway/hub/tunnel-server/etc. 106 which is itself connected to the internet 107 via some internet service provider (ISP) connection 108. Also shown are other possible clients 101, 103 possibly used by other application systems users, or interested parties, similarly connected to the internet 107 via an ISP connection 104, with these units communicating to possibly a home office via an ISP connection 109 to a gateway/tunnel-server 110 which is connected 111 to various enterprise application servers 112, 113, 114
which could be connected through another hub/router 115 to various local clients 116, 117, 118. Any of these servers 112, 113, 114 could function as a server of the present invention, as more fully described below. Any user situated at any of these client machines would normally have to be an authorized user of the system as described more fully below.

[0219] An embodiment of the Business Applications Platform System of the present invention can operate on a general purpose computer unit which typically includes generally the elements shown in FIG. 2. The general purpose system 201 includes a motherboard 203 having thereon an input/output ("I/O") section 205, one or more central processing units ("CPU") 207, and a memory section 209 which may or may not have a flash memory card 211 related to it. The I/O section 205 is connected to a keyboard 226, other similar general purpose computer units 225, 215, a disk storage unit 223 and a CD-ROM drive unit 217. The CD-ROM drive unit 217 can read a CD-ROM medium 219 which typically contains programs 221
and other data. Such programmed computers may also be connected electronically to database systems such as those available from Oracle.TM., Sybase.TM., Informix.TM., SQLServer from Microsoft.TM. and the like. Logic circuits or other components of these programmed computers will perform series of specifically identified operations dictated by computer programs as described more fully below.

[0220] Detailed System Description

[0221] The Platform system of the present invention is now described in more detail. In general a preferred embodiment with a presently known best mode for making and using the system is described. Alternative embodiments are similarly described for various parts of the Platform system.

[0222] Business Applications Server/BDK

[0223] Preferred Embodiment

[0224] The following description of the BDK Business application server covers the presently preferred embodiment and the presently known best mode for making and using it. This section is followed by a further description of an alternative embodiment which may include features in addition to or in place of those in the preferred embodiment.

[0225] 1. Overview

[0226] The Business Development Kit applications server (BDK) component of the Platform provides a supporting framework for business objects. A business object is a Java object with persistent state that represents some entity in a business application, such as an employee or company.

[0227] Specifically, the BDK provides a persistence framework for saving and restoring object state and a set of core services for performing a variety of useful operations on business objects.

[0228] 2. Persistence Framework

[0229] The persistence framework defines a common code path used to create new objects, restore and update existing objects, delete objects, and find objects. The code path consists of a set of Java code and database stored procedures to construct and verify object data and SQL commands to save and restore information using a relational database.

[0230] The persistence framework is highly flexible because it is metadata-driven. For each class of object, the system provides a set of metadata--data about data--that defines the class' properties and behavior. This means that the data used to determine the behavior and characteristics of specific classes and instances of business objects is stored as distinct, editable information, rather than being hard-coded into the logic of the system. The persistence code itself is part of the metadata, that is, the SQL commands for save, restore, etc. are stored as metadata, not in source code. As an example benefit, it makes applications much easier to port between databases because only the metadata for the SQL needs to be changed; no source code needs to be changed and recompiled.

[0231] Use of metadata allows the system to be configured and otherwise modified by different clients for different deployments, resulting in unique runtime behavior of the system. Object properties that can be customized range from the labels used to display object information, to the type of data validation performed, to the amount of custom information associated with each object.

[0232] A unique feature of the persistence framework is its support for an arbitrary amount of custom information, stored in what is known as "custom fields." Experience has shown that predefined business objects typically do not express the full set of data a given customer may wish to track, and that this data varies from customer to customer. Custom fields provide a way for different customers to uniquely extend the data stored with a class of business objects. In the current implementation, customers are provided with a set of five "custom fields" that can be searched, and an unlimited number of "extended custom fields" that cannot be searched, but provide additional data validation for date and numeric values. Again, the code to save and restore custom fields is all driven off metadata.

[0233] As an example of the persistence framework's operation, a user of the system may attempt to create a new employee by specifying the employee's first and last name, social security number, starting salary, and date of birth. The persistence framework performs the following operations to save this data as a new "SabaPerson" business object:

[0234] Uses metadata settings about the "first name", "last name", "ssn", and "birth date" properties of a "SabaPerson" to determine the data validation to perform. In this case, the metadata settings may instruct the framework to verify that values are provided for first name, last name, and ssn, that starting salary is greater than a fixed numeric minimum wage value, and that birth date is a valid date.

[0235] Uses metadata to obtain and execute a database stored procedure named "tpp_person_ins" that takes values for first name, last name, ssn, salary, and birth date as parameters and inserts these values into a database table named "tpt_person."

[0236] 2a. The Meta-data Store

[0237] In the preferred embodiment the meta-data store contains the definition of each type of object in the system, its attributes, and some basic properties of those attributes. Further, for each type of object, it contains a reference to the methods to invoke, to insert, update, delete or fetch a given instance of that object from the persistent store.

[0238] The Metadata store consists of the following tables:

[0239] 1. fgt_dd_class

[0240] Every business object in the system is registered in this table. This table also describes basic properties of objects.

[0241] fgt_dd_class has the following columns:

1
Column Name Type Rq? Description Id Char (20) The identifier of the object. Ui_name Varchar2 This is the display name of (255) the object and generally used to paint UI as well. Description Varchar2 Meaningful description of the (255) object and its function. Enumber int Unique number for each object. Insert_spid Int Method call for inserting a new instance of the object. Foreign key to mesg_id column of fgt_mesg_table. Update_spid Int Method call for updating an existing instance of the object. Foreign key to mesg_id column of fgt_mesg_table. Delete_spid Int Method call for deleting an instance of the object. Foreign key to mesg_id column of fgt_mesg_table. Sel_det_spid Int Method call for retrieving an instance of the object based on its id. Foreign key to mesg_id column of fgt_mesg_table. Finder_id Int Finder Id for invoking a default finder associated with the object. Fixed_attr_ct Int Total count of the fixed attributes for the object. Attr_ct Int Total count of the attributes for the object. This number is sum of all fixed and all custom attributes. Flags Char (10) Ten bit string describes the behavior of the object. 1st bit = Object can be displayed in the security screen for granting privs. 2nd bit = This 2bit mask is set to see if reports or letters or both can be attached. 3.sup.rd bit = Obsolete. 4.sup.th bit = Obsolete. 5.sup.th bit = If the object is owned in nature and cannot exist without its owner. 6.sup.th bit = Obsolete 7.sup.th bit = If object can be customized bu end user. 8.sup.th bit = If Object can have Extensible attributes of its own. next_attr_enum Int Enumber to use for the next custom attribute that will be added to the object. The install time value for this attribute is 10,000. Prefix char (5) This 5letter long string is used in generating Ids for the object. This string is prepended to the number generated by the sequence. Table_name Varchar2 This is the name where the (25) object is stored. The sequence, methods are also named based on this. Domain_enum int This is denormalized data and shows the enumber of the Domain attribute. Java_class_nam Varchar2 The java class name of the e (255) object. Hlevel Int The level of the object in the object hierarchy. Parent_id Char (20) In case of hierarchical object's it stores the parent object's id

[0242] As an example, the following are the values for a class of business object representing domains:

2
id ui_name description enumber insert_spid ddcls000000 Domain Hierarchal 195 10560
000001095 Domain update_spid delete_spid sel_det_spid finder_id fixed_attr_ct 10562 10561 10563 15710 14
next_attr_enu attr_ct flags m prefix table_name 14 1100001100 100000
domin fgt_domain domain_enum java_class_name hlevel parent_id com.saba.busobj.Sa 1
baDomain

[0243] 2. fgt_dd_attr

[0244] The attributes of each class of business object is stored in this table. This table also describes basic properties of each attribute.

[0245] fgt_dd_attr has the following columns:

3
Column Name Type Rq? Description Id Char (20) Y Unique identifier for an attribute. Cid OBJECTID Y The object id, this attribute belongs to Enumber Int Y Required to be unique within a class. The code should use these numbers to refer to attributes rather than using the ID. Fixed enumbers are assigned in the range 1000- 9999. Extensible attributes are allocated from 10,000
onwards. The next_attr_enum in the corresponding object record stores the next enumber available for this class. Col_name Varchar (25 Y The column name in which the 5) value of this attribute is stored. Ui_name Varchar (255) Y The name of the attribute, which is used for painting the UI. description Varchar (255) N Description of the attribute. Attr_type Int Y The number corresponds to the data type of the attribute. list_of_vals OBJECTID N If the attribute val. is selected from a list of values, then the id of the list is stored here. min_val Int N If its a numeric column, then the min allowable value if any. max_val Int N If its a numeric column, then the max allowable value if any. default_val STR N Default value to use for the attribute when an instance of the object is created. str_1 STR N This generation formula for those attributes whose values have to be generated on the creation of the object. The generation is driven by the generation bit in the flag. Flags varchar (15) Y 1.sup.st bit => The required bit. 2.sup.nd bit => Reference bit is set if attribute points to another object. 3.sup.rd bit => LOV bit is set if its values must come from fixed list of values. 4th bit => This two bit mask describes the type of the attribute. 5th bit => Id bit is set if its an Id column. 6th bit => Generation bit is set if the value need to be generated during the creation of an object. 7th bit => Customization bit. This 4bit mask says if label, required or generation can be customized by end user. 8th bit => Audit bit. 9th bit => Obsolete 10th bit => Obsolete 11.sup.th bit => This bit describes the type of the custom attribute. 12.sup.th bit => Domain bit is set if the attribute is domain id. 13.sup.th bit => set if Default value can be changed by user. 14.sup.th bit => set if Minimum value can be changed by user. 15.sup.th bit => set if Maximum value can be changed by user.

[0246] As an example, the following are some of the attributes defined for the domain business object:

4
id cid enumber col_name ui_name attr_type flags ddatr000 ddc1s0 1000 id ID 8 100011000
0000000 00000
000000
02991 00000
1095
ddatr000 ddc1s0 1001
time_stamp Time Stamp 4 100000000
0000000 00000 000000
02992 00000
1095
ddatr000 ddc1s0 1002 name Domain Name 4
100000100
0000000 00000 Name 000100
02993 00000
1095
ddatr000 ddc1s0 1003 description Description 7 000000300
0000000 00000 000100
02994 00000
1095
ddatr000 ddc1s0 1004 custom0 custom0 7 000100300
0000000 00000
010100
02995 00000
1095

[0247] 3. fgt_mesg_table

[0248] This table stores the actual SQL code used for object persistence. In the case of insert, update, and delete methods, typically these are calls to stored procedures containing additional business logic in addition to database calls.

[0249] Long SQL statements are stored in multiple rows, which are then reconstructed on-the-fly by the persistence layer.

[0250] fgt_mesg_table has the following columns:

5
Column Name Type Rq? Description Mesg_id Int Y This is the message id for the SQL statement group. Mesg_seq Int Y Since the SQL statements can be greater than 255 chars which is the length of the mesg_text columns. This column tells the sequence of this SQL statement in the group. Mesg_text Varchar Y The text of message. (255)

[0251] As an example, the following are persistence calls for the domain business object. Note from the sample data above that 10563 is the code for retrieving an object, 10560 for inserting an object, and 10562 for updating an object.

6
mesg_id mesg_seq mesg_text 10563 1 select d.id id, d.time_stamp ts, d.name dname, d.description descr, d.custom0 c0, d.custom1 c1, d.custom2 c2, d.custom3 c3, d.custom4 c4, d.created_on cron, d.created_by crby, d.updated_on upon, d.upd 10563 2 ated_by upby, d.parent_id pid, parent.name parent from fgt_domain d, fgt_domain parent where d.id = @001 and d.parent_id = parent.id(+) 10560 1 begin fgp_domain_ins (@001, @002, @003, @004, @005, @006, @007, @008, @009, @010, @011, @012, @013, @014, @015); end; 10562 1
begin fgp_domain_upd (@001, @002, @003, @004, @005, @006, @007, @008, @009, @010, @011, @012, @013, @014, @015); end;

[0252] Notice that the SQL references the actual table used to store domain data, fgt_domain (described in detail in the section on security).

[0253] The fgp_domain_ins stored procedure is PL/SQL code defined as:

7
create or replace procedure fgp_domain_ins ( xid char, xtime_stamp varchar2, xname varchar2, xdescription varchar2, xcustom0 varchar2, xcustom1
varchar2, xcustom2 varchar2, xcustom3 varchar2, xcustom4 varchar2, xcreated_on date, xcreated_by varchar2, xupdated_on date, xupdated_by varchar2, xparent_id char, xnewts varchar2
) as begin /* validating that the parent of a node is not itself */ if (xid = xparent_id) then raise_application_error(-20698, "); return; end if; /* parent_id cannot be null except for the root */ if (xid <> `domin000000000000001` and xparent_id is null) then raise_application_error(-20699, "); return; end if; insert into fgt_domain ( id, time_stamp, name, ci_name, description, custom0, custom1, custom2, custom3, custom4, created_on, created_by, updated_on, updated_by, parent_id) values ( xid, xnewts, xname, lower(xname), xdescription, xcustom0, xcustom1, xcustom2, xcustom3, xcustom4, sysdate, xcreated_by, sysdate, xupdated_by, xparent_id); /* update the denormalized flat tree table */ tpp_flat_tree_relation(195, xid, null, null, 0); /* inherit a snapshot of the custom fields for all objects */ insert into fgt_dd_domain_to_attr (ID, TIME_STAMP, DOMAIN_ID, ATTR_ID, FLAGS, LOCAL_FLAGS, UI_NAME, MIN_VAL, MAX_VAL, DEFAULT_VAL, LIST_OF_VALS, GEN_MASK) select `ddoat`.vertline..vertline. lpad(ltrim(rtrim(to_char(fgt_dd_domain- _to_attr_seq.nextval))), 15, `0`), xnewts, xid, ATTR_ID, FLAGS, LOCAL_FLAGS, UI_NAME, MIN_VAL, MAX_VAL, DEFAULT_VAL, LIST_OF_VALS, GEN_MASK from fgt_dd_domain_to_attr where domain_id = xparent_id; end;

[0254] 2b. Persistence Algorithms

[0255] In a preferred embodiment all business objects that Saba's Application server manipulates are derived from a single base class called SabaObject. The SabaObject class provides save, restore, and delete capabilities by implementing the persistence layer architecture. All subclasses of SabaObject then inherit this behavior and rarely if ever override it.

[0256] Every SabaObject is expected to know which class it belongs to, and how that class is registered in the meta-data store. Thus each subclass of SabaObject stores a class identifier so that it can tell the system which entry in the meta-data store it corresponds to.

[0257] Every SabaObject also stores a state flag that determines whether this is a new object, or it is an object that already exists in the data store. This state then determines whether the object invokes an insert method or an update method during a saveo invocation.

[0258] Every SabaObject has an unchangeable, unique identifier that identifies that particular object in the persistence store. The uniqueness of this identifier is guaranteed across the entire persistence store regardless of the type of object.

[0259] The algorithm for save is then as follows:

[0260] Look up the entry for the class of the object in the meta-data store.

[0261] If the class is notfound, raise an error "Unknown Class".

[0262] If (State=new)

[0263] M=look up the method to call for inserting the object.

[0264] Else /* State =update */

[0265] M=look up the method to call for updating the object

[0266] Marshall all the attributes of the SabaObject into the appropriate data structure.

[0267] Check each of the attributes against the rules set for its nullity, constraints. If any of the constraints are violated, throw an error.

[0268] Lead the default values wherever necessary.

[0269] Invoke M with that data structure. (1)

[0270] For deletion, the basic process is identical, except that the invocation of the delete method only requires the unique identifier of the SabaObject to be passed in as its only argument.

[0271] For restore, the algorithm is just slightly different and is as follows:

[0272] Look up the entry for the class of the object in the meta-data store.

[0273] If the class is notfound, raise an error "Unknown Class".

[0274] M=look up the method to call for fetching the object.

[0275] Invoke M(unique ID of SabaObject)

[0276] Unmarshall all the attributes returned by M (2)

[0277] In the presently preferred embodiment, the method invocation currently only supports invocation of database stored procedures although in alternative embodiments this will be extended to other types of persistence mechanisms.

[0278] These stored procedures provide the actual intelligence of taking the marshaled arguments that come in, and storing them in specific fields in the database, and vice versa. Thus a combination of the meta-data store and the stored procedures create an abstraction layer that allows the base SabaObject to store all objects through a simple, uniform algorithm. 1

[0279] The persistence mechanism thus created allows the transfer of various kinds of objects to database storage as shown below. 2

[0280] Individual messages are retrieved using a SQL command of the form: select mesg_id, mesg_seq, mesg_text from fgt_mesg_table where mesg_id=? order by mesg_id, mesg_seq

[0281] Query results are transformed into actual SQL code using the following method:

8
private static String processMessage(ResultSet rSet) throws Exception, SabaException { StringBuffer buf; String str; buf = new StringBuffer (rSet.getString(kMsgTextCol)); while (rSet.next() != false) { String temp = rSet.getString(kMsgTextCol); buf.append (temp); } str = buf.toString(); return str; } } Retrieved messages are also stored in a local cache for improved performance.

[0282] 2c. Configurable Custom Fields

[0283] In the preferred embodiment, the Saba persistence mechanism provides built-in support for configurable, runtime definable, custom fields for any object.

[0284] The basic mechanism is extremely simple. An administrative user interface is provided by which the meta-data definition of a given class can be extended by adding (or removing) custom attributes as needed. For each custom attribute, the user only needs to provide some very basic information about the type of the field, whether or not it is required, constraining minimum and maximum values for numeric fields, and a constraining list if the field is to be validated against a list of possible values.

[0285] The SabaObject implementation then simply picks up these fields during its normal marshalling and unmarshalling of arguments. Further, the SabaObject also performs the basic checks for nullity as it would normally do.

[0286] To save and restore the custom fields, the actual algorithms are extended from the ones shown earlier. In the case of insert or update the following additional lines are called after the line marked (1) in the algorithm shown earlier:

[0287] After invoking the basic method M

[0288] Marshall all custom field data into the appropriate data structure

[0289] Invoke the insert/update method for storing the custom data structure.

[0290] In the case of restore, the following lines are added to the original algorithm after the line marked (2):

[0291] Invoke the custom field fetch

[0292] Unmarshall all custom field data and update the relevant fields in the SabaObject.

[0293] The actual storage where the custom field data for any given instance is stored, consists of a single table as defined below. All the custom field data is stored as tag-value pairs in typed columns.

[0294] Fgt_dd_custom

[0295] This common table provides the storage area for all data stored in the extended custom fields for a given object.

9
Column Name Type Rq? Description Id OBJECTID Y owner_id OBJECTID Y Which object this custom field is for. attr_id OBJECTID Y Refer to the attribute for which value is stored. attr_type INT Y Type of the custom field. This matches the attr_type in the fgt_dd_attr table and is a denormalization of the same. Num_value Number N Value is stored here if it is Numeric type Str_value Varchar (25 N Value is stored here if 5) it is String type Date_value Date N Value is stored here if it is Date type

[0296] 3 Core Services

[0297] BDK also provides a set of core services to perform useful operations on business objects. Some of these services include:

[0298] Security. BDK provides extremely fine-grained security control to control whether specific users have privileges to perform operations such as creating or viewing a particular class of business object. The system is unique in that it provides a flexible model of security roles and security lists to assign a set of privileges to distinct groups of users, and it employs a scalable notion of domains to differentiate among sets of business objects. The security model is explained in detail in a separate section below.

[0299] Auditing. BDK provides the ability to track the history of all changes to an object, including the date of a change, the identity of the user making the change, and a justification for the change.

[0300] Internationalization (i18n). BDK provides utilities for allowing business objects to be internationalized. Internationalization is a standardized process wherein message content, money amounts, dates and various other culture specific data are kept in separate files in order to permit an easy change from one countries language and cultural rules to another. This comprises both storing values of business objects in multiple languages and supporting multiple formats for date, currency, and other data types that vary among countries.

[0301] Concurrency. BDK provides concurrency services for controlling overlapping write operations on multiple instances of an object, while permitting multiple reads at the same time. This is achieved via comparison of an instance-specific timestamp when committing of an object's state to the persistent store is requested. The timestamp is updated whenever the state of an object is altered and the object is successfully committed to persistent storage.

[0302] Transaction Management. BDK provides two types of transactional services: procedural and declarative. In the former case, a developer explicitly marks the beginning and end of a unit-of-work using BDK's API. In the latter case, a developer can associate a transactional attribute with a method, and the BDK's Transaction Monitor keeps track of initiating and terminating transactions, as well as executing a method within the scope of an on-going transaction, based on run-time context.

[0303] Logging. BDK provides logging functionality that can be used for capturing system state and operations in one or more logs.

[0304] Notification. BDK provides the ability to send notifications, such as emails or faxes, to predefined categories of users when the state of identified business objects changes. For example, everyone subscribed to a class may receive a page if the class is cancelled.

[0305] Business Rules. In a preferred embodiment, for example, Saba's learning application provides a set of pre-defined business rules that affect the workflow and behavior of various business objects in the system. The BDK provides a mechanism to enable and disable these business rules. For example, a customer can configure whether a manager's approval is required to register for a class. Similar business rules can be handled for other types of applications.

[0306] Notes. BDK provides the ability to associate arbitrary, free-form text, or "notes," with any business object in the system.

[0307] 4 Application Programming Interfaces

[0308] In the preferred embodiment, the BDK exposes Application Programming Interfaces (APIs) for use in programming the system. A variety of APIs with equivalent functionality are supported on top of the persistence framework. The system supports both propriety and industry-standard forms of Java API, as well as XML-based APIs.

[0309] a. SabaObject API

[0310] One Java API is a proprietary "SabaObject" interface to a business object. A SabaObject is a Java class defining a set of operations common to all business objects, including the ability to get and set properties using a variety of data types and the ability to save and restore an object's state. Specific business object classes can subclass SabaObject to add functionality and business logic appropriate to that class.

[0311] The Java interface for SabaObject is the following:

10
public class SabaObject { /** * SabaObject Constructor * Creates a new empty Saba object in the context of the given session. */ public SabaObject(String sessionKey); /* methods to set attribute values as different datatypes */ public void setAttrVal(String attrName, Boolean attrVal); public void setAttrVal(String attrName, Timestamp attrVal); public void setAttrVal(String attrName, Integer attrVal); public void setAttrVal(String attrName, BigDecimal attrVal); public void setAttrVal(String attrName, String attrVal); public void setAttrVal(String attrName, Object attrVal); /* methods to restore attribute values as different datatypes */ public String getAttrVal(String attrName); public String getStringAttrVal(String attrName); public Integer getIntegerAttrVal(String attrName); public Timestamp getTimestampAttrVal(String attrName); public BigDecimal getBigDecimalAttrVal(String attrName); public Boolean getBooleanAttrVal(String attrName); /** * Gets a hashtable of the attribute values. */ public Hashtable getAttributeValues (); /** * Returns the display label for the named attribute */ public String getAttributeLabel( String attrName); /* save, restore, and delete methods */ public void save(); public void save(SabaTransaction tr); public void restore(); public void restore(SabaTransaction tr); public void delete(); }

[0312] In the preferred embodiment, as part of a business object's creation, the business object author provides four SQL statements corresponding to selection, deletion, insertion, and updating of the object. Pointers to these statements are provided as part of the metadata for the object as stored in fgt dd class. The first two (selection and deletion) types of statements take a single bind variable, namely, the id of the object. The other two take the id as well as all other attribute values in the order declared in the metadata for that object's attributes in the table fgt_dd_attr. The order of retrieval of attributes in the selection statement must also match such order.

[0313] Upon receiving a request to create an in-memory representation of an object through the "restore( )" method, BDK retrieves the selection statement for that class of objects, binds the variable to the id of the object that is desired to be restored, executes the statement, and fills in an instance-specific hashtable of attribute-value pairs with the values so retrieved. In addition, a standard SQL statement is executed to retrieve the value of extended custom attributes, and the results are again inserted in the aforementioned hashtable. For the "restore(SabaTransaction tr)" variant of this operation, the execution of these SQL statements is done using the database connection contained in tr, the transaction argument. When executing the "delete( )" method, the object is marked for deletion. Upon a subsequent call to "save( )" or "save(SabaTransaction tr)," BDK checks for the state of the object. If it is an object that has been marked for deletion, the deletion SQL statement as supplied by the business object author is executed after binding the id, using the database connection in the transaction argument for the "save(SabaTransaction tr)" case. Other possibilities upon execution of the save operation are that the object instance is new, or it is an altered state of an existing object. In these cases, the statements corresponding to insertion and updating are executed, respectively, after the replacing the bind variables with attribute values from the hashtable in the order specified in metadata. In the case of insertion, BDK automatically generates a unique id for the object that is reflected both in the persistent storage and the in-memory representation.

[0314] Implementation of the setAttrVal( ) and get<type>AttrVal( ) involve setting and accessing values in the hashtable, respectively, using the provided attribute name as the key. getAttributeValues( ) returns a copy of the object's hashtable whereas getAttributeLabel( ) looks up the attributes' metadata and returns the label corresponding to the chosen attribute.

[0315] 4b. SabaEntitvBean API

[0316] Another Java API is based on the industry-standard Enterprise JavaBean (EJB) model. This model has a notion of "entity beans" that provide the interface to specific business objects. Accordingly, the persistence framework provides a EJB-based abstract class, "SabaEntityBean" that implements the javax.ejb.EntityBean interface. The SabaEntityBean class provides default implementations of the following methods: ejbActivate( ), ejbPassivate( ), ejbRemove( ), setEntityContext( ), ejbCreate( ), ejbLoad( ), ejbStore( ), and unsetEntityContext( ). Implementations of the ejbLoad( ), ejbStore( ), ejbCreate, and ejbRemove( ) methods rely on the selection, update, insertion, and deletion statements declared as part of metadata (please refer to the discussion of the implementation of SabaObject's API). Other methods are implemented as empty stubs that can be overridden by a developer if desired.

[0317] In addition to defining the bean class, to implement an EJB one also needs to define a corresponding remote interface, a home interface, and, for entity beans, a primary key class. The remote interface is the external world's view of the bean and is comprised of the business methods that the bean wishes to expose. The getters and setters for the bean's attributes are also exposed through the remote interface. The home interface declares the life-cycle methods, such as those for creating, removing, or finding beans.

[0318] In the preferred embodiment, the BDK provides two interfaces, ISabaRemote and ISabaHome, which a bean can extend for defining remote and home interfaces, respectively. The ISabaRemote interface extends the standard EJB interface EJBObject and provides the following sets of methods:

[0319] void setCustomAttrVal(String attr, <type>value), and

[0320] <type>getCustomAttrVal(String attr)

[0321] for Boolean, Timestamp, String, Integer, Float, and Double data types. The ISabaHome interface provides a layer of abstraction over the standard EJB interface EJBHome. The BDK also defines a class SabaPrimaryKey (a thin wrapper around the String class) which can be used by entity beans for defining primary keys.

[0322] 4c. Session Manager APIs

[0323] The EJB model also has a notion of "session beans," higher-level interfaces that represent business processes. In the preferred embodiment, the BDK has standardized on the use of session bean-based interfaces as its public API; these interfaces are known as "session bean managers," and are implemented using the lower-level entity bean APIs provided by the persistence layer. The BDK provides a SabaSessionBean base class that defines common session bean manager functionality, and a framework for several categories of "helper classes"--additional interfaces used in conjunction with specific session bean managers:

[0324] Detail--represent immutable detail information about a specific business object

[0325] Handle--represent opaque references to a business object

[0326] Primitive--represent commonly used data structures, such as addresses and full names

[0327] 4d. XML Interfaces

[0328] In the preferred embodiment, the BDK also provides XML-based interfaces for saving and retrieving business objects; these interfaces provide the communication layer with the other Platform servers and components.

[0329] One XML format is known as "Saba Canonical Format" (SCF). It is an XML serialization of the data in a SabaObject. The Interconnect server system reads and writes SCF to implement the AccessorReader and ImporterWriter for the native Saba system; refer to the Interconnect server section for more details.

[0330] An example fragment of an SCF document, representing a business object defining a specific currency, is:

11
<SabaObject type="com.saba.busobj.SabaCurrency" id="crncy000000000000001" status="existing"> <name dt:type="string">US Dollars</name> <time_stamp dt:type="string">199812161647032900</time_stamp> <short_name dt:type="string">USD</short_name> <flags dt:type="string">1100000000</flags> </SabaObject>

[0331] In the preferred embodiment, another XML interface is the "IXMLObject" interface. An IXMLObject is a Java object capable of serializing itself into an XML representation. The detail, handle, and primitive helper objects used by session bean managers all implement this interface. The WDK server system uses these objects to generate dynamic web content by invoking the session bean manager APIs, then serializing the resulting objects into XML; refer to the WDK section for more details.

[0332] The IXMLObject interface conforms to the "Visitor" design pattern, and is defined as follows:

12
public interface IXMLObject { /** * Accept a visitor. An implementation should ask the Visitor to visit each of its public elements (i.e., fields or properties). * * @param visitor The XML Visitor object */ public void acceptXMLVisitor(IXMLVisitor visitor) throws XMLVisitorException; /** * Get the preferred tag name for this object. * @return the tag name to identify */ public String getTagName(); } Note: a "visitor" object is one which has processes which represent an operation to be performed on the elements of an object structure. A visitor lets one define a new operation without changing the classes of the elements on which it operates. Visitor objects and their operation and use are described in #more detail at pages 331-344 of Design Patterns, by Gamma, Helm, Johnson, & Vlissides, Addison-Wesley 1995, ISBN 0-201-63361-2 which are hereby fully incorporated herein by #reference. Those skilled in these arts will recognize that various other #implementations of these algorithms and concepts may be developed without departing from the spirit and functionality of this invention. Additional background information can be found in Enterprise JavaBeans Specification, v1.1 (can be found at url=java.sun.com/products/- ejb/ docs.html), and in other sections of the book titled Design Patterns, by Gamma, Helm, Johnson, & Vlissides, Addison-Wesley 1995, ISBN 0-201-63361-2 which are hereby fully incorporated herein by reference.

[0333] Alternative embodiment

[0334] An alternative embodiment of the BDK business applications server may be described as follows, using the context of how a developer and user would use this portion of the system. In an alternative embodiment, the developer's use is outlined in the context of a BDK development kit which would be provided by Applicants for use in developing applications which can run on the Platform and by way of indicating some details unique to the Platform through a description of a use of the Business Development Kit.

[0335] In the alternative embodiment, the Business Server embodies a development kit framework which provides a set of interfaces and classes in the form of Java packages, identifies certain services that developers can rely on, and defines an application development model. The framework relies extensively on the server-side component model espoused by Java, namely Enterprise JavaBeans (EJB) components. Selection of EJBs as the server-side component model is driven in part by the requirements of reliance on open standards and backward compatibility. Using EJBs also enables integration with other Java 2 Enterprise Edition (J2EE) technologies such as Java ServerPages (JSP) and servlets that one would intend to use for web applications development. Furthermore, a number of EJB-enabled application servers available in the marketplace could be used to deploy the components so developed.

[0336] In the alternative embodiment, the development kit classes and interfaces, the services, and the application development model are discussed in greater detail in the next three subsections.

[0337] Classes and Interfaces

[0338] The BDK interfaces and classes address the following needs.

[0339] 1. Provide an additional layer of abstraction (by writing wrappers around base Java classes) to provide a richer level of functionality needed by SABA applications and to allow future modifications with minimal impact on the client application code.

[0340] 2. Expedite component development by providing default implementations (that can be overridden) of certain required interfaces in EJB.

[0341] 3. Define certain interfaces that must be implemented by classes used for specific purposes (an example is that a class must implement a certain interface if its instances are used in a JSP page).

[0342] 4. Define certain classes that are necessary to provide basic services, such as data partitioning and logging, as well as utility classes for expedited application development.

[0343] 5. To the extent possible, eliminate application server dependencies in areas where the EJB Specification is currently not vendor independent.

[0344] In the alternative embodiment, the following discussion of is background for a discussion of the usage and types of EJBs within the context of the development kit described in more detail below.

[0345] Metadata Support

[0346] In the alternative embodiment, one of the facilities provided by the development framework is that characteristics of business objects can be varied across deployment. For example, for an attribute, one can optionally specify whether it has a required attribute, the list of values (LOVs) that the attribute can assume, its default value, and its minimum and maximum values. The values can be different across installations, as different customers have different requirements. To achieve this flexibility, metadata about the business objects and their attributes is captured in the system.

[0347] In the alternative embodiment, some of the metadata that is currently captured about a class or an attribute could be dynamically determined using the Java reflection API. Examples include the parent ID and attribute count for business objects and attribute type for an attribute. The Java reflection API provides classes Class and Field that can be used to retrieve such information. Furthermore, instead of building a hashtable-based infrastructure for storing and retrieving attribute values, one can use methods like set and get in the Field class to operate directly on the attributes, which are declared as member variables of the class.

[0348] The classes Class and Field by themselves, however, may not provide the rich functionality needed by certain applications. For instance, there is no way to indicate minimum and maximum values of an attribute in the Field class. Thus, what is needed is to create new classes that provide wrappers around Class and Field and capture the additional information. In the interest of consistency with previously used names while avoiding conflicts at the same time, two new classes maybe used: SabaPlatformClass (inherits from Class) and SabaPlatformAttribute (inherits from Field). In addition to the functionality provided by Class (e.g., for getting parent class), SabaPlatformClass provides for such additional functionality as domain-based attributes and getting fixed vs. extended custom attribute counts. Similarly, SabaPlatformAttribute provides functionality for LOVs, default value, and minimum and maximum values. (As we will discuss later, the classes SabaPlatformClass and SabaPlatformAttribute themselves are beans--or, entity beans to be more specific--in this alternative embodiment system.)

[0349] The classes SabaPlatformClass and SabaPlatformAttribute will not be used directly by users of business components (though developers of such components will use them). Typically, the user of these classes will be a class SabaPlatformObject. In some instances, SabaPlatformObject will make use of the functionality provided by these classes as part of an operation (e.g., when setting the value of an attribute, SabaPlatformObject will use SabaPlatformAttribute to determine the minimum and maximum value constraints). In other cases, SabaPlatformObject will delegate an operation directly to one of these classes (an example would be retrieving the superclass of an object). SabaPlatformObject implements a set of methods for getting and setting attribute values that provide a centralized point for capturing the logic for such things as auditing and constraint checking, and are used by subclasses of SabaPlatformObject.

[0350] In this alternative embodiment, a component user will not interact directly with even SabaPlatformObject. Instead, the component user will deal with a specialization of either a SabaEntityBean or a SabaSessionBean, which are discussed in the next subsection.

[0351] Beans

[0352] In the alternative embodiment, components based on Enterprise JavaBeans (EJBs) will be a basic building block for developing applications using the BDK. Below we provide a brief overview of EJBs. Those skilled in these arts will understand that various books and documents on the "java.sun.com" web site provide additional details on this subject. There are two types of EJBs:

[0353] 1. Entity Beans, and

[0354] 2. Session Beans.

[0355] Entity beans are used for modeling business data and behavior whereas session beans are used for modeling business processes. Examples of entity beans could be SabaClass (a training class, not a Java class), SabaPerson, and SabaRegistration. Entity beans typically would map to objects (tables) in the persistent data store. Behaviors associated with an entity bean typically would relate to changing the data in the bean.

[0356] An example of a session bean could be SabaRegistrar, which uses the entity beans mentioned above and encapsulates the business logic associated with certain tasks, such as registering for a class. Session beans are not persistent, though changes in data of certain entity beans or their creation or removal could result from the actions of a session bean. A session bean can be stateful or stateless. A stateful session bean maintains state information specific to the client using it, such that results of invocation of a method may depend upon the methods invoked earlier on the bean. (An example of a stateful session bean would be SabaShoppingCart, which would keep track of items in an order as they are being added, to be followed by either placement of the order or clearing of the cart.) This is typically done by storing client-specific data in instance variables of a bean, which are then used by the methods to accomplish their task. A stateless session bean does not maintain any state specific to a client. An example of a stateless session bean would be SabaTaxCalculator, which provides methods for computation of sales and other taxes.

[0357] In the alternative embodiment the development kit would provide two abstract base classes: SabaEntityBean and SabaSessionBean. (Whether a session bean is stateful or stateless is indicated in something called a deployment descriptor.) These classes implement the javax.ejb.EntityBean and javax.ejb.SessionBean interfaces, respectively. The intent is to provide a default implementation of certain required methods to enable rapid development of components, yet allow a component to override the default implementation of the methods it chooses. The SabaEntityBean class provides default implementations of the following methods: ejbActivate( ), ejbpassivate( ), ejbRemove( ), setEntityContext( ), ejbcreate( ), ejbLoad( ), ejbStore( ), and unsetEntityContext( ). Implementation of the ejbRemove( ) and ejbCreate( ) are discussed in the next subsection. The other methods in the list by default have an empty implementation. The SabaSessionBean class provides default (empty) implementations of the first four methods in the preceding list.sabaEntityBean inherits from SabaPlatformObject and provides attributes common to all the entity beans, (such as namespace) and has a method to XML( ) that ensures that all entity beans will provide an implementation for serializing their data to an XML representation. In other words, SabaEntitybean implements an interface ISabaXMLRenderable (explained later) and provides two convenience methods: findUsingRQL (String rql) and findUsingRQLURI (String URI) to locate specific entity beans using RQL. In addition to defining the bean class, to implement an EJB one also needs to define a corresponding remote interface, a home interface, and, for entity beans, a primary key class. The remote interface is the external world's view of the bean and is comprised of the business methods that the bean wishes to expose. The getters and setters for the bean's attributes are also exposed through the remote interface. A developer must implement these methods by calling the getAttrval( ) and setAttrVal( ) methods available in SabaPlatformObject to take advantage of services like constraint checking and auditing. The home interface declares the life-cycle methods, such as those for creating, removing, or finding beans.

[0358] The development kit provides two interfaces ISabaRemote and ISabaHome, which a bean can extend for defining remote and home interfaces, respectively. The ISabaRemote interface extends the standard EJB interface EJBObject and provides the following sets of methods:

[0359] void setCustomAttrVal(String attr, <type>value), and

[0360] <type>getCustomAttrVal(String attr)

[0361] for Boolean, Timestamp, String, Integer, Float, and Double data types. The ISabaHome interface provides a layer of abstraction over the standard EJB interface EJBHome. The BDK also defines a class SabaPrimaryKey (a thin wrapper around the string class) which can be used by entity beans for defining primary keys.

[0362] One final interface defined in the BDK for EJBs is ISabaXMLRenderable. This interface extends the java.io.Serializable interface and defines a single method, toXML( ). Only classes that implement this interface are eligible to act as return types of methods that are going to be invoked from a Java ServerPage.

[0363] In the alternative embodiment the BDK would come with a few prepackaged beans. One is a stateless session bean named SabaPlatformLogin that can be used to authenticate a user. Another is an entity bean named SabaNameSpace, which encapsulates characteristics of a namespace, including its place in the hierarchy and the list of users who have access to entity beans in that namespace. The namespace is used for data partitioning and security purposes.

[0364] Relationships

[0365] Another area in which the BDK provides support is relationships amongst entity beans. In an object model, relationships between different classes are arranged in four categories: inheritance, association, composition, and aggregation. During implementation, the inheritance relationship is captured by extending a subclass from a superclass. The other three types of relationships entail constraints between the classes being related. For instance, a composition relationship implies commonality of life span (i.e., destroying the "whole" should result in destruction of the "components") and an association relationship implies referential integrity constraints (i.e., creating an instance of a class which refers to a non-existent interface of another class is not permitted). In an alternative embodiment, such relationships can be captured through constraints in the database.

[0366] In the alternative embodiment, the BDK will provide a SabaRelationship class, that has attributes for the name of relationship, the type of relationship, the source class and attribute, and the destination class and attribute. The SabaRelationship class will encapsulate lifetime management constraints implicit in each of the different types of relationships. Thus, if an object is being removed and it is declared to have compositional relationship with some other objects, the SabaRelationship class will ensure the removal of the related objects. Similarly, when creating an object, the SabaRelatlonship class will ensure that referential integrity constraints are being satisfied. The SabaEntityBean class will delegate calls to the SabaRelationship class within its ejbRemove( ) and ejbCreate( ) methods. Any implementation that a component developer provides for these methods for a specific bean would have to call super. ejbRemove( ) or super. ejbCreate( ) as appropriate.

[0367] In the alternative embodiment, an attribute capturing the list of relationships (where each item in the list is of type SabaRelationship) will be defined in the SabaEntityBean class. By default (i.e., at SabaEntityBean level), the list will be defined to be empty. When component developers create an entity bean by extending SabaEntityBean, they will be able to declaratively specify relationships between the bean being created and the other beans in the system. Additional relationships may be added to existing beans too when a new bean is created.

[0368] In the alternative embodiment, besides lifetime management, the declared relationships could also be used for navigational purposes within the object model. As an example, consider a situation where the SabaRegistration bean is related to the SabaClass bean, which in turn is related to the SabaLocation bean. One would like to be able to retrieve attributes of the location (say, the map) of the class, given a registration. A new class, SabaCompositeRelationship will allow one to compose navigational paths in terms of basic SabaRelationship objects. Then, given a source object and the name (or id) of a composite relationship, the SabaCompositeRelationship class will be able to fetch the destination object(s).

[0369] Vendor-specific Wrappers

[0370] In the alternative embodiment, when some areas within the J2EE specifications are still not standardized and are left up to individual vendors for implementation, additional facilities will be needed. To prevent vendor-specific implementation details from migrating into SABA code, the BDK would provide a class SabaJ2EEvendor that provides a wrapper around vendor-specific implementations. SabaJ2EEVendor provides static methods that can be used to perform activities in a vendor-neutral fashion in SABA code. An example method in SabaJ2EEvendor is getInitialContext( ),which encapsulates the logic for getting an initial context (at present, the mechanism for this is vendor-dependent). To use a particular vendor's implementation of J2EE specifications, one will have to provide implementations of the methods in this class. By default, the BDK will provide implementations of this class for a few selected J2EE servers.

[0371] Miscellaneous Classes

[0372] In an alternative embodiment, in addition to the foregoing, the BDK also provides the following utility classes that can be useful for developing components: SabaProperties, DateUtil, FormatUtil, LocaleUtil, SystemUtil, and Timer. Also, the following exception classes are supported: SabaException,SabaSecurityException,SabaFatal-Exception, AttributeNotFoundException, and SabaRelationshipViolationException. For logging purposes, the BDK provides a SabaLog class and for debugging purposes, the BDK provides a SabaDebug class. The functionality provided by the foregoing classes is similar to that available currently.

[0373] The use of the various classes and interfaces discussed in this section is described in the "Application Development Model" section.

[0374] Services

[0375] A number of services are required by application developers to develop robust, flexible, and scalable systems. A number of these services are provided by the commercially available application servers that host the EJB components. In the following paragraphs we discuss the various services that an application developer can rely on and how these services might be used.

[0376] Distributed Components

[0377] One of the key ingredients for building scalable systems is the ability to distribute components. In the EJB model, different beans can be deployed on different computers transparently. Separation of interfaces from the implementation enables automated generation of stubs and skeletons that hide the details of network communications. A client application (or a bean that relies on another bean) (Subsequent references to a client application should be interpreted to be inclusive of beans that rely on other beans) uses a naming service to first locate the bean and then interact with it, thus making no assumptions about location of any given component.

[0378] Naming

[0379] As alluded to in the previous paragraph, before using a bean, it must first be located. All EJB application servers are required to provide Java Naming and Directory Service (JNDI) access for bean users. To use JNDI, a client application would typically first get an "initial context" (driven by properties such as where to find the EJB server, somewhat analogous to the JDBC connect string for locating a database), and then using the context, look up the home interface of the bean by its name. Using the home interface, the client can find a specific instance of a bean, create a new instance, or remove an instance. The naming service would be used and the interaction would be the same even if the bean instance is present locally (i.e., exists in the same Java Virtual Machine) instead of being deployed on a remote machine.

[0380] The JNDI naming mechanism also obviates the need for the SabaClassRegistry mechanism that is used at present. The client application looks for a bean by a name (say, Authentication). Any bean class that provides the implementation of the remote and home interfaces can be deployed against that name in the application server. Thus, at one installation, the default bean class SabaPlatformLogin can be deployed with a name of Authentication, whereas at some other installation, the bean class SabaLDAPLogin can be deployed with the same external name to use a different authentication logic.

[0381] Persistence

[0382] One of the benefits of using EJBs is that component developers do not have to worry about persistence of data, as the container hosting the (entity) beans can manage such persistence. Automatic persistence service provided by the application server enhances the productivity of bean developers, is more efficient at runtime, and allows the bean's definition to be independent of the type of data store used for persistence (e.g., a relational database or an object-oriented database). A component developer will be responsible for declaring part or all of the attributes of an entity bean as persistent in its deployment descriptor, and then mapping them to fields in a database at deployment time. The interface and mechanism of such mapping would depend upon the application server being used.

[0383] The bean is automatically saved to the persistent store when it is created by a client application using the create( ) method, and when the container decides to synchronize the bean's state with the database if the bean's data has been changed by the client application. The container's decision is based on such factors as transactions, concurrency, and resource management. The container will remove the data from persistent store when the remove( ) method is called by a client on an entity bean.

[0384] Concurrency

[0385] A component developer does not have to worry about concurrent access to an entity bean from multiple transactions (such as from several client applications). It is the responsibility of the container hosting the bean to ensure synchronization for entity objects. Indeed, use of the keyword synchronized is prohibited by the EJB Specification. Concurrent access for session beans is not meaningful, since by definition an instance of a stateful session bean can be used by only one client and stateless session beans do not maintain any data that needs to be shared.

[0386] Transactions

[0387] For transactions, an application developer has two options: 1) to explicitly demarcate the boundaries of a transaction, or 2) to use declarative transactional management available with EJBs. Use of declarative transactional management is cleaner and is strongly recommended. In this case, the level of granularity for managing transactions corresponds to methods in a bean. Instead of interleaving transaction boundaries within business logic, transactional attributes are separately declared in the bean's deployment descriptor (for a specific method, or as the bean's default) as one of the following six options: TX_NOT_SUPPORTED, TX_SUPPORTS, TX_REQUIRED, TX_REQUIRES_NEW, TX_MANDATORY, TX_BEAN_MANAGED. Details of these can be found in books on EJB.

[0388] Security

[0389] As discussed earlier, application developers can use a stateless session bean, SabaPlatformLogin, to authenticate a user. In the deployment descriptor for every bean, access control entries are defined which list the identities (users or roles) that are allowed to invoke a specific method (alternatively, an access control list can act as the default for all the methods in a bean). According to EJB Specification, each client application accessing an EJB object must have an associated java.security. Identity object (generally associated at login time). The general Security system used in the present invention was discussed in more detail above.

[0390] Read/Write/Arbitrary Privileges

[0391] Search

[0392] To locate an instance of an entity bean, each entity bean provides a method findByPrimaryKey( ) in its home interface. In addition, other finder methods (which must be named in accordance with the pattern find criterion>)can also be provided. With container-managed persistence, the container generates the implementations of such methods automatically at deployment time. The mapping of finder methods to the database is vendor-dependent at present, though a standardized syntax for the same is a goal of EJB 2.0 Specification effort. In the meantime, a developer can implement the finder methods in terms of findUsingRQL( ) and findUsingRQLURI( ) methods available in SabaEntityBean.

[0393] Logging & Debugging

[0394] A component may be used by multiple applications in an interleaving fashion.

[0395] An application could have components distributed over multiple computers--how to assemble a unified log--use a "log server" bean--heavy performance price, impacts debugging class too.

[0396] Turning on and off debugging on a component basis. Mechanics of how to do it without having runtime checks every time a method in Debug is called. What if one app wants a component to turn debugging on whereas another wants to turn it off.

[0397] Application Development Model

[0398] In the alternative embodiment, to develop an application using the BDK, an object model of the application domain should be first developed, retaining a separation between objects that represent business processes and those that represent business data. The two types of objects, obviously, map to session beans and entity beans in EJB parlance. A controller object, for instance, would indicate a session bean whereas an object that persists its data would indicate an entity bean. An application would typically also include UI components (such as JSP pages or servlets) which would use such business components. Thus, there are two primary roles from an applica