CASE DESCRIPTION

University information systems are specific in the scale of various data produced and processed by different groups of users. E-business systems used by companies to communicate their business data with their partners usually exchange just a few types of business documents, such as orders, stock quotes, or invoices. Even though these documents change a little over time, there is no dramatic need to keep adding new types of them to cover other business needs. Nevertheless, in the university environment with many diverse and changing activities, there is high demand for information system flexibility. New services for new groups of people need to be designed and redesigned continuously. Therefore, there is need for effective means to build user-to-system or system-to-system interfaces. An on-going growth of the information system has to be taken care of.

In order to manage a growing system, it might be useful to have a metasystem that defines and manipulates the underlying information system. Information systems usually contain one or several databases where data are stored. For each piece of data in any of the databases, the metasystem would need to have a description (metadata) (Tannenbaum, 2001). There exists an object-oriented mechanism that may be used to define the metadata and provide means to access the data based on the descriptions.

The information system that is being developed at the Brno University of Technology uses the concept and concept view definitions presented in this case. Concepts are used to describe data in object-oriented fashion and concept views are used to describe more complex views on interrelated data (Amble, 2001). Since the definitions are always accompanied with human readable navigation and support texts, it is possible to use them as metadata for generation of Web enabled services for human users or for system-to-system communication.

It is expected that using a metasystem to define, redefine, refine, and generate underlying system speeds implementation time and improves quality of the resulting expanding system. This is because it should enable the project team to focus on the services that need to be offered to users instead of continuously having to program the services at low level with many chances of mistake.

The IT department decided to base the solution on open technologies. The main one of them is XML (Extensible Markup Language) used for platform-neutral representation of complex data (Smolik, 1999; Birbeck, 2001; Ray, 2001; Extensible Markup Language (XML), 2002; Learn XML, 2002). Since there was just a little experience with XML, the IT department requested expertise from the local company that had already two years experience using XML in commerce applications. The company provided its Java, XML, and XSL based Web-application framework with extension that enables XSL style-sheets to be used for generation of the XSL style-sheets used to provide the system Web-pages (McLaughlin, 2001; Tidwell, 2001; XSL Transformations (XSLT), 2002).

Since the system developed is always defined in metadata on the metasystem level, it is possible to generate application not only for the provided applications framework, used for the pilot, but for other available application frameworks or servers. That ensures independence of the resulting solution on a specific platform.

The whole business model is built on the provider company's model of information system development where there are two fundamental partners. One is an experienced technology provider but knows a little about the problem domain of the resulting application. And the other has very good know-how in the problem domain, but doesn't have much experience with the technologies. Either of the partners may, for specific projects, outsource the knowledge and work of the other. In the case of this pilot project, the IT department contracted the provider to outsource the technologies, but itself it is taking care of defining the university information system know-how.

The following subsections provide closer look on the technologies used to satisfy all the project requirements.

Conceptual Model

This section presents the fundamental mechanism that has been used for object-oriented description of data for the pilot project and later for the whole university information system. It might get little more technical, but on the other hand, may serve as a good background for understanding the implementation side of the case.

The metasystem uses descriptions, called concepts, to provide static views of systems it defines and generates. The concept definitions were first employed in the G2 object-oriented database system. The G2 model of concepts provides the most complete picture of what could be implemented at the metasystem level to describe data of processed in systems. Even though the current version of the metasystem implements only part of the specification, it is presented here in the full scale.

Concept Definition

CDL (Concept Definition Language) is the specification language for the conceptual object modelling of G2 system applications. It exists in two syntax forms - the textual form and UML. The object model consists of objects. An object is an ordered tuple of property values. Each property has name and data type. Concept is the Cartesian product of the named property data types. For the time being, concept is equivalent to the well-known notion of class, but with expanded semantics. Each property can be parameterized, i.e., each property can have an arbitrary number of parameters. Each parameter must also have some name and data type.

