Generation of Administration framework for server systems Number:7,412,497 from the United States Patent and Trademark Office (PTO) owispatent A generator mechanism for generating an administration framework for server systems. In one embodiment, the administration framework may be generated from meta-information that describes elements of configuration data and relationships among the elements. The mechanism may provide automatic generation of the administration framework. In one embodiment, the administration framework may be a stack on an administration server that includes several layers each including one or more generated components. In one embodiment, the generation mechanism may generate management beans of a management layer, representing business logic of the server; configuration beans of a data representation layer; and a presentation layer for accessing and administering generated components. The data representation layer may provide transparency to the persistent store for the other layers. A production generation of the administration framework may be performed and instances of generated components may be deployed on other servers.<H Administration, Generation, Generation, of, A, 7412497.html, Patent, pto, 7412497

Title: Generation of Administration framework for server systems

Abstract: A generator mechanism for generating an administration framework for server systems. In one embodiment, the administration framework may be generated from meta-information that describes elements of configuration data and relationships among the elements. The mechanism may provide automatic generation of the administration framework. In one embodiment, the administration framework may be a stack on an administration server that includes several layers each including one or more generated components. In one embodiment, the generation mechanism may generate management beans of a management layer, representing business logic of the server; configuration beans of a data representation layer; and a presentation layer for accessing and administering generated components. The data representation layer may provide transparency to the persistent store for the other layers. A production generation of the administration framework may be performed and instances of generated components may be deployed on other servers.

Patent Number: 7,412,497 Issued on 08/12/2008 to Viswanath, et al.

Inventors: Viswanath; Sridatta (Santa Clara, CA), Kaul; Jeetendra (Sunnyvale, CA), Islam; Akm N. (San Jose, CA), Champenois; Ludovic J. (Mountain View, CA)
Assignee: Sun Microsystems, Inc. (Santa Clara, CA)

Appl. No.: 10/205,058

Filed: July 25, 2002

Current U.S. Class: 709/220 ; 709/223; 719/328

Current International Class: G06F 15/177 (20060101); G06F 15/173 (20060101); G06F 3/00 (20060101)

Field of Search: 709/220,223 718/1 719/315,328

References Cited [Referenced By]

U.S. Patent Documents


6061692	May 2000	Thomas et al.
6230160	May 2001	Chan et al.
6757778	June 2004	van Rietschote
6854122	February 2005	Sheriff et al.
6934952	August 2005	Sarkar et al.
2002/0116437	August 2002	Kambara et al.
2002/0147856	October 2002	Sarkar et al.
2003/0217170	November 2003	Nelson et al.
2004/0019662	January 2004	Viswanath et al.
2004/0019669	January 2004	Viswanath et al.
2004/0019670	January 2004	Viswanath

Other References

Loeser et al., "iWebDB--Web Site Administration based on Object-Relational Database Technology," 1999 International Database Engineering and Application Symposium, 1999, (6 Pages). cited by other .
Dinesh C. Verma, "Simplifying Network Administration Using Policy Based Management," Network, IEEE, vol. 16, Issue: 2, ISSN:0890-8044, Mar./Apr. 2002 (8 Pages). cited by other .
Seshadri Gokul, "J2EE Components and Services," http://www.samspublishing.com/articles, May 24, 2002, (6 Pages). cited by other .
"J2EE," http://searchwebservices.techtarget.com/gDefinition/0,294236,sid26- .sub.--gci283984,00.html,3Mar. 28, 1984, (3 Pages). cited by other .
Hunt et al., "Distributed Configuration Management via Java and the World Wide Web," University of Karlsruhe, Karlsruhe, Germany, May 1997, (14 Pages). cited by other .
Watson et al., "DHCP Server Verification by Client Via DNSSEC," http://mirrors.isc.org/pub/www.waterspirngs.org/pub/id/draft-watson-dhc-s- erv-verify-00.txt, Jul. 30, 1997, (6 Pages). cited by other.

Primary Examiner: Cardone; Jason
Assistant Examiner: Hossain; Tanim
Attorney, Agent or Firm: Kowert; Robert C. Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C.

Claims

What is claimed is:

1. A system, comprising: a plurality of servers; a data store comprising a persistent store of configuration information for the plurality of servers, wherein the persistent store is formatted in accordance with a data storage format; wherein one of the plurality of servers comprises a generation mechanism configured to: generate on the server an in-memory representation of the configuration information from meta-information describing the configuration information, wherein the in-memory representation of the configuration information is formatted in accordance with an in-memory data format; and generate on the server a plurality of components from the meta-information describing the configuration information, wherein the plurality of components are configured to access the in-memory representation of the configuration information to perform server configuration tasks.

2. The system as recited in claim 1, wherein the server further comprises a user interface configured to access the plurality of components to perform the server configuration tasks in response to user input, wherein the generation mechanism is further configured to generate the user interface from the meta-information describing the configuration information.

3. The system as recited in claim 1, wherein the server is configured to provide an instance of the in-memory representation of the configuration information to each of one or more others of the plurality of servers, wherein each of the other servers is configured to access the server information from the provided instance of the in-memory representation of the configuration information.

