 |
|
DAILY NEWS AND INFORMATION
FOR THE GLOBAL GRID COMMUNITY / JULY 7, 2003: VOL. 2 NO. 27
|
Special Features:
DEFINING A CONCEPT FOR A SMART
NEIGHBORHOOD, PART IV
by K.S. Venkatram, computer engineer, University Of
Poona
"Defining a concept for a Smart Neighborhood - Integration Scenarios"
This article introduces Web administration and service in a series about
"Defining a concept for a Smart Neighborhood - Integration Scenarios". These
articles are not a published solution. Rather, they introduce the reader to a
concept for a smarter neighborhood and guide the user through a comparative
analysis and extensibility of a sensor-controlled network against what is
ordinarily presented in Grid computing.
The roots of this concept are due to my involvements and looking ahead when
development plans and limited focus rule the solutions delivered. I would like
to state to readers who have an introductory knowledge of these areas, that
they can find an alignment in the proposal and involve themselves in this
solution. The enterprise can accommodate any genuine effort and orientation
from the reader.
Introduction to help a reader preview the ELS proposal
The proposal for the Enterprise Location System (ELS) is also described as
a
proposal for a "sensor-controlled network (SensorCN)" or a "sensor-controlled
enterprise (SensorCE)". The design context and specification of the sensor-
controlled network is based on Location Entities and also support from
extensible sensor-controlled services.
The enterprise network resources are typically hardware, software
applications, performance measurement objects and network manageability
objects in the enterprise network or grid.
The enterprise network is a consolidation of mixed network computers, mixed
network resources and mixed network services. In this mixed grid, the
Enterprise Location will be a network address or DNS or network name for a
network computer or server participating in resource tracking. The Enterprise
Location will be identified with the help of sensors, resource tracking and
access.
The Enterprise Location Protocol defines the network transport and service
in
querying resource availability in the enterprise grid.
The Enterprise Location Server (ELS) will be a management server that
participates in the Enterprise Location System. An Enterprise Location Server
will support registration, discovery and monitoring of sensors in the
enterprise grid. Sensor location, registration, access information will be
stored and synchronized through a database called the Sensor Resource
Database. The Enterprise Location Server is a configurable entity that
controls sensor signaling and collaboration in the enterprise grid.
The Enterprise Resource Server (ERS) is an Enterprise Location Server (ELS)
that helps collect the list of resource definitions from the various network
computers and adds the same to an Enterprise Resource Database. The Enterprise
Resource Database model will be that of a relational database with tables,
stored procedures, and database support to host information about mixed
resources in an enterprise network or grid.
The Enterprise Resource LDAP Server (ELRS) is an Enterprise Location Server
(ELS) that helps collect the LDAP resource definitions from the various
network computers and adds the same to an LDAP Directory. The Enterprise
Location System uses the ELRS for publishing resources in a LDAP Directory.
The LDAP-based resource model will describe the resources using the LDAP
schema.
Like typical network support and relationships built through domains, the
Enterprise Location System also defines enterprise support and resource
neighborhoods through the Enterprise Location Domain. The Enterprise Location
Domain implementation registers sensors, pooled sensors and services with a
Location Server like the Enterprise Resource Server (ERS) or Enterprise
Resource Server + Enterprise Location Domain support (ERS-ELD) or Enterprise
Location Server (ELS). Grid associations built on the Enterprise Location
Domain concept enhance the searching, tracking and support functionality in
the sensor-controlled network.
The Enterprise Location System will support interoperability, enterprise
grids
and varieties of resource neighborhoods through the Enterprise Location
Domain. The Enterprise Location Domain associates a DNS name or domain name
with the LDAP support (ELRS-ELD). Many Grid associations today need this DNS
namespace integration for searching, tracking and support functionality in the
network. This means from the understanding outlined so far, along with the
LDAP directory naming and indexing, the ELRS-ELD feature will build a DNS like
Enterprise Location directory that will be maintained on the ELRS and through
notification support synchronized across the network 's ELRS
installations.
To introduce the reader to "Location entities" - Location entities are the
network computers in the network that are installed with sensors. The Location
entities are classified as One-way or Two-way systems.
Sensors are qualifying agents in the Enterprise Location System that are
placed on the Location entities classified as One-way or Two-way systems. A
Sensor qualifies a single Location entity for a resource query or qualifies a
set of Location entities for a resource query.
- One-way systems are Location entities running sensors; the resources are
tracked by queries sent from the network user or Administrator's machine to
the sensors. The network user does either configure the sensors to be queried
or relies on querying one sensor which conferences pools of sensors.
When querying a sensor that conferences various related sensors, the
network
user or Administrator does not expect to know which related sensors service
the request and respond. So the sensor-control is single or multi-purpose for
querying resources.
- Two-way systems are unlike One-way systems, these sensors are One-way
systems and additionally connect into the network and play the role of
transmitting messages independently to the network user or Administrator's
machine. The Two-way sensors also enhance the location system by forwarding or
retrieving the information from other Location entities and have some
association in criticality or resource definitions.
The Enterprise Location Service Catalog (ELSC) is a contextual
infrastructure
that designs manageability of the smart neighborhood through a Directory or
Database Map and synchronizes this service information across the sensor-
controlled network. The management information from the sensor-controlled
network computer will be stored, modelled through a "Database or Directory
map, this map is also termed as a Service Catalog. The Database Service
Catalog or schema model will be supported by ELS-ERS infrastructure. The
Directory Service Catalog or schema model will be supported by the ELS-ELRS
infrastructure.
Easy reference and introduction to the Smart Neighborhood has been published
as a series in the Grid site. The URLs for the series are listed below:
1. http://www.gridtoday.com/03/0602/101487.html
2. http://www.gridtoday.com/03/0609/101511.html
3. http://www.gridtoday.com/03/0616/101543.html
4. http://www.gridtoday.com/03/0623/101584.html
Preview of the Enterprise Location System and the Enterprise Data Center
Services market:
Today many companies and applications rely on other mechanisms to integrate
the local and remote world or neighborhood. We have many companies supporting
this integration of the local and remote world through:
1. Directory Services and related modeling
2. Web Services and related modeling
3. Component Instrumentation and related modeling
Any of the above services like networking infrastructure, for some interest
will come across as what connects the local and remote world. The important
question at this stage is to ask, what happens to time spent developing
products that do not connect well enough? As a related issue, the additional
question to the industry is due to these issues, how often is the implication
of this on the customer and not on the product development company?
As an author, in stating this for most facts, the models by themselves are not
issues but the integration and infrastructure efforts are high. The focus in
Web management and services though important to many companies will have
implications for old solutions and thereon integration with the local and
remote world.
A Data Center installation today requires manageability to synchronize the
data definitions, schema and status across the enterprise. The integration of
the ELS with Web services could serve principles of Web Management for a Data
Center installation.
In the scenarios of co-existing with existing Enterprise Data Center Services
and Web Services, the ELS supports options for network users to integrate the
sensor, connection point to existing Enterprise Data Center Services.
On integrating a sensor, connection point with existing Enterprise Data Center
Services and Web Services, this functionality then permits the network user to
decide or dynamically control the Enterprise Data Center solution. The
integration helps the network user to take ownership of the Data Center
solution. Additionally the integration with the ELS will ease effort to
integrate with other Data Center Services, own the manageability in the Data
Center solution and coexist in mixed grids.
A. The proposal for the Enterprise Resource Server in a Data Center
installation can be split as service requirements to support the following:
1. Any deployment for a Data Center and Enterprise native database services
rely on controlled locatability specifications. Locatability is defined
commonly by Schema Masters. The Schema Master supports integration of
independent scope in a neighborhood. Resource descriptions or data definitions
in an enterprise network is commonly distributed across the network, Data
Center services today support resource updates from independent network
computers or servers to the Schema Master. The Schema Master relies on an
update guideline to synchronize the Data Center descriptions and resources
across the network.
2. A common Service to detect the Schema Master in the ERS neighborhood is
presented in the ELS - Illustration.
Illustration I - Detect the Schema Master:
The following illustratation shows how to detect whether a server is a Schema
Master:
- Read the els_ERSRoleOwner property of the schema container for the ERS. The
els_ERSRoleOwner attribute reports the distinguished name/DN or the
els_dnsHostName of the server object defined as the schema master.
- If the els_ERSRoleOwner attribute reports the distinguished name/DN of the
server object, then get the els_dnsHostName property of the server object.
This is the DNS name of the server "running as the schema master.
- Specify the DNS name of the schema master as the server and the DN as the DN
of the schema container to bind to the schema master. For example if the
server is called RESOURCE_DOMAINCONTROLLER_COMMON with the DNS name as
RESOURCE_DOMAINCONTROLLER_COMMON.entnet.com and the schema container DN as
cn=schema, cn=configuration, dc= entnet, dc=com, the Path will be as follows:
LDAP://RESOURCE_DOMAINCONTROLLER_COMMON.entnet.com/cn=schema,
cn=configuration, dc=entnet, dc=com
- On binding to the server, the ERS Schema Master sets online state to update
and synchronize the schema changes with installed Enterprise Resource Servers
that are secondary Schema Owners.
3. Schema synchronization is an existing issue for mixed grids. Schema updates
may not be uniform across all ERS servers and domain controllers. To address
such inconsistencies and prevent conflicts, the schema update guideline will
rely on controlled support. In order to distribute and synchronize schema
updates, entities like ELRS, ELS and sensors help Distribution and
Synchronization support for resources. These details are available in the
illustrations.
Illustrations II - Pre-detection:
This documemtation illustrates how the ERS configures the services to update
the schema.
- While installing an ERS/ES in a LDAP directory supported scenario, the
directory schema will be verified for attributes such as:
- The schema for the O/OU container, that this ERS is associated with, should
support a els_ERSRoleOwner property. If the schema attribute is there, then,
proceed without any additional effort. If the schema attribute is not there,
then extend the directory schema for the O/OU container to support a
els_ERSRoleOwner property.
- The els_ERSRoleOwner property will report the distinguished name/DN of the
server defined as the schema master. The other option is to store the
els_dnsHostName of the server defined as the schema master.
- The schema for the server object should include a els_dnsHostName property.
This is the DNS name of the server and will be used to detect the schema
master. If the schema attribute is there then, proceed without any additional
effort. If the schema attribute is not there, then extend the LDAP Directory
schema for the server object to support a els_dnsHostName property.
- The schema for the server object should include a els_ERSRoleMember
property. This is the either the DNS name or is a network addresss that the
ERS wishes to make available to the enterprise network.
If the schema attribute is there then, proceed without any additional effort.
If the schema attribute is not there, then extend the LDAP Directory schema
for the server object to support a els_ERSRoleMember property.
Illustration III - Enforcing a schema master in the ERS installation:
It is necessary that while installing the ERS server in the network, the
Administrator define whether the ERS server is to a schema master.
- The Administrator will define the Schema Master while installing the ERS
member server in the network. Along with support for pre-configuration, due to
the network inclusions/updations, the Schema Master support can switch from
one ERS server to another ERS server. This specific functionality support is
addressed through the ELD support.
- In the ELS an ERS member server expects to rely on ELD support for
Enterprise Domain and Schema Master information. An ERS member server will
read the ELD database for information about the ERS domain. The ELD database
will manage network information about the ERS members with an
"els_ERSRoleMember" property, and importantly maintain a record for an
"els_ERSRoleOwner" property. The "els_ERSRoleOwner" database property or the
Schema Master property associates the distinguished name/DN of the server or
the els_dnsHostName of the server.
If the ERS setting for the schemaclass is ServerSchemaMaster,then the ERS will
on startup execute an application running in the context of a privileged user,
that issues an LDAP write setting the operational els_ERSRoleOwner attribute
to become a Schema Master to the root container for the ERS. This will
initiate automatic transfer of schema master rights from the existing server
to this one.
If the ERS setting for the schemaclass is ServerRole,then the ERS will on
startup execute an application running in the context of a privileged user,
that issues an LDAP read to identify the schemaMaster for that DC.
Illustration IV - Member detection of the Schema Master:
- While installing an ERS/ES member in a DNS only supported scenario, the ELS
will support funtionality to detect the Schema Master.
- An ERS member will send out a <read database for "els_ERSRoleOwner"> to the
ERS-ELD server configured. The ERS-ELD server will support an ELD database,
that will be read for the "els_ERSRoleOwner" attribute. The "els_ERSRoleOwner"
attribute guides the name of the Schema Master. On successful reads this
result will be returned to the querying member. On detecting the Schema
Master, an ERS member will rely on the ERS-ELD server to synchronize/update
current schema information.
- An ERS member will send out a <read database for "els_ERSRoleMember xxx"> to
the ERS-ELD server to get network information about any ERS server in the
network.
- An ERS member will send out a <addreg database "els_ERSRoleMember xxx"> to
the ERS-ELD server to register network information about the ERS server in the
network.
- An ERS member will send out a <delreg database "els_ERSRoleMember xxx"> to
the ERS-ELD server to delete network information about the ERS server in the
network.
- An ERS member will send out a <enforcereg database "els_ERSRoleMember xxx">
to the ERS-ELD server to enforce network information about the ERS server in
the network.
4. Service to detect the namespaces supported and naming conventions:
a. This service will need to identify the DN/FDN/FQDN of the network computer.
b. This service will need to identify the tree/domain/forest/context that this
network computer is part of.
c. This service will need to identify the DNS namespace integration. The
functionality expected is associating a DNS name along with the network
computer's Directory name. The DNS name association as part of the DN/FDN/FQDN
enhances the global root capabilities of the solution.
d. This service will need to identify the Schema Master. The Schema Master
identification will need to include relevant namespace information, the
LDAP/DNS/ELS namespace guidelines are included in the efforts to name, search
and manage database objects.
e. This service will need to identify the map to convert the vendor's
Enterprise Resource or Data Center names to the ELS Database model names.
5. Service to detect the features supported for schema updates and
synchronization. To start the decision making for this, it is necessary to
configure the role of the ELS Database Service on the ERS. The ELS Database
service supports functionality to administer the schema updates, directory
content updates in the ELS.
6. Service to design and configure a Database Services Connector:
A Database Service Connector is a concept that enables Enterprise Resource or
Data Center solutions to integrate information with the ELS Database solution
and extends the services available.
In the design and proposal for a Database Services Connector, the
implementation will need some configuration options to be defined for the
solution:
i. The Connector will need to know the directory or directories involved. The
Connector will also need to know the number of connectors that can be
installed on a host server.
ii. The Connector will need to know the names of the servers to be contacted
for synchronization. These are some classifications of synchronization,
Bidirectional synchronization, Selective attribute synchronization, Change
synchronization and synchronization of attribute level changes.
iii. The Connector will need to know the object classes to be included in the
synchronization process.
iv. The Connector will need to know the direction in which the synchronization
should occur.
v. The Connector will need scheduling information for the synchronization
process
vi. The Connector will need to know how deleted objects will be dealt with
vii. The Connector will need to know the list of attributes to be synchronized
and how the attributes map between directory services.
viii. The Connector will need to know which method is used for creating new
objects
ix. The Connector will need to know the authentication methods supported
x. The Connector will need to know the list of containers that will be
involved in synchronization and how they map between directory services.
xi. The Connector will need to define options and support performance
monitoring through custom performance objects and counters. Typical objects
and counters like Processor Performance monitoring objects, Memory Performance
monitoring objects, Disk Performance monitoring objects, Network Performance
monitoring objects, Resource objects and object classes for selective
attribute tracking sessions.
xii. The Connector will need to know the support for logging status details
for Replication events, Account Management events that occur during a
write/read of an object during replication, Attribute Mapping events that
occur while mapping attributes from one database to another, Service
Controller events that occur when the connector services are started, reset,
stopped and events for Database operations that occur while ELS services
access the database. This support is the "design focus and "heart" of the
proposal of this Web Administration article, the scope for this feature
interfaces conceptually with a Data Center Solution and importantly any LDAP
directory Solution".
The article describes implementing a Enterprise Web Management solution using
entities such as the "WebManagement_ConnectionPointService" and the "Web
Service". The Web Service that uses a WSDL definition to service information
connectors for Replication events, Account Management events, Attribute
Mapping events that occur during a write/read of an object during replication
and during the mapping attributes from one database to another. Networks are
known to solve work domain limitations by using implementations that
communicate with Web Services using request, request/response messages. The
smart neighborhood relies on the Enterprise Location Service Catalog (ELSC)
contextual infrastructure and Sensor-controlled infrastructure to implement
this solution.
The ELSC infrastructure interfaces with the Database Services to preprocess,
store, update and synchronize this information across the sensor-controlled
network.
The Sensor design and the sensor-controlled infrastructure:
To describe how the sensor recognizes the sensor connection points:
In the sensor-controlled network the sensor connection points will be defined
in a configuration file called the "enterprise.config" file. The configuration
will include entries for the various resource applications, services and
channels that describe the resource definitions.
The sensor will create an instance of the various resource connection points,
services and channels that describe the resource definitions. The resource
connection point will be of lifetime "extension". The sensor relies on the
resource connection point to collect information about resources. The
capability of the sensor to service resource queries is not static in scope
but extends through the inclusion of newer resource connection points.
1. We look at the application section for configuration options that support
an ERDb; the application section will identify the settings required for the
sensor to publish the resource definitions in the ERDb.
<application>
<directory 1>WEB</directory 1>
<global identifier format>
<refresh_global_identifier>
Disabled
</refresh_global_identifier>
<include_directory>
Enabled
</include_directory>
<Schema_Servicedirectory>
Enabled
</Schema_Servicedirectory>
<Web_Servicedirectory>
Enabled
</Web_Servicedirectory>
<refresh_include_directory>
Enabled
</refresh_include_directory>
<include_global_time>
Disabled
</include_global_time>
</global identifier format>
<global identifier>
SENSOR_2-WAY_ANYNODE
</global identifier>
</application>
In order to publish resources in an ERDb, the sensor will use the
Enabled or Disabled setting
in the application section. When this setting is enabled, the sensor will use
the connection point to describe the resources available and create an
industry conformant schema file for these resources. The schema file will be
used in processing the resource xml files and publishing the resources in the
required ERDb after suitable schema updates.
As there is now a remote understanding of the "heart for Web Administration
and Services", we proceed to review the Web service support for resources, the
sensor will use the Enabled or
Disabled setting in the application section. When this
setting is enabled, the sensor will use the
WebManagement_ConnectionPointService to describe the data definitions, schema
resources available and create a Web Service Definition Language file for
these resources. The WSDL schema file will be used in processing the Request,
Request/Response parameters for management of the Data Center network.
2. The server section will along other configuration options, describe the
identity of the Enterprise Resource Server (ERS) and the identity of the
Enterprise LDAP Resource Server (ELRS).
The functionality on an ERS will update, synchronize resource definitions and
information available on the sensor's network computer into an Enterprise
Resource Database.
The functionality on an ELRS will update, synchronize resource definitions and
information
available on the sensor's network computer into a LDAP Directory. In this
article we will focus on the Enterprise Resource Database model.
<resource>
<ip address>203.200.15.170</ip address>
<resourceserver>
<parameter name="hostname" value="RESOURCE_DOMAIN_COMMON"/>
<parameter name="domainclass" value="Server"/>
<parameter name="schemaclass" value="ServerSchemaMaster"/>
<parameter name="schemamaster" value="RESOURCE_DOMAIN_COMMON"/>
<wellknown
<parameter name="type" value="Windows2000.version"/>
<parameter name="lifetime" value=""/>
/>
<wellknown
<parameter name="type" value="Windows2003.version"/>
<parameter name="lifetime" value=""/>
/>
<wellknown
<parameter name="type" value="NetWare.version"/>
<parameter name="lifetime" value=""/>
/>
</resourceserver>
</resource>
The sensor invokes the Tracking_Submit function with the op-code "read
resources" or "read connector resources". The proposal for the
WebManagement_ConnectionPointService will extend the "read connector
resources" interface to the Database Service Connector. The "read connector
resources" will report the management of status details for Replication
events, Account Management events,Attribute Mapping events, Domain Service and
Service Controller events via Web Service Definitions.
When "read resources" or "read connector resources" successful, the ETA will
check the availability of resource definitions. On enumerating the various
connection points and checking for the resulting resource definitions, the
sensor follows these principles:
1. For each resource connection point with "resources defined" initialization
results, the Tracking_Submit request will invoke the connection point with the
"read resources" op-code. On being invoked with the op-code "read resources",
the connection point or WebManagement_ConnectionPointService_Submit extension
will link the ConnectionPointService.xml results file with the Tracking_Submit
function. The Tracking_Submit function will use this
ConnectionPointService.xml results file for location manageability by placing
it in the content directory. In the article the content directory for the
Enterprise Tracking Agent is "network computer
location:\\sensor\\content\\ConnectionPointService".
The WebManagement_ConnectionPoint will report "connector resources defined"
initialization results when the Data Center status has been enumerated. The
Tracking_Submit request will invoke the
WebManagement_ConnectionPointService_Submit with the "connector read
resources" op-code. On being invoked with the op-code "connector read
resources", the WebManagement_ConnectionPointService_Submit extension will
link the ConnectionPointService.xml results file with the Tracking_Submit
function. The Tracking_Submit function will use this
ConnectionPointService.xml results file for location manageability by placing
it in the content directory. In the article the content directory for the
Enterprise Tracking Agent is "network computer
location:\\sensor\\content\\WebManagement_ConnectionPointService". This xml
resultis made available for enhancing Schema Master features through Web
Administration. The Web Administration features are not integrated as an
implementation in the Smart Neighborhood, the well-defined industry effort in
"Web Services and Management" is sufficient to interface with the
ConnectionPointService.xml-WSDL mapping and resolve Schema Connector and
Synchronization inconsistencies and failures.
2. When the Tracking_Submit function preprocesses the resource xml file, the
results will be validated for success in parsing. If the results cannot be
processed by simple parsing techniques, the algorithm will process the content
of the results xml file by invoking the
WebManagement_ConnectionPointService_Submit function with the op-code "read
schema". When the invocation of the
WebManagement_ConnectionPointService_Submit function returns references to the
schema file, the ETA will place the resource schema file in the content
directory. If no schema is available, then the Tracking_Submit function will
place the ConnectionPointService.xml file with a
WebManagement_ConnnectionPointService.blob file in the content directory. This
WebManagement_ConnectionPointService.blob file will be processed without
interpretation and stored in the Enterprise Resource Database for binary
lookup or application results.
3. When the ETA calls the WebManagement_ConnectionPointService_Submit
function, if the resource definitions are available then the ETA will add the
results xml file and available xml schema file to it's collection of
enterprise content in the content directory. In the example this connection
directory is "network computer location:\\sensor\\content\\connections".
Feature note: If the ERDb extension to the sensor is defined, then the ETA
will add the results file, xml schema file and ERDb custom schema file, into a
content directory for storing these resource definitions in the Enterprise
Resource Database. In our example the content directory for ERS updates is
"network computer location:\\sensor\\content\\connections". As the ELS uses
XML formats for describing data, when resource definitions need to be
published in the Enterprise Resource Database, the xml schema file will need
to be converted to a ERDb custom schema file.
4. When the connection points have all been read for the resource definitions
then the Tracking_Submit function will invoke it's resource definition update
algorithm. The resource definitions will be transmitted to the ERS for parsing
and database storage. The sensor implementation will propose to address
success or failure of all transmissions to the ERS. The ERS will use available
schema .scm files to construct a parser. For any resource xml, the ERS
executes a parser, if parsing is successful the resource xml will be stored in
the resource class information, else if parsing is a failure, then the
resource-blob files will be stored in the resource class information.
Feature note: If the ERDb extension to the sensor is defined, then the ETA
will add the results file, xml schema file and ERDb custom schema file, into a
content directory for storing these resource definitions in the Enterprise
Resource Database. In our example the content directory for ERS updates is
"network computer location:\\sensor\\content\\connections". As the ELS uses
XML formats for describing data, when resource definitions need to be
published in the Globus Database, the xml schema file will need to be
converted to a Globus interoperable custom schema file.
5. The resource xml files define a namespace attribute for resource class
definitions and include information for integrating domain information with
the network name of the network computer installed with the sensor.
6. When the resource definitions and corresponding .xml file definitions are
parsed and successfully updated into the ERS-ERDb, the ETA will place the
resource .xml files into a content directory for monitoring successful
updates. In our example the content directory for successful updates is
"network computer location:\\sensor\\content\\succcesful". Additional support
for monitoring the resource .xml files is accommodated by prefixing the ERS
name in the name of the results xml file. In this example the
WebManagement_ConnectionPointService.xml will become
RESOURCE_DOMAIN_COMMON_WebManagement_ConnectionPointService.xml.
By design if the resource definitions and .xml files are not updated due to
errors, the ETA will place the .xml file into a content directory for error
updates. In our example the content directory for error updates will be
"network computer location:\\sensor\\content\\error". To support monitoring
functionality, the sensor will also prefix the error xml file by the ERS name,
a file name like WebManagement_ConnectionPointService_Error.xml will become
RESOURCE_DOMAIN_COMMON_WebManagement_ConnectionPointService_Error.xml
7. When the sensor has completed execution of the Tracking_Submit function,
the sensor will now set state to respond to locators or queries. This sensor
is now capable of responding to Locator requests and Enterprise requests for
information.
8. ETA listeners will be created when the sensor is 2-way. In this mode the
sensor will read resource definitions from related or pooled sensors or
network computers. When the connection points have all been read for the
resource definitions, the Tracking_Submit function will invoke it's
Tracking_Receive function. If there is a Tracking_Receive function with no
listener then this functionality will not poll for results. The
Tracking_Receive function will use the listener to send requests to related or
pooled sensors. The Tracking_Receive function will set a poll check state
"requests activated" in the connection point execution. The Tracking_Receive
function will read the resource definitions from the related sensors and
places the resource xml file and resource xml schema file for each sensor into
a poll check content directory say "network computer
location:\\sensor\\content\\connections\\pollcheck".
If all poll check states of "done" or "done but incomplete" strings are
returned for connection points; the ETA state is set for the ETA to use the
polled resource information.
In case of a "done" string for a connection point-poll check, the ETA will
check for the 2-WAY- Associate-sensor's xml files and xml schema files in the
poll check content directory. When all poll check results have been checked
and validated, the ETA algorithm will initiate attempts to push these 2-WAY-
Associate resources files onto the ERS.
Like regular xml files and xml schema resource files, the poll check files
will be first processed for parser updates, according to parsing success or
error the poll check xml files and xml schema files will be placed in the
sensor's content directories for results and enterprise functionality.
Feature note for an ELS Enhancement: In planning the ELS implementation, we
could also look to support creating Web Service Definition Administrative
Templates for the network computer whose resources are being published in the
Enterprise Resource Database. This will be a step towards enabling database
administration.
Terminology and service definition for Web administration and services:
1. Web Service Definition Language or commonly known as WSDL addresses this
need by defining an XML grammar for describing network services as collections
of communication endpoints capable of exchanging messages. WSDL service
definitions provide documentation for distributed systems and serve as a
recipe for automating the details involved in applications communication.
2. Like any specification, a WSDL document defines services as collections of
network endpoints, or ports. In WSDL, the abstract definition of endpoints and
messages is separated from their concrete network deployment or data format
bindings. This allows the reuse of abstract definitions: messages, which are
abstract descriptions of the data being exchanged, and port types which are
abstract collections of operations. The concrete protocol and data format
specifications for a particular port type constitutes a reusable binding. A
port is defined by associating a network address with a reusable binding, and
a collection of ports define a service. Hence, a WSDL document uses the
following elements in the definition of network services:
Types: a container for data type definitions using some type system (such as
XSD). Message: an abstract, typed definition of the data being communicated.
Operation: an abstract description of an action supported by the service. Port
Type:an abstract set of operations supported by one or more endpoints.
Binding: a concrete protocol and data format specification for a particular
port type. Port: a single endpoint defined as a combination of a binding and a
network address. Service: a collection of related endpoints.
3. WSDL recognizes the need for rich type systems for describing message
formats, and supports the XML Schemas specification (XSD) [11] as its
canonical type system.
In addition, WSDL defines a common binding mechanism. This is used to attach a
specific protocol or data format or structure to an abstract message,
operation, or endpoint. It allows the reuse of abstract definitions.
In addition to the core service definition framework, this specification
introduces specific binding extensions for the following protocols and message
formats:
+SOAP 1.1/
+HTTP GET / POST
+MIME
+New protocols and message formats
4. The design focus and "heart" of the proposal of this Web Administration
article is this feature interfaces conceptually with a Data Center Solution
and importantly any LDAP directory Solution. "Enterprise resource, schema
synchronization is a critical requirement for any Network Administrator, the
interoperable smart neighborhood solution is a potential scenario that could
extend and preserve network value-additions.
Pre-description to extend Enterprise Resource, Attributes and Schema
Synchronization
As we prepare to successively map the results from the
WebManagement_ConnectionPointService into service defintions, pre-description
of the status details is helpful and is described in the section below.
+ The pre-description for Replication events that occur during a write/read
of an object or definition are listed as follows:
> Status for addition of object schema definitions
> Status for revision of object schema definitions
> Status for deletion of object schema definitions
> Status for addition of object attribute schema definitions
> Status for revision of object attribute schema definitions
> Status for deletion of object attribute schema definitions
+ The pre-description for Account Management events that occur during a write/
read of an object during replication are listed as follows:
> Container/Account authentication for addition of object schema definitions
> Container/Account authentication for revision of object schema definitions
> Container/Account authentication for deletion of object schema definitions
> Container/Account authentication for addition of object attribute schema definitions
> Container/Account authentication for revision of object attribute schema definitions
> Container/Account authentication for deletion of object attribute schema definitions
+ The pre-description for an Attribute Mapping events that occur while mapping
attributes from one database to another are listed as follows:
> Map Results for addition of object schema definitions
> Map Results for revision of object schema definitions
> Map Results for deletion of object schema definitions
> Map Results for addition of object attribute schema definitions
> Map Results for revision of object attribute schema definitions
> Map Results for deletion of object attribute schema definitions
+ The pre-description for Service Controller events that occur when the
connector services are started, reset, stopped are listed as follows:
> Service Status for addition of object schema definitions
> Service Status for revision of object schema definitions
> Service Status for deletion of object schema definitions
> Service Status for addition of object attribute schema definitions
> Service Status for revision of object attribute schema definitions
> Service Status for deletion of object attribute schema definitions
+ As we rely on Web Services <-> the Administration of the Replication, Schema
synchronization, we could remote evaluate Web events that occur when the
connector services execute on Schema Masters. Today sampling these Web events,
is possible as we manage Schema/Object/Data across an enterprise network,
typical samples of these Web events are presented below:
> Web Events that include a message/op-code to enable or disable addition of object schema definitions
> Web Events that include a message/op-code to enable or disable revision of object schema definitions
> Web Events that include a message/op-code to enable or disable deletion of object schema definitions
> Web Events that include a message/op-code to enable or disable addition of object attribute schema definitions
> Web Events that include a message/op-code to enable or disable revision of object attribute schema definitions
> Web Events that include a message/op-code to enable or disable deletion of object attribute schema definitions
Typical communication in a Web Service neighborhood is using WSDL, so in the
next article we will review a WSDL specification for the Web Administration
proposed for the Enterprise.
We will also look at why the ELS-LDAP directory integration could enhance the
network administration or engineering focus in a Web Service neighborhood.
-- K.S. Venkatram is a computer engineer from the University Of Poona.
|