An example could be a Person object. Each person can have a list of names, a family name, and a birth date. Concepts are used to define objects. The following concept defines the names Name, Family, and DateOfBirth as properties with their corresponding data types String and Date. The Name property is parameterized. The Order parameter is used to define the order of person names.

 Concept Person Properties Name(Order: Integer):   String Family: String DateOfBirth:   Date End   Concept 

It is not stated whether the property is a date or an algorithm. The concept defines the interface of the object for a user communication. The implementation is defined elsewhere.

The basic set of elementary data types includes Byte, Integer, Long, Single, Double, Currency, Date, String, and Boolean.

Relationships and Collections

The model consists of objects, nevertheless objects do not exist separately. In opposition to the relational model, each object can define possible relationships to other objects. Two kinds of relationships are distinguished: relationships 1:1 and relationships 1:N.

The 1:1 relationship definition expresses that one object, an owner of the relationship, is bound to another object, member of the relationship (for example, a person has usually one father). The 1:N relationship expresses that one owner is bound to a (possibly empty) set of members (a person and its children). The way the model expresses relationships is shown below, but first collection of objects need to be defined.

The natural purpose of objects is to establish collections. For example, some person has a collection of children or some document has a collection of lines. Further, it should be noticed that collections of objects could have properties themselves (i.e., an average age).

An object and its collection can be defined in one concept (here the notion of concept starts to differ from the one of a class).

 Concept Person/People Properties Name(Order:   Integer): String Family: String DateOfBirth: Date Father: Person Children: Persons AverageAge:   Integer [Where=Col] End   Concept 

Because concepts define both objects and collections of objects, there is one name for a single object (concept name) and another name for the collection (concept collection name). In the example, one person is defined under the name Person and the collection of people under the name People. To be able to distinguish between properties of a single object and of its collection, the Where attribute may be used in the property definition. This attribute can have values Alone, Col, or (Col, Alone). It means that the property belongs to a single object, to a collection, or to both. Usually, most properties belong to a single object, and therefore the Where = Alone attribute is implicit.

An extent is a very important collection type of the model. It is a collection of all objects of the same concept. The database system maintains this collection automatically. Extents are the main entry points to object-oriented databases.

Relationships are defined as properties with a data type equal to either concept name or a concept collection name. If the concept name is used then the 1:1 relationship is established and if the concept collection name is used then the 1:N relationship is established.

In the above example, the relationship Father is 1:1 relationship to the object Person and the relationship Children is 1:N relationship to the collection of People.

Object-Oriented Data Access

The previous section shows how data in a system may be described on the metasystem level using the concept descriptions. This section will explore way how the data may be expressed as instances of concepts (objects) and how collections of interrelated objects may be expressed (Dodds, 2001). Further, the XML Data Access (XDA) query language will be shown. XDA was developed at the technology provider company and has been used on several e-commerce and e-business projects (Smolik, 2000). The system realized at the Brno University of Technology uses XDA to enable flexible data access to various types of databases. Moreover, XDA is complemented with a web services access control methodology (WSAC) that allows limiting access to objects based on user and group rights to services and objects within those services. WSAC was also developed by the provider company and will not be explained within the scope of this case, nevertheless it is very useful for controlling access of many different groups of people to various parts of a university-wide information system.

Expressing Objects in XML

There are two ways how data in a database might be accessed. Either they could be accessed directly by application objects via an object interface, or they could be accessed externally through an XML interface.

Each object or a collection of objects of a certain concept may be expressed in XML exactly as defined in the concept definition (Carlson, 2001). The property values of the objects are enclosed in elements tagged with the corresponding property names. All the property value elements are then enclosed in an element tagged with the name of the corresponding concept. For example, a sample object of the Person concept may look like the following:

 <Person o>   <Name>Drundun</Name> <Family>Hallway</Family>   <DateOfBirth>1955-05-16</DateOfBirth> </Person>   