4. The system as recited in claim 1, wherein the system is configured to generate an instance of the in-memory representation of the configuration information and an instance of the plurality of components on one or more others of the plurality of servers, wherein each instance of the plurality of components is configured to access the corresponding instance of the in-memory representation of the configuration information to perform configuration tasks of the particular server.

5. The system as recited in claim 1, wherein the server further comprises a configuration Application Programming Interface (API) configured to provide access to the persistent store for the plurality of components independent of a location and the data storage format of the persistent store.

6. The system as recited in claim 5, wherein the configuration API is further configured to provide access to the persistent store for the plurality of components in accordance with a different data storage format in response to a change of the data storage format of the persistent store to the different data storage format.

7. The system as recited in claim 1, wherein the plurality of components each comprise: one or more program methods each configured to perform business logic of the server; and one or more access methods for accessing the in-memory representation of the configuration information.

8. The system as recited in claim 1, wherein the configuration information comprises a plurality of elements, wherein, to generate on the server an in-memory representation of the configuration information from meta-information describing the configuration information, the generation mechanism is further configured to generate a plurality of configuration components comprising the in-memory representation of the configuration information, wherein each of the configuration components represents one element of the configuration information.

9. The system as recited in claim 8, wherein each of the configuration components comprises one or more access methods for accessing the element of the configuration information represented by the configuration component.

10. The system as recited in claim 8, wherein the plurality of configuration components are Java beans.

11. The system as recited in claim 1, wherein one or more of the plurality of components are management components each comprising one or more program methods configured to access the in-memory representation of the configuration information to perform a particular one of the server configuration tasks.

12. The system as recited in claim 11, wherein the management components are Java Management Extensions (JMX) MBeans.

13. The system as recited in claim 1, wherein the server further comprises a configuration Application Programming Interface (API), and wherein one or more of the components are each configured to send lookup requests for one or more of the other components to the configuration API, wherein the configuration API is configured to: look up a requested component; and provide the requested component to the requesting component.

14. The system as recited in claim 13, wherein the lookup requests are formatted in accordance with XPath.

15. The system as recited in claim 1, wherein the configuration information comprises a plurality of related elements, wherein the meta-information describes the elements and a relationship among the elements.

16. The system as recited in claim 1, wherein the system is an application server system, wherein the plurality of servers comprises one or more application servers, and wherein the one of the plurality of servers is an administration server for the application server system.

17. A server, comprising: a memory; and a generation mechanism configured to: generate in the memory an in-memory representation of configuration information from meta-information describing a persistent store of the configuration information, wherein the in-memory representation of the configuration information is formatted in accordance with an in-memory data format, and wherein the persistent store of the configuration information is formatted in accordance with a data storage format; and generate on the server a plurality of components from the meta-information describing the configuration information, wherein the plurality of components are configured to access the in-memory representation of the configuration information to perform server configuration tasks.

18. The server as recited in claim 17, further comprising a user interface configured to access the plurality of components to perform the server configuration tasks in response to user input, wherein the generation mechanism is further configured to generate the user interface from the meta-information describing the configuration information.

19. The server as recited in claim 17, further configured to provide an instance of the in-memory representation of the configuration information to each of one or more other servers, wherein each of the other servers are configured to access the server information from the provided instance of the in-memory representation of the configuration information.

20. The server as recited in claim 17, further configured to provide an instance of the in-memory representation of the configuration information and an instance of the plurality of components to each of one or more other servers, wherein each instance of the plurality of components is configured to access the corresponding instance of the in-memory representation of the configuration information to perform configuration tasks of the particular server.

21. The server as recited in claim 17, further comprising a configuration Application Programming Interface (API) configured to provide access to the persistent store for the plurality of components independent of a location and the data storage format of the persistent store.

22. The server as recited in claim 21, wherein the configuration API is further configured to provide access to the persistent store for the plurality of components in accordance with a different data storage format in response to a change of the data storage format of the persistent store to the different data storage format.

23. The server as recited in claim 17, wherein the plurality of components each comprise: one or more program methods each configured to perform business logic of the server; and one or more access methods for accessing the in-memory representation of the configuration information.

24. The server as recited in claim 17, wherein the configuration information comprises a plurality of elements, wherein, to generate in the memory an in-memory representation of configuration information from meta-information describing a persistent store of the configuration information, the generation mechanism is further configured to generate a plurality of configuration components comprising the in-memory representation of the configuration information, wherein each of the configuration components represents one element of the configuration information.

25. The server as recited in claim 24, wherein each of the configuration components comprises one or more access methods for accessing the element of the configuration information represented by the configuration component.

26. The server as recited in claim 24, wherein the plurality of configuration components are Java beans.

27. The server as recited in claim 17, wherein one or more of the plurality of components are management components each comprising one or more program methods configured to access the in-memory representation of the configuration information to perform a particular one of the server configuration tasks.

28. The server as recited in claim 17, wherein the management components are Java Management Extensions (JMX) MBeans.

29. The server as recited in claim 17, further comprising a configuration Application Programming Interface (API), wherein one or more of the components are each configured to send lookup requests for one or more of the other components to the configuration API, wherein the configuration API is configured to: look up a requested component; and provide the requested component to the requesting component.

