1
|
<!--
|
2
|
* metacat-architecture.html
|
3
|
*
|
4
|
* Authors: Michael Daigle
|
5
|
* Copyright: 2009 Regents of the University of California and the
|
6
|
* National Center for Ecological Analysis and Synthesis
|
7
|
* For Details: http://www.nceas.ucsb.edu/
|
8
|
* Created: 2009 January 19
|
9
|
* Version:
|
10
|
* File Info: '$ '
|
11
|
*
|
12
|
*
|
13
|
-->
|
14
|
<html>
|
15
|
<head>
|
16
|
<title>Metacat Service Based Architecture</title>
|
17
|
<!-- unfortunately, we have to look for the common css file in the
|
18
|
user docs directory. This is because the user docs deploy to
|
19
|
the top level of the metacat docs on the knb web server -->
|
20
|
<link rel="stylesheet" type="text/css" href="../user/common.css">
|
21
|
<link rel="stylesheet" type="text/css" href="./default.css">
|
22
|
</head>
|
23
|
|
24
|
<body>
|
25
|
<table class="tabledefault" width="100%">
|
26
|
<tr>
|
27
|
<td rowspan="2"><img src="./images/KNBLogo.gif"></td>
|
28
|
<td colspan="7"><div class="title">KNB Software Development Guide: Metacat Service Based Architecture</div></td>
|
29
|
</tr>
|
30
|
<tr>
|
31
|
<td><a href="/" class="toollink"> KNB Home </a></td>
|
32
|
<td><a href="/data.html" class="toollink"> Data </a></td>
|
33
|
<td><a href="/people.html" class="toollink"> People </a></td>
|
34
|
<td><a href="/informatics" class="toollink"> Informatics </a></td>
|
35
|
<td><a href="/biodiversity" class="toollink"> Biocomplexity </a></td>
|
36
|
<td><a href="/education" class="toollink"> Education </a></td>
|
37
|
<td><a href="/software" class="toollink"> Software </a></td>
|
38
|
</tr>
|
39
|
</table>
|
40
|
<br>
|
41
|
|
42
|
<table width="100%">
|
43
|
<tr>
|
44
|
<td class="tablehead" colspan="2"><p class="label">Metacat Service Based Architecture</p></td>
|
45
|
<td class="tablehead" colspan="2" align="right">
|
46
|
<a href="./query-caching.html">Back</a> | <a href="./index.html">Home</a> |
|
47
|
<a href="./utilities-classes.html">Next</a>
|
48
|
</td>
|
49
|
</tr>
|
50
|
</table>
|
51
|
|
52
|
<div class="header1">Table of Contents</div>
|
53
|
<div class="toc">
|
54
|
<div class="toc1"><a href="#Overview">Overview</a></div>
|
55
|
<div class="toc1"><a href="#BaseService">Extending BaseService Class</a></div>
|
56
|
<div class="toc1"><a href="#ServiceService">Controling Services With ServiceService Class</a></div>
|
57
|
</div>
|
58
|
|
59
|
<a name="Overview"></a><div class="header1">Overview</div>
|
60
|
<p>Metacat is migrating toward a service based architecture. Basically,
|
61
|
what this means is that any internal service that Metacat provides should be
|
62
|
represented in a singleton class that extends the BaseService class.</p>
|
63
|
|
64
|
<p>There are a few basic questions that can be asked when you are creating a
|
65
|
class to decide if it should be a service.</p>
|
66
|
<ul>
|
67
|
<li>Does this class perform some action repeatedly throughout the lifetime of
|
68
|
the Metacat application?</li>
|
69
|
<li>Does it make sense for this class to cache certain information? This is
|
70
|
typically information that is accessed often and seldom changes. For example,
|
71
|
system properties rarely change and are constantly being accessed. (Thus the
|
72
|
PropertyService class.)</li>
|
73
|
<li>Would it make sense for the information in the class to be refreshable? Note
|
74
|
that this is not a strict requirement, since, as we will discuss, a class can
|
75
|
declare itself to be non-refreshable. A good example of a non-refreshable
|
76
|
class might be a database service. If core database information changes,
|
77
|
that usually requires a system restart, and not a service refresh.</li>
|
78
|
</ul>
|
79
|
|
80
|
<p>Any of these could signify the need for a service. Note that another option
|
81
|
is to create a utility class. Utility classes are singletons that have static
|
82
|
methods and less state requirements. See the
|
83
|
<a href="./utilities-classes.html">Utilities Classes page</a> for more information.</p>
|
84
|
|
85
|
<a name="BaseService"></a><div class="header1">Extending BaseService Class</div>
|
86
|
<p> All Services extend the BaseService class except the ServiceService class (discussed
|
87
|
next). </p>
|
88
|
|
89
|
<p>Currently, BaseService defines three methods:</p>
|
90
|
<ul>
|
91
|
<li> refreshable() - a package level abstract method that reports whether the class can be
|
92
|
refreshed. This has package level access because we only want ServiceService to be
|
93
|
able to access this information. You will need to decide at implementation time
|
94
|
whether it makes sense to refresh your service and return the appropriate boolean from
|
95
|
this method.</li>
|
96
|
<li> doRefresh() - a protected abstract method that performs the service refresh. It is
|
97
|
protected because it should only be called by the refresh() method (see next). Typically,
|
98
|
an implementation of the doRefresh() method updates any cached values in the service and
|
99
|
performs any appropriate state-specific service updates.</li>
|
100
|
<li> refresh() - a package level method that calls refreshable() and doRefresh(). It has
|
101
|
package level access because we only want the ServiceService to be able to refresh the
|
102
|
service</li>
|
103
|
</ul>
|
104
|
|
105
|
<a name="ServiceService"></a><div class="header1">Controling Services With ServiceService Class</div>
|
106
|
<p> The ServiceService class is a exception to the BaseService extension rule. This service
|
107
|
controls all other services. It maintains a registry of available services. </p>
|
108
|
|
109
|
<p>Some of the methods available via ServiceService are: </p>
|
110
|
<ul>
|
111
|
<li>registerService() - register a service by sending the service name and an instance of
|
112
|
the service. </li>
|
113
|
<li>refreshService() - refresh a service by name.</li>
|
114
|
</ul>
|
115
|
|
116
|
<br>
|
117
|
<a href="./query-caching.html">Back</a> | <a href="./index.html">Home</a> |
|
118
|
<a href="./utilities-classes.html">Next</a>
|
119
|
</ul>
|
120
|
|
121
|
</body>
|
122
|
</html>
|