Similarly, individual objects may be wrapped into collections of objects using the concept collection name also defined in the concept definition. Then the individual person objects are enclosed in the corresponding collection element:

 <People> <Person   o> <Name>Drundun</Name>   <Family>Hallway</Family>   <DateOfBirth>1955-05-16</DateOfBirth> </Person> <Person   o> <Name>Miranda</Name>   <Family>Hallway</Family>   <DateOfBirth>1959-11-07</DateOfBirth> </Person>   </People> 

Concept Views

The simple objects presented so far could be also expressed as simple rows of a table as in known from result-sets in relational databases. Nevertheless, in the world of objects there need for much more than just this. It should be possible to express complex data structures corresponding to views of related objects. Concept definition allows properties to define relationships with other concepts. According to the Person concept, each person may have a father and several children.

That may be expressed in the following way:

 <Person o>   <Father o> <Name>Eduard</Name>   <Family>Hallway</Family>   <DateOfBirth>1926-01-21</DateOfBirth> </Father>   <Children> <Child o> <Name>Monica</Name>   <Family>Hallway</Family>   <DateOfBirth>1978-10-29</DateOfBirth> </Child>   </Children> </Person> 

Since objects are often interrelated in complex way, mechanism is needed that would allow for accessing only the data corresponding to few relationships that are of interest. The view of related objects called a concept view is defined in a concept view definition. Definition for the above view might be the following:

 <ConceptView   name="PeopleWithFathersAndChildren"> <Include concept="Person">   <Include relationship="Father"/>   <Include relationship="Children"/> </Include> </ConceptView>   

XML Data Access (XDA)

In order to communicate with an object-oriented database a query language is needed. There could be three types of queries. Queries that get data, update/create data, or delete data. Each query specifies which concept or concept view defines the data of interest. The get data queries further include constraints limiting the scope of the selected data. The update data queries include the data to being updated or inserted, and the delete data queries include the necessary object ids that identify the objects to be deleted.

For example to obtain collection of all Person objects available the following query may be used:

 <GetData concept="Person"/>   

To obtain collection of all the people, whose family name is "Hallway," the following query could be used:

 <GetData concept="Person">   <Where> <Eq property="Family" value="Hallway"/> </Where>   </GetData> 

Concept view queries are built similarly. To obtain all people with their fathers and children the following might be an appropriate query:

 <GetData   conceptview="PeopleWithFathersAndChildren"/> 

The concept view queries might also be constrain on any level of the included subtree as in the following example, which would provide all people whose child's name is Monica.

 <GetData   conceptview="PeopleWithFathersAndChildren"> <Where> <Eq   property="/Person/Child/Name" value="Monica"/> </Where>   </GetData> 

Finally, here are examples of both an update data and delete data queries:

 <UpdateData concept="Person"   insert="yes"> <Data> <Person o>   <DateOfBirth>1955-05-17</DateOfBirth> </Person> </Data>   </UpdateData> <DeleteData concept="Person"> <Data> <Person   o/> <Data> </DeleteData> 

These were just simple examples of concept and concept view queries demonstrating the object access mechanism usable to access data in a database. This exact mechanism was used for the pilot project to provide XML-based access to data in various relational databases and has been used both as the XML interface for the faculties to the central system and as source of data from the databases to be visualized in the user interface that was built.

Web Services

Web services could be considered as either human or machine interfaces to information systems. Web services are accessible over the Internet where human users use browsers to view HTML pages or other systems communicate XML documents. XDA mentioned in the previous section serves as a Web services provider for other systems to access data in the central university system, and it also enables the business logic tier to access data in an object-oriented fashion.

Figure 1 shows general Web services provider architecture. On the right side, each Web service accesses data in various data sources, such as databases or directly accessible enterprise information systems. On the left side, each Web service communicates with the outside world. It could present its services directly to users via the Presenter, which transforms the pure data into appropriate Web pages, and to other systems, it provides its services via the Listener, which listens for service requests and provides service replies. All communication with the outside world is based on the HTTP protocol, and the data is represented either in some visualization format for users (HTML, …) or in XML for other systems. Any Web service may use other Web services to obtain necessary information or to have computations done. Web services are mostly seen as services provided by a machine to another machine, nevertheless, they could be also seen as services directly offered to human users, because the logic of the service is equivalent in both cases, only the visualization part is being added for the comfort of the user. And further, if there is a good service description then it means that the graphical user interface could be easily generated. Web services therefore might be considered as both machine and human accessible.