30. The server as recited in claim 29, wherein the lookup requests are formatted in accordance with XPath.

31. The server as recited in claim 17, wherein the configuration information comprises a plurality of related elements, wherein the meta-information describes the elements and a relationship among the elements.

32. The server as recited in claim 17, wherein the server is an administration server for one or more application servers in an application server system.

33. A method, comprising: generating on a server an in-memory representation of configuration information from meta-information describing a persistent store of the configuration information, wherein the in-memory representation of the configuration information is formatted in accordance with an in-memory data format, and wherein the persistent store of the configuration information is formatted in accordance with a data storage format; and generating on the server a plurality of components from the meta-information describing the configuration information, wherein the plurality of components are configured to access the in-memory representation of the configuration information to perform server configuration tasks.

34. The method as recited in claim 33, further comprising: generating a user interface from the meta-information describing the configuration information; and the user interface accessing the plurality of components to perform the server configuration tasks in response to user input.

35. The method as recited in claim 33, further comprising generating an instance of the in-memory representation of the configuration information on each, of one or more other servers, wherein the other servers are each configured to access the server information from the generated instance of the in-memory representation of the configuration information.

36. The method as recited in claim 33, further comprising generating an instance of the in-memory representation of the configuration information and an instance of the plurality of components on each of one or more other servers, wherein each instance of the plurality of components is configured to access the corresponding instance of the in-memory representation of the configuration information to perform configuration tasks of the particular server.

37. The method as recited in claim 33, further comprising one or more of the plurality of components accessing the persistent store through a configuration Application Programming Interface (API), wherein said accessing is performed transparent to a location and the data storage format of the persistent store.

38. The method as recited in claim 37, further comprising: changing the data storage format of the persistent store to a different data storage format; and the one or more of the plurality of components accessing the persistent store through the configuration API in accordance with the different data storage format.

39. The method as recited in claim 33, wherein the plurality of components each comprise: one or more program methods each configured to perform business logic of the server; and one or more access methods for accessing the in-memory representation of the configuration information.

40. The method as recited in claim 33, wherein the configuration information comprises a plurality of elements, wherein said generating on a server an in-memory representation of configuration information from meta-information describing a persistent store of the configuration information comprises generating a plurality of configuration components comprising the in-memory representation of the configuration information, wherein each of the configuration components represents one element of the configuration information.

41. The method as recited in claim 40, wherein each of the configuration components comprises one or more access methods for accessing the element of the configuration information represented by the configuration component.

42. The method as recited in claim 40, wherein the plurality of configuration components are Java beans.

43. The method as recited in claim 33, wherein one or more of the plurality of components are management components each comprising one or more program methods each configured to access one or more of the configuration components to perform a particular one of the server configuration tasks.

44. The method as recited in claim 43, wherein the management components are Java Management Extensions (JMX) MBeans.

45. The method as recited in claim 33, further comprising: one of the components sending a lookup request for another one of the components to a configuration Application Programming Interface (API); the configuration API looking up the requested component; and the configuration API providing the requested component to the requesting management component.

46. The method as recited in claim 45, wherein the lookup requests are formatted in accordance with XPath.

47. The method as recited in claim 33, wherein the configuration information comprises a plurality of related elements, wherein the meta-information describes the elements and a relationship among the elements.

48. The method as recited in claim 33, wherein the server is an administration server for one or more application servers in an application server system.

49. A computer accessible storage medium comprising program instructions configured to implement: generating on a server an in-memory representation of configuration information from meta-information describing a persistent store of the configuration information, wherein the in-memory representation of the configuration information is formatted in accordance with an in-memory data format, and wherein the persistent store of the configuration information is formatted in accordance with a data storage format; and generating on the server a plurality of components from the meta-information describing the configuration information, wherein the plurality of components are configured to access the in-memory representation of the configuration information to perform server configuration tasks.

50. The computer accessible storage medium as recited in claim 49, wherein the program instructions are further configured to implement: generating a user interface from the meta-information describing the configuration information; and the user interface accessing the plurality of components to perform the server configuration tasks in response to user input.

51. The computer accessible storage medium as recited in claim 49, wherein the program instructions are further configured to implement generating an instance of the in-memory representation of the configuration information on each of one or more other servers, wherein the other servers are each configured to access the server information from the generated instance of the in-memory representation of the configuration information.

52. The computer accessible storage medium as recited in claim 49, wherein the program instructions are further configured to implement generating an instance of the in-memory representation of the configuration information and an instance of the plurality of components on each of one or more other servers, wherein each instance of the plurality of components is configured to access the corresponding instance of the in-memory representation of the configuration information to perform configuration tasks of the particular server.

53. The computer accessible storage medium as recited in claim 49, wherein the program instructions are further configured to implement one or more of the plurality of components accessing the persistent store through a configuration Application Programming Interface (API), wherein said accessing is performed transparent to a location and the data storage format of the persistent store.

54. The computer accessible storage medium as recited in claim 53, wherein the program instructions are further configured to implement: changing the data storage format of the persistent store to a different data storage format; and the one or more of the plurality of components accessing the persistent store through the configuration API in accordance with the different data storage format.

