UC BERKELEY E-ARCHITECTURE GUIDELINES
This document is meant to serve as a guide to help campus departments integrate new information systems they may be buying or building with the e-Berkeley architecture. The basis for these guidelines comes from several source documents found at http://socrates.Berkeley.EDU:4259/eberk.detail.html. Because the architecture will evolve as current technologies change and new ones emerge, these guidelines will be reviewed and revised on a periodic basis if needed.
The adoption of an architecture for e-Berkeley has come after much analysis of the current campus IT architecture as well as plans for its future development and integration. The EBITF has asked the ITATF e-Architecture subcommittee to compile this set of guidelines.
Some general guiding principles that have been highlighted are:
Connector-emphasized, n-tier systems, based upon the J2EE framework, that adhere to authentication, authorization, and data exchange standards will be the easiest to integrate into the new architecture. Applications that do not have these qualities may require modification by either the vendor or campus personnel to be integrated.
Below are several descriptions of areas of concern and subsequent questions to be asked of vendors when selecting a product. The vendors' answers will help all involved to assess the application's ability to work well in the E-Berkeley architecture.
For an application to easily integrate into the e-Berkeley architecture, the application will need to provide well-defined interfaces to access application functionality programmatically. There are three main areas where interfaces should be provided: presentation interface, business logic, and database.
The user interface access is necessary for cases in which the application needs to be customized to fit UC Berkeley business practices. For example, an application workflow interface may need changes due to actual workflow practices on campus or to facilitate integration into a campus portal. The business logic access is useful for applications that need to follow the same business logic without recreating it. The database access may be needed when a program needs to access the data without going through the business logic.
When integrating a new application into the campus architecture, we need to consider its full impact on existing systems. For example, in some cases it may be better to make use of an already installed database that is already integrated into the campus architecture than to install a new system.
A.1) What component model does your application use in the current version? What models are planned, and when are they expected? What application server do you use?
A.2) What interfaces are provided to your application using which technologies (e.g., RMI, Corba, custom API, etc.)? Please list the interfaces that you provide for each of the application layers below.
Presentation
Business logic
Database
A.3) What is the logical configuration of the components of your application? How have you provisioned your application's components for robustness and scalability?
A.4) What mechanism do you provide to configure your application? Is it possible to change the workflow and business logic within your application? How are changes made?
A.5) Is the presentation interface customizable? Can users personalize their environment?
A.6) Can your application participate in a portal? Which portal environments do you support?
A.7) What administrative tools are provided for management of the various components of your application?
A.8) Can your application use an external database? If so, which databases and database drivers are supported?
A.9) What OS versions/patches are required for the components of the server? What OS versions are required for the client software, if any? What web browsers and versions are supported?
Applications integrating into the e-Berkeley architecture will need to utilize the provided authentication and authorization interfaces of the CalNet service. Currently, Kerberos is the deployed technology for authentication and LDAP is the deployed technology for authorization. Applications that provide a web interface should implement Kerberos web proxy authentication using the Authentication Web Server (AWS) service, see http://www.net.berkeley.edu/kerberos/documents/AWSAppSetup.html. All UC Berkeley students, staff, and faculty have a CalNet ID. The CalNet ID allows them to access many services across campus. Applications will want to allow users to utilize their CalNet ID to access application services. CalNet will eventually include a Public Key Infrastructure as well. More information can be found at http://calnet.berkeley.edu/. For more security information see http://cio.berkeley.edu/security.html.
Applications will need to adhere to University policies. One of the main ways that policies will be implemented in the e-Berkeley architecture is through use of the CalNet service. Ownership, Entitlement, and Stewardship are the main issues that must be reflected in the applications business logic. (see policy information at http://socrates.berkeley.edu:7015/e-Berkeley.policy.html).
B.1) Can your application utilize e-Berkeley authentication (Kerberos/AWS) and authorization interfaces (LDAP)?
B.2) Can your application utilize authorization rules based upon role information found in or derived from LDAP? If so, is the role information accessed in real time, or does your application store a local copy?
B.3) What precautions does your application take to avoid security compromises such as denial of service attacks?
Applications working in the e-Berkeley architecture will primarily share data using XML. In cases where there is not yet a standard schema, it is important to understand which schema(s) the application will use for communicating with other systems.
C.1) What data exchange formats and standards does your application provide?
C.2) How is your application setup to exchange data? Does your application have an Enterprise Application Integration (EAI) component for data exchange with other systems?
|
Send comments about this website or the ITATF to: ita@socrates.berkeley.edu | Website revised: 13 September 2001 |