Figure 1: Web Services Provider Architecture

Web services enable communication of data among companies or independent parts of an organization (i.e., business entities) (Cerami, 2002; Oellermann, 2001; A Platform for Web Services, 2002). Each business entity may offer their Web services to other entities. Because the use of Web services has to be easy and connecting to new services needs to be simple, there will be standard ways to describe, offer, and find services. The most promising language for description of Web services is the XML-based Web Services Description Language (WSDL) jointly developed by Microsoft and IBM. Further, the Universal Description, Discovery and Integration (UDDI) specification describes Web services and programmatic interface that define a simple framework for describing any kind of service, and finally SOAP as the transfer wrapper (Graham, 2001; Universal Description, Discovery and Integration (UDDI), 2002).

As mentioned earlier, there are two generic types of a Web service. Ones that provide access to data and ones that do computations. Example of the first case could be sending and an order or receiving an invoice. Example of the second case could be requesting price for sending a package of specified size and weight from place A to place B. Web services that access data could be defined in terms of concept views that were presented above. Web service could, therefore, be defined as a concept view enriched with documentation texts and other information related to level of access to objects within the service. This enriched description could be considered as the service description. Each service thus defines what view of interrelated objects is available within that service. For each concept in the service definition defines what operation (list, create, edit, delete) is allowed. The service may define implicit filters on accessible objects and other information needed for proper documentation or visualization. Further constraints on what objects could be accessed by what users within given service are put by a separate mechanism (Web services access control) mentioned earlier.

Metasystem

Previous sections discussed ways to represent data about a system (metadata). From the metasystem point of view there are several types of metadata:

• metadata that define the data in the systems (concepts)

• metadata that define views on data with their hierarchical relationships (concept views)

• metadata that define Web services (service descriptions)

In a way, service description in its complete form may take form of a personal process. Personal process is then the activity that the user performs in order to take a full advantage of a service, for example, the service "Send purchase order." From the data perspective, an XML document containing proper order head and order items needs to be sent. For any user, preparing such a document is a process of entering order-head information and adding items. This personal process information would be also needed as part of the service description, so that suitable editor may be generated for each service.

In the future, attempts to add metadata that would define organizational processes should be made. Organizational process could be seen as the process of using different Web services by different users in order to reach an organizational goal. Usually, organizational processes are executed by individual users implicitly, and they have no explicit definition, or they are hard-wired in the system implementation. By making organizational processes explicit by representing them on the metasystem level, it could be expected that the continuous growth of the underlying system could be better controlled.

The current implementation of the metasystem, as shown on Figure 2, uses concept definition to define objects manipulated by the system, uses service descriptions (with concept views included) to define Web services with their corresponding personal processes. Using the Generator, metasystem generates several parts of a system. The XML interfaces to services are the full-blown Web service listeners presented in the previous section. The User interfaces to services are the user Presenters for each Web service. All the system parts are generated from a universal description to a specific system program code using the Generating styles. There are special styles for generation into different target environments. The current version of the metasystem generates XML service descriptions and XSL style sheets used by the provider company's applications framework, but it is possible to add generating styles to generate applications in Java, JSP, ASP, PHP, WebSphere, WebLogic, or Oracle AS.

Figure 2: System Generated by a Metasystem

Based on both concept definitions and service definitions, the metasystem is able to generate not only proper interfaces, but also documentation. In development and maintenance of a system offering wide range of services and encompassing many different types of data, there is a high need for good documentation. For this reason, the concept definitions are further complemented with human readable descriptions of all properties and concepts themselves, so the complete information as what the data means is presentable.