55. The computer accessible storage medium as recited in claim 49, wherein the plurality of components each comprise: one or more program methods each configured to perform business logic of the server; and one or more access methods for accessing the in-memory representation of the configuration information.

56. The computer accessible storage medium as recited in claim 49, wherein the configuration information comprises a plurality of elements, wherein, in said generating on a server an in-memory representation of configuration information from meta-information describing a persistent store of the configuration information, the program instructions are further configured to implement generating a plurality of configuration components comprising the in-memory representation of the configuration information, wherein each of the configuration components represents one element of the configuration information.

57. The computer accessible storage medium as recited in claim 56, wherein each of the configuration components comprises one or more access methods for accessing the element of the configuration information represented by the configuration component.

58. The computer accessible storage medium as recited in claim 56, wherein the plurality of configuration components are Java beans.

59. The computer accessible storage medium as recited in claim 49, wherein one or more of the plurality of components are management components each comprising one or more program methods each configured to access one or more of the configuration components to perform a particular one of the server configuration tasks.

60. The computer accessible storage medium as recited in claim 59, wherein the management components are Java Management Extensions (JMX) MBeans.

61. The computer accessible storage medium as recited in claim 49, wherein the program instructions are further configured to implement: one of the components sending a lookup request for another one of the components to a configuration Application Programming Interface (API); the configuration API looking up the requested component; and the configuration API providing the requested component to the requesting management component.

62. The computer accessible storage medium as recited in claim 61, wherein the lookup requests are formatted in accordance with XPath.

63. The computer accessible storage medium as recited in claim 49, wherein the configuration information comprises a plurality of related elements, wherein the meta-information describes the elements and a relationship among the elements.

64. The computer accessible storage medium as recited in claim 49, wherein the server is an administration server for one or more application servers in an application server system.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to computer networks, and more particularly to a dynamic administration framework for distributed server systems.

2. Description of the Related Art

An application server is a server program in a computer in a distributed network that provides the business logic for an application program. The application server is frequently viewed as part of a three-tier application, consisting of a graphical user interface (GUI) server, an application (business logic) server, and a database server. More descriptively, it can be viewed as dividing an application into: A first-tier, front-end, Web browser-based graphical user interface, usually at a personal computer or workstation; A middle-tier business logic application or set of applications, possibly on a local area network or intranet server; A third-tier, back-end, database and transaction server, sometimes on a mainframe or large server.

Older, legacy application databases and transaction management applications are part of the back end or third tier. The application server is the middleman between browser-based front-ends and back-end databases and legacy systems.

A Web server is a program that, using the client/server model and the World Wide Web's Hypertext Transfer Protocol (HTTP), serves the files that form Web pages to Web users (whose computers contain HTTP clients that forward their requests). Every computer on the Internet that contains a Web site must have a Web server program.

In servers based on the J2EE (Java 2 Platform, Enterprise Edition) distributed computing model, the business presentation is typically represented using servlets and/or Java Server Pages (JSPs), and the business logic typically runs in the form of distributed components such as Enterprise JavaBeans (EJBs).

J2EE (Java 2 Platform, Enterprise Edition) is a Java platform designed for the mainframe-scale computing typical of large enterprises. Sun Microsystems (together with industry partners such as IBM) designed J2EE to simplify application development in a thin client tiered environment. J2EE simplifies application development and decreases the need for programming and programmer training by creating standardized, reusable modular components and by enabling the tier to handle many aspects of programming automatically. J2EE includes a number of components, including: The Java Development Kit (JDK) is included as the core language package. Full support for Enterprise JavaBeans. EJB is a server-based technology for the delivery of program components in an enterprise environment. It supports the eXtensible Markup Language (XML) and has enhanced deployment and security features. The Java servlet API (application programming interface) enhances consistency for developers without requiring a graphical user interface (GUI). Java Server Pages (JSP) is used for dynamic Web-enabled data access and manipulation.

The J2EE Application Programming Model is the standard programming model used to facilitate the development of multi-tier, thin client applications. The J2EE Platform includes policies and APIs such as the Java servlets and Java Message Service (JMS).

The Sun.TM. One Application Server provides a robust J2EE e-commerce platform for the development, deployment, and management of application services to a broad range of servers, clients, and devices. The Sun.TM. One Application Server maximizes application re-use and developer collaboration and demonstrates the potential of leveraging Java for large-scale web and wireless applications.

The Sun.TM. One Web Server is a software product for developers engaged in building dynamic Web applications for e-commerce sites. Multiplatform support makes it possible for developers to work in the operating system environment of their choice. The product works with Java.TM. Servlet and JavaServer Pages.TM. technologies to generate personalized content and speed development. Its centralized server management, content management, and rapid application development features combine to deliver a powerful means for enterprises to move their businesses to the Internet.

Java.TM. Management Extensions (JMX) is an open technology for management and monitoring for deployment across industries wherever management and/or monitoring may be needed or desired. JMX may be used, for example, for adapting legacy systems, implementing new management and monitoring solutions and plugging into future solutions. JMX may provide tools for building distributed, Web-based, modular and dynamic solutions for managing and monitoring devices, applications and service-driven networks.

A bean may be defined as a component, a reusable program building block that may be combined with other components in the same or other computers in a distributed network to form an application. Examples of components include, but are not limited to, buttons in a graphical user interface and interfaces to a database manager. Components may be deployed on different servers in a network and may communicate with each other for needed services. A component may run within a context called a container. Examples of containers include, but are not limited to, pages on a Web site, Web browsers, and word processors.

A managed bean, or MBean, is a Java object that represents a JMX manageable resource. MBeans may follow the JavaBeans.TM. components model, thus providing a direct mapping between JavaBeans components and manageability. Because MBeans provide instrumentation of managed resources in a standardized way, they can be plugged into any JMX agent.

The open source schema2beans library (schema2beans jar file) allows the generation of a set of java bean classes from a DTD or XML Schema file. This set of beans may be used to represent an XML file as a graph of java beans. Elements of the graph may be added, changed and/or removed, graphs may be merged and compared, and events may be generated and obtained on any change in the graph. The graph may be written back as a DTD or XML Schema file. The package of this library is includes a schema2beans runtime and schema2beans generator, both part of the same schema2beans jar file.

XPath is a language that describes a way to locate and process items in documents (e.g. Extensible Markup Language (XML) documents) by using an addressing syntax based on a path through the document's logical structure or hierarchy. This makes writing programming expressions easier than if each expression had to understand typical XML markup and its sequence in a document. XPath also allows the programmer to deal with the document at a higher level of abstraction. XPath is a language that is used by and specified as part of both the Extensible Stylesheet Language Transformations (XSLT) and by XPointer (SML Pointer Language). It uses the information abstraction defined in the XML Information Set (Infoset). Since XPath does not use XML syntax itself, it may be used in contexts other than those of XML.

SUMMARY OF THE INVENTION

A generator mechanism that may be used to generate an administration framework for server systems such as application and web server systems is described. In one embodiment, the administration framework may be generated from meta-information that describes elements or properties of configuration data, and that may describe relationships (e.g. hierarchical relationships) among the elements of the configuration data. During development, configuration data, and thus the meta-information describing the configuration data, may be changed. The generation mechanism may provide an automatic way to generate the administration framework rather than having to manually make changes to the administration framework to support changes in configuration data. In one embodiment, XML may be used as a data representation language for the meta-information.

The meta-information may include a representation of the elements and element attributes of a persistent store of configuration information. The meta-information may be represented in formats including, but not limited to, markup languages such as XML, schemas, DTDs, etc. In one embodiment, all meta-information may be contained in one file (e.g. an XML file or a schema file). In one embodiment, the meta-information file may be generated by a user or users, for example a server system designer or developer, to describe the elements of configuration data of the server system and the relationships among the described elements. In one embodiment, the meta-information may be accessed by administration framework generator(s) to generate components of the administration server to be used at runtime for monitoring and managing the system.

In one embodiment, the administration framework may be a stack implemented on an administration server that includes several layers each including one or more components. At least a portion of each of these layers may be generated by the generation mechanism from the meta-information. In one embodiment, the generation mechanism may generate one or more management beans (e.g. MBeans) of a management layer, each representing business logic of the server. In one embodiment, the generation mechanism may generate one or more configuration beans of a data representation layer. In one embodiment, the generation mechanism may generate one or more components of a presentation layer (e.g. an administration user interface (UI)) for use in displaying, locating, accessing, managing and modifying configuration elements and/or attributes as represented in the configuration beans.

At runtime, the generated administration UI of the presentation layer may be used to access the management layer (e.g. management beans) to perform administration, monitoring and configuration operations. The management layer may access the data representation layer (e.g. configuration beans) to access the server configuration information. The data representation layer may abstract the other layers from the persistent store, and thus may provide data storage format and location transparency to the persistent store for the other layers.

In one embodiment, when the system is ready to go from development to a production environment, a production generation of the administration framework may be performed and the system may be deployed. In one embodiment, deployment may include implementing instances of components generated on the administration server (e.g. the configuration beans representing the configuration information and the management beans implementing the business logic) on one or more other servers (e.g. application servers) to which the server system is to be deployed. The server components may then access the management beans and the in-memory representation of the configuration information (e.g. the configuration beans) to perform server tasks.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A illustrates an exemplary architecture for a web application that utilizes an application server cluster;

FIG. 1B illustrates an exemplary architecture for an application that utilizes an application server cluster;

FIG. 2 illustrates an administration server implemented in accordance with a dynamic administration framework according to one embodiment;

FIG. 3 illustrates an administration server with management beans and configuration beans implemented in accordance with a dynamic administration framework according to one embodiment;

FIG. 4 illustrates an application server system implemented in accordance with a dynamic administration framework according to one embodiment;

FIG. 5 further illustrates an application server system implemented in accordance with a dynamic administration framework according to one embodiment;

FIG. 6 illustrates the generation and runtime aspects of the administration framework according to one embodiment;

FIG. 7 is a flowchart illustrating a method of event notification according to one embodiment;

FIG. 8 is a flowchart illustrating a method of configuration change handling on an administration server according to one embodiment;

FIG. 9 is a flowchart illustrating a server initialization process in an application server system using the administration framework generating components (e.g. server instances), listeners for the components, and a multicaster component of the event notification mechanism according to one embodiment;

FIG. 10 is a flowchart illustrating a multicaster sending notification events to registered components generated using the method of FIG. 9 according to one embodiment;

FIG. 11 illustrates an architecture of a pluggable verification and validation mechanism for configuration data according to one embodiment;

FIG. 12 illustrates a method of performing verification and validation according to one embodiment; and

FIG. 13 further illustrates a method of performing verification and validation according to one embodiment.

While the invention is described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that the invention is not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word "may" is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words "include", "including", and "includes" mean including, but not limited to.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Embodiments of a dynamic administration framework for server systems such as application and web server systems are described. Embodiments may address the generation as well as the runtime behavior of the administration framework and one or more of its components. Given meta-information that describes a system, a generation mechanism may generate one or more of the components of the administration framework for administration of that system. In one embodiment, the generated components may include components that are implemented as Java beans. In one embodiment, at least a portion of the generated components may include, but are not limited to, one or more of program (e.g. business) logic for the server(s) and access functions for accessing configuration information of the server system. In one embodiment, the administration framework may include an administration user interface (UI) that may be generated from the meta-information and that may be used to manage and monitor components of the generated administration framework.

In one embodiment, generated components of the administration framework may include an in-memory representation of configuration information for the server system. In one embodiment, the in-memory representation of configuration information may include a plurality of components (e.g. beans) generated from the meta-information. In one embodiment, each of the plurality of components included in the in-memory representation of configuration information may represent an element of the configuration information; each of these components may be located and accessed to access the corresponding configuration element.

