Information Technology Reference
In-Depth Information
some special data, we combine these two methods
of RDB and XML. For example, we classify the
user's properties into four sets: common data such
as login name and password, admin data such
as ID card number, user data such as email and
gender, and system data such as statistical data.
As for the admin data, user data and system data,
in order to keep the extensibility, we use the XML
format to store them.
In the data access layer, there exist three inter-
faces: one for relational database, one for XML
database and one for file set. For the relational
database, we use Spring to configure the database
connection pool. There are two kinds of database
access methods provided. The first is to use
JDBC to connect the database and SQL to query
the data. The second method is to use Hibernate
to package the database. The second interface is
Hibernate which makes it seem as if a database
contains plain Java objects. For the XML data-
base, we use XQuery that is a language from the
W3C designed to query and format XML data.
And for the file set, we use SOAP/http to upload
and download files.
Above the data access layer is the logic layer.
In this layer, we implement the business logic of
the cloud functions using different data from the
data layer through corresponding access methods
provided by the data access layer. Above the logic
layer is the ESB layer which is based on SCA.
By using ESB, the business logics of the cloud
functions can be implemented in different inter-
faces. The detail functions of each cloud will be
introduced in the later sections.
The event response layer is between the user
interface layer and the ESB layer. We provide
two basic interfaces to interact with the users in
the user interface layer: one is the common Web
interface which is used while the cloud is running
as a standalone system, and the other is Web service
interface which is used while the cloud is running
as a remote service on the Internet. When the
user sends a request to our cloud through the user
interface, the event response layer is invoked. In
this layer, we create filters that perform privilege
verification inside different actions as defined
in Struts. After verification, this layer invokes
different functions through ESB and responds
accordingly as different results are returned. For
each of the clouds, we give out the specifications
for them. The security, testing and maintenance
column in the figure is similar to the techniques
discussed in the previous section.
For each of the clouds, we use our framework
to develop them, which will be described in sec-
tion 6. The framework can provide the basic au-
thentication, menu and frameset-based interface.
5.1. CDOI
The Digital Object Identifier (DOI) System is
for identifying content objects in the digital en-
vironment, just like DNS for domain names. DOI
names are assigned to any entity for use on digital
networks. They are used to provide up-to-date
information, including where they can be found
on the Internet. Information about a digital object
may change over time, including where to find it,
but its DOI name will not change. However, there
exist several problems of using DOI:
•
Naming rule: the length of DOI name is of
variable length and can reach 128 bytes,
which is not efficient for computer system
to store and process.
•
Name generation: it requires human inter-
vention, which is impossible to deal with
considering the massive user-generated
content based on Web2.0.
•
Integration: DOI cannot support the inte-
gration of the digital resources distributed
on different repositories because these re-
positories may have the same digital ob-
ject identifier for different resources. For
example, they probably use the internal
ID such as an auto-incremental number to
name a digital resource, which may cause
the problem of ID conflict.
Search WWH ::
Custom Search