"In-memory" is used herein to distinguish representations of the configuration information on the server(s) in a server system from the backend storage of the configuration information. The in-memory representation of the configuration information may be used, for example, during development of the server system and/or during runtime of the server system. The in-memory representation may be stored in various memory media of a server including one or more of, or a combination of, RAM (e.g. SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, and local storage devices such as disks. For example, in a system supporting virtual memory, a portion of the in-memory representation may be stored in active storage (e.g. RAM) and other portions may be stored in or "swapped out" to hard disk or other high volume storage devices.

During development, configuration data, and thus the meta-information describing the configuration data, may be changed. The generation mechanism as described herein may provide an automatic way to generate the administration framework rather than having to manually make changes to the administration framework to support changes in configuration data. If an element or attribute changes, the generation mechanism may provide an automatic method to update the administration framework rather than having to locate and make changes to every instance of the element or attribute manually.

Embodiments of the administration framework may provide storage transparency to the backend storage of configuration data. Backend storage of configuration information for a system (which may be referred to as a persistent store) may be distributed across one or more data storage devices, and may be formatted in accordance with one of a variety of heterogeneous data storage formats (e.g. file-based, LDAP, etc.). The data storage format and/or distribution of the persistent store may be changed, for example to meet changing requirements of the system. Through storage transparency, frontend clients may access the persistent store of configuration data independent of the distribution and/or data storage format of the persistent store. In one embodiment, the administration framework may provide a generic application programming interface (API) that provides the storage transparency between the persistent store of configuration information and clients of the persistent store. The API (which may be referred to as a configuration API) may provide a unified view of the persistent store of configuration information, and may provide a generic interface for accessing heterogeneous data storage formats that may be used in the backend storage. Through the generic interface provided by the API, a frontend process or component may access multiple stores on different backend storage devices using a single operation (e.g. a write or a read operation).

One embodiment may include an event notification mechanism that may allow events (e.g. changes in configuration data) to be propagated in a distributed system running several virtual machines (VMs) (e.g. Java Virtual Machines (JVMs)).

One embodiment may provide a generic, pluggable, extensible verification and validation mechanism that may be reusable in stand-alone (off-line) applications and in applications server (on-line).

FIGS. 1A and 1B illustrate exemplary architectures for client/server systems that utilize application server clusters. It is noted that application server clusters may be utilized in any of various types of systems, and FIGS. 1A and 1B illustrate only one exemplary use.

In general, a web application may be defined as an Internet or Intranet-based application comprising a collection of resources that are accessible through uniform resource locators (URLs). The resources may include web pages comprising HTML, XML, scripting code such as Javascript or VBScript, or other types of elements. The resources may also include any of various types of executable programs or components, such as CGI programs, Java servlets, JavaBeans components, CORBA components, downloadable code such as Java classes or ActiveX components, etc. The resources may also include any other type of resource addressable through a URL.

FIG. 1A illustrates a client computer 100 running a web browser, such as the Netscape Navigator or Microsoft Internet Explorer web browsers. It is noted that the web browser need not be a web browser per se, but may be any of various types of client-side applications that include web-browsing functionality. For example, Microsoft Corp. provides programming interfaces enabling applications to incorporate various web-browsing capabilities provided by the Microsoft Internet Explorer code base.

The web browser may run in any type of client computer 100. For example, the web browser may run in a desktop computer or workstation running any of various operating systems, such as Windows, Mac OS, Unix, etc., or the web browser may run in a portable computing device, such as a personal data assistant, smart cellular phone, etc. The client computer 100 may use a network connection for communicating with a web server 104 via a network 102, such as the Internet or an Intranet. The client network connection may be a connection of any type, such as a PPP or SLIP dialup link, an Ethernet or token ring connection, an ISDN connection, a cable modem connection, any of various types of wireless connections, etc. Although web applications are often associated with particular communication protocols, such as HTTP or SSL, it is noted that any communication protocol, including TCP-based protocols and UDP-based protocols, may be used to communicate over the network 102.

As the web server 104 receives a request from a client computer 100, the web server may treat the request differently, depending on the type of resource the request references. For example, if the request references a document 106, such as an HTML document, then the web server may process the request itself, e.g., by retrieving the document from the web server's local file system or from a local cache and returning the document to the client computer. For other types of requests, e.g., requests referencing executable components, such as Java servlets, JavaBeans components, C program modules, CORBA components, etc., the web server 104 may broker the request to an application server 108. For example, as shown in FIG. 1A, there may be a plurality of application servers 108 in a cluster, and the web server 104 may select an application server to which to broker the request, e.g., using load balancing techniques. The web server 104 may interface with an application server 108 using various techniques, e.g., through an in-process extension, such as an ISAPI or NSAPI extension.

The application server 108 may be configured as a part of an application server cluster. Although FIG. 1A illustrates an application server cluster with only two application servers, it is noted that the cluster may comprise any number of application servers. Each application server 108 may interface with various types of other servers or systems. For example, as illustrated in FIG. 1A, the application servers 108 may communicate with a database 110. Each application server 108 in the cluster may interface with the same systems, or the application servers 108 may differ in which systems they interface with. For example, application server 108B is shown to interface with a backend system 112, e.g., a CICS, R/3, PeopleSoft, or other type of backend system. For example, the backend system 112 may be responsible for managing enterprise data or performing business functions for an enterprise.

Application servers 108 in a cluster may or may not be in close physical proximity to each other. The application server computers may be connected to each other in any of various ways. For example, in one embodiment, each application server computer may be a member of a single local area network (LAN). In another embodiment, various of the application server computers may be located in two or more LANs, wherein the LANs are networked together.

While FIG. 1A illustrates web server 104 and application servers 108 as implemented on different computing devices, it is noted that in various embodiments one or more web servers 104 and one or more application servers 108 may be implemented in software on a computing device. For example, web server 104 and application server 108B may be implemented on a single computing device. In some embodiments, one or more web servers 104 and/or one or more application servers 108 may be implemented on virtual machines (VMs) (e.g., Java Virtual Machines (JVMs)). The virtual machines may be implemented on one or more computing devices. For example, in FIG. 1A, web server 104 and application servers 108A and 108B may each be implemented in a separate virtual machine, or alternatively one or more of the servers may be implemented in a single virtual machine.

In alternative embodiments, as illustrated in FIG. 1B, a client computer 100 may communicate directly with an application server 108 or application server cluster, without interfacing through a web server. As one example, the application servers 108 may run an enterprise resource planning application, and the client computers 100 may be computers within the enterprise that are connected to the application servers 108 via a WAN. In this example, the client computers may run "thick client" software, e.g., client software that comprises a portion of the enterprise resource planning application logic. The client computer software may interface directly with executable programs or components running on the application servers, e.g., through a protocol such as the Internet Inter-Orb Protocol (IIOP).

As noted above, FIGS. 1A and 1B represent exemplary architectures only, and many variations are possible. As a small handful of examples of alternative embodiments, multiple web servers may be present to receive requests from client computers and broker the requests to application servers, the web server may itself interface directly with a database, application servers may interface with various other types of systems, such as specialized authentication servers, e-commerce servers, other types of legacy systems, etc.

FIG. 2 illustrates an administration server implemented in accordance with a dynamic administration framework according to one embodiment. FIG. 2 shows an administration server 200, a persistent store 204 and meta-information 226. FIG. 2 also illustrates flow of a process of generating the administration framework from meta-information 226 describing a persistent store 204 of configuration information of the administration server 200. One embodiment may include an administration framework generator 224 mechanism that may be used to generate an administration framework from meta-information 226 (e.g., an XML file, a schema, a DTD file, etc.) that includes descriptions of elements or properties, and their attributes, of the persistent store 204, and that may also describe relationships (e.g. hierarchical relationships) among the elements. The administration framework generator 224, along with the configuration API 222, may be used as a basis for administering a server system. The administration framework generator 224 mechanism may provide pluggability and ease of maintenance, among other advantages. While the administration framework generator 224 mechanism is illustrated as being separate from application server 200, it is noted that in one embodiment, the administration framework generator 224 mechanism may be included in the application server 200. In one embodiment, the administration framework generator 224 mechanism and the application server 200 may be software components of a computer system, or alternatively may be software components of different computer systems. In one embodiment, the administration framework generator 224 mechanism and the application server 200 may be software components of a virtual machine, or alternatively may be software components of different virtual machines.

In one embodiment, all elements or properties of the persistent store 204 may be represented in one or more meta-information 226 files (e.g. an XML file). In one embodiment, all elements or properties of the persistent store 204 may be represented in exactly one meta-information 226 file (e.g. an XML file). In one embodiment, there may be one such file per server instance in the server system. In one embodiment, XML may be used as a data representation language for the meta-information. The meta-information 226 may include rules defining the system configuration data. The meta-information may describe elements to be administered and their attributes. For example, an element called "server" may have attributes such as name, locale(s), log-root, etc. These attributes may have default values described in the meta-information 226, as well as a list of correct possible values, and in one embodiment may be described as REQUIRED or IMPLIED.

Meta-information 226 file may include representations of configuration information for the application server 200. In one embodiment, this configuration information may include server-level configuration information, e.g. information describing data of persistent store 204 and information describing deployed applications that servers associated with the administration server 200 may run. In one embodiment, meta-information 226 may not include application-level configuration data. In one embodiment, the meta-information 226 may be configuration information in any of different formats including, but not limited to, XML, LDAP, DTD, schema, database-based, and file-based.

In one embodiment, the meta-information 226 may include server and component configuration information as well as registered application information. In one embodiment, deployed applications may be stored, for example, as jar files, with application configuration info within the jar files (e.g. application.xml, etc). The following illustrates the structure of an exemplary meta-information 226 file that uses tags (e.g. an XML file), and is not intended to be limiting:

TABLE-US-00001 <Domain> <resources... /> <Application> ... <WebAppComponent> ... <EJBComponent> ... </Application> <Application ... /> <Server...> <web container> ... <etc...> </Server> </Domain>

In one embodiment, there is a hierarchical relationship among the elements of the configuration data. In this embodiment, the elements and their hierarchical relationship are represented in meta-information 226.

In one embodiment, the meta-information 226 may be accessed by generator mechanism 224 to generate beans 250. Beans 250 may provide a bean representation of the configuration data of the backend persistent store 204. In one embodiment, beans 250 may be generated in a hierarchical relationship to represent a hierarchical relationship of configuration data elements as described in meta-information 226.

A bean 250 may include one or more methods for performing business logic of the server system that may perform operations on, or using, one or more elements of the persistent store 204. A bean may also include "get" and "set" methods for the attributes of the corresponding elements. These generated methods may implement the constraints on the data elements defined in the meta-information 226. Elements may have sub-elements that may be used to describe hierarchical data of the system. For example, an element "server" may have sub-elements "web-container," "resources," "applications," etc. Each of these sub-elements may also have sub-elements and attributes.

In one embodiment, the generator mechanism 224 may generate a bean 250 for each corresponding element in meta-information 226. Beans 259 may represent every element in the meta-information 226 file. For example, if there are five elements under the root, there will be five beans representing the elements. In one embodiment, a bean 250 may include other beans 250 and/or references to other beans 250. In one embodiment, elements have a one-to-one correspondence to generated beans 250.

In one embodiment, generator mechanism 224 to generate beans 250 using the open source schema2beans library. In one embodiment, beans 250 may be exposed so that the beans may be modified by users.

In one embodiment, the generator mechanism 224 may generate, from meta-information 226, one or more bean methods in a bean 250 to describe the containment relationship between elements. These methods may facilitate adding, removing, and replacing a sub-element, or accessing a sub-element give a primary key, for example. A primary key may be included in the meta-information for each element, and may include one or more of the attributes of the element. For example, the primary key for the "server" element may be its name, since servers may have different names. Other bean methods may also be generated, for example for getting the number of sub-elements of a certain type (e.g., the number of applications for the server).

In one embodiment, application server may include a configuration API 222 that may provide an interface to the persistent store 204 as represented in meta-information 226, and thus may abstract the persistent store 204 to provide flexibility of storage and location transparency. In one embodiment, the configuration API 222 may provide access to the meta-information 226 file (any element, any attribute). In one embodiment, configuration API 222 is a generic API. In one embodiment, the core configuration API is not generated by administration framework generator 224, and may be used "as is" in any of a variety of server applications to provide an interface to persistent stores 204 in any of a variety of formats. Generated beans and other components may use the configuration API as a generic, transparent access method to the backend storage of the persistent store 204, independent of the format of the backend storage.

The persistent store 204 of configuration information may be distributed across one or more data storage devices, and may be formatted in accordance with one of a variety of heterogeneous data storage formats (e.g. file-based, LDAP, etc.). The data storage format and/or distribution of the persistent store may be changed, for example to meet changing requirements of the system. Through storage transparency, frontend clients may access the persistent store of configuration data independent of the distribution and/or data storage format of the persistent store. The configuration API may provide a unified view of the persistent store of configuration information, and may provide a generic interface for accessing heterogeneous data storage formats that may be used in the backend storage. Through the configuration API, a frontend process or component may access multiple stores on different backend storage devices using a single operation (e.g. a write or a read operation).

In one embodiment, the configuration API 222 may provide storage transparency. The backend storage (persistent store 204) may be changed without requiring change to the generated front end provided by the administration framework. For example, if the backend storage format of the persistent store 204 is changed (e.g. from file-based to LDAP), the administration framework may not need to be regenerated. The context may be changed inside the configuration API 222 (for example, one or more different storage adapters 208 may be plugged in to support the new backend format), and the changed persistent store 204 may be accessed by the previously generated administration framework through the configuration API 222.

The configuration API 222 may provide a generic interface