 |
|
DAILY NEWS AND INFORMATION
FOR THE GLOBAL GRID COMMUNITY /
|
Special Features:
CONCEPT FOR EXTENDING THE REMOTE
NETWORK FILE SYSTEM SERVICES
By K.S.Venkatram
This article will describe the specification that extends effectiveness in
working with remote file systems. For any remote or online referral, these
model concepts were defined and penned first as model scope. The rendering of
the same into an article for the Grid today expects to support referral for
market interest in such a proposal.
Publications And Articles For Related Analysis
Development plans, interoperability and extensibility from this article is
published as part of the series about "Defining a concept for a Smart
Neighborhood" in the Grid Today. The article is 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 in enterprise scenarios.
For immediate subject interest, we review the sensor-controlled network in
this article and then review how this sensor-controlled network can support
the concept for extension for the Smart Neighborhood Assistant & Remote
Network File System.
Review Of The Sensor-Controlled Network
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 support from the
extensible sensor-controlled services.
To set expectation for the reader I begin with the following concepts and
definitions:
"Enterprise Network Resources" The enterprise network resources are
typically hardware, software applications, performance measurement objects and
network manageability objects in the mixed network or grid.
"Enterprise Locations" 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.
"Enterprise Location Protocol" The Enterprise Location Protocol defines
the network transport and service in querying resource availability in the
mixed grid.
"Enterprise Location Servers" - 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.
"Enterprise Resource Servers" - 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.
"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" - 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 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 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.
Introduction
i. Today solutions only work with the concept of pre-defined resource
definitions or platform-related resources or remote file systems; in this
support the sensor-controlled network does conceive connection points that
collaborate to deal with pre-defined and other resources extensions. The
sensor-controlled network supports spectrums or mixed varieties of resources,
as newer resources are added or existing resources deleted, the Simple Model
stores the resource definitions and their status in a database and
synchronizes this information to help any network computer locate
resources.
ii. The concept proposed through the sensor-controlled network, relies on
storing and synchronizing resource information from various sensors. On
successful storage, the sensor-controlled network looks up these resource
definitions to query resource objects in the enterprise grid. In this article
we integrate into the sensor-controlled network, the design for the Remote
File System interoperability and connection extensions. We do this by
reviewing the mechanisms for Interfaces, Basic services for Remote File
System.
Understanding The Sensor And The Simple Model
1. Like regular databases, Enterprise Resource Databases will be installed
on
Enterprise Resource Servers. 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. In this sensor-controlled network, we will
look at extending remote file system services.
2. Enterprise Resource Databases (ERDb) will host a set of tables to store
and
track information about various resources available in an enterprise grid. The
proposed ERS solution uses information publishing and information
synchronization services to guide, report and architect the mechanism of
locating resources irrespective of their location in the enterprise grid.
3. The Enterprise Resource Server (ERS) will store and synchronize resource
definitions across other Enterprise Resource Servers and Enterprise Resource
Databases. An Enterprise Resource Server will use a distribution service to
synchronize resource definitions, thus enabling tracking resources in an
enterprise grid with mixed platform support.
4. The schema for the Enterprise Resource Database (ERDb) is a Simple Model
to
store and report information of any resource on the network. To understand the
Simple model, the following guidelines are presented:
In the ERS, all resources will have an Enterprise identifier.
In the ERS, all resources will have a resource class. Commonly known
classes
are Hardware class, or Software class, or Performance Indicator class or
Extension Resource class. In this case the Extension Resource class is the
"Enterprise AccessNConnectDecision services for interoperable Remote File
Systems".
In the ERS, all resources will have an Object-Collection identifier.
In the ERS, an Object-Collection model will define resource class and the
various attributes associated with the class. All resources in the
Object-Collection model will have attributes like a resource identifier, a
description, value and units for the value.
In the ERS, all resources will have attributes that track the resource on
the
basis of the timestamps. The variety of timestamps in the ERS are:
a. Timestamp when the resource was configured or described first in the
enterprise network.
b. Timestamp when the resource was tracked or accessed or updated in the
enterprise network.
c. Timestamp when the resource was deleted or exposed to lifecycle updates
in
the enterprise network.
In the ERS, all resources will have attributes like lifetime signing and
criticality that determine the lifecycle of a resource in the enterprise
network.
In the ERS, all the attributes will focus on manageability and strategizing
focus for resource lifecycles in the enterprise network.
Understanding The Sensor And Connection Point Services
1. A sensor will support a unique connection point for each resource
service
or management agent on the network computer. Typically a network computer
could be installed with management agents such as a SNMP agent or a WMI agent
or a Directory agent. The sensor conceives a solution to describe resources,
by which there will be a connection point for each management agent on a
network computer i.e. in this example network computer there will be a
connection point for SNMP, there will be a connection point for WMI and a
connection point for the Directory agent. The sensor will report resources
available on this example network computer, by interfacing with the management
agents through these active connection points. The connection points use the
management agents to consolidate and describe the various resources on the
network computer.
2. For example an SNMP agent in today's support describes the resources in
the
SNMP namespace with the SNMP mappings, a WMI agent in today's support
describes the resources in the Windows Management Instrumentation namespace
with the WMI mappings and a Directory agent in today's support describes
resources in the Directory namespace with the Directory mapping.
Till this conceptualization, SNMP, WMI and common agents today have been
reviewed to enable sensor-controlled network support and decisions. In this
article, we review the Enterprise AccessNConnectDecision management agent.
For any reference, the URLs for the "sensor-controlled network" articles
are:
3. Enterprise AccessNConnectDecision Management agent
The "new conceptual model" proposes implementation for agents called the
Enterprise AccessNConnectDecision management agents. The sensor conceives a
solution to extend remote file system services, by which there will be a
connection point for each of these management agent on a network computer.
The Remote File System AccessNConnectDecision Model proposes integrating &
supporting the following services, these services expect to support new
mechanisms of remote file system access.
3.1 Interfaces, Basic services.
3.2 Neighborhood Assistant Interfaces invoked by specific Platforms.
3.3 Interfaces invoked by specific Platform connectivity services.
3.4 Interfaces invoked by specific Platform File System services.
3.5 Interfaces invoked by specific Explorer infrastructure services.
3.6 Interfaces invoked by specific Marshalling services to write/read/align
with various file formats, images.
3.7 Interfaces to manage using virtual folders explicitly created for the
Neighborhood Assistant Decision Support and Information services.
a. These AccessNConnectDecision management agents will further the
connection
point experience for network services, interfaces, sensor based lifecycles in
the enterprise network and design ways to extend the file system.
For the AccessNConnectDecision Management agents, the connection point
infrastructure interfaces with components called "PlugNPlaySensorServices". We
will review the specification for these experiences as I expect to involve
ourselves further with this concept.
b. We will look at basic interfaces and platforms known to enable file
systems
across various mappings and connection points. As we step through the
requirements for agents and services in the Remote File System Infrastructure,
the usage of the Smart Neighborhood design proposes to connect and access the
file systems with sensor based definitions, options & extensibility.
c. These AccessNConnectDecision management agents will rely on Enterprise
Remote File System Server (ERFSS) support to extend the file system. The ERFSS
infrastructure or BackEndServices will exist on the remote server & remote
file system, these services interface with the file system to develop and
extend the scope for any network access.
The Enterprise Resource Server (ERS) revises interfaces and experiences to
become the Enterprise Remote File System Server (ERFSS), this proposes support
to extend the file system; the ERFSS will store and synchronize Remote File
System resource definitions across other Enterprise Remote File System Servers
and Enterprise Resource Databases to extend support through the
AccessNConnectDecision parameters for network services, interfaces, sensor
based definitions and sensor based lifecycles.
For the AccessNConnectDecision management agents, in enabling expectation
we
revise the Enterprise Location System - Sensor Configuration illustrated in
previous sensor-controlled network articles and extend the same for the
AccessNConnectDecision management agent.
Enterprise Location System - Sensor Configuration for the
AccessNConnectDecision management agents - Illustration I
<application>
<service>
<wellknown
<parameter name="mode" value="Singleton"/>
<parameter name="type" value="AccessNConnectDecision"/>
<parameter name="lifetime" value="extension"/>
<parameter name="algorithm" value="ERFSS"/>
<parameter name="objectURI" value="Custom_AccessNConnectDecision"/>
/>
<channel
<parameter name="ref" value=""/>
<parameter name="port" value=""/>
/>
<handler
<parameter name="arguments" value="contributor,contribution,response"/>
<parameter name="responsefile" value="AccessNConnectDecision.int"/>
<parameter name="submit" value="Custom_AccessNConnectDecision_Submit"/>
<parameter name="receive" value="Custom_AccessNConnectDecision_Receive"/>
/>
<filesystem
<parameter name="schema" value="xml"/>
<parameter name="schemafile" value="AccessNConnectDecision.scm"/>
<parameter name="resourcefile" value="AccessNConnectDecision.xml"/>
<parameter name="rulesfile" value="AccessNConnectDecision.rul"/>
<parameter name="contentdirectory" value="c:\\sensor\\content\\Custom_AccessNConnectDecision"/>
<parameter name="cache" value="enabled"/>
/>
</service>
</application>
Recommendations for Future interest: the series will describe the
<parameter
name="algorithm" value="ERFSS"/> and look at same for the
AccessNConnectDecision management agent.
4. One side of the problem is using an existing management agent; the other
well-known problem is that, a change in the data model or a change in the
management agent interfaces does require new alignment. To ease the effort in
alignment and also satisfy the common network requirement, the ELS proposes a
mechanism that connects with each of these agents and enumerates their
resource descriptions. This sensor-controlled mechanism consolidates resource
descriptions using a data model algorithm and then updates them into the
Enterprise Resource Database (ERDb) on an Enterprise Resource Server (ERS), in
case of the Remote File System an Enterprise Remote File System Server
(ERFSS).
5. In any sensor-controlled framework an Enterprise Tracking Agent (ETA)
will
be installed on the network computer irrespective of the other management
agents. The Enterprise Tracking Agent will consolidate or collect the resource
descriptions from the various connection points and keep this cached for any
sensor query or response.
The Enterprise Tracking Agent will integrate and approach the
infrastructure
alignment with the services of the AccessNConnectDecision management agent.
The Enterprise Tracking Agent interfaces with the management agent to connect
and access the file systems with sensor based definitions, options &
extensibility.
Understanding The Implementation Of The Enterprise Location System
a. In the proposed Enterprise Location System, simple design specifications
direct the scope and guidelines recommended to implement the solution. The
design requires the implementation of specific functions, input and output
parameter formats and published op-codes for mixed grids and management
girds.
b. Describing Grid Resource Services:
To quote from an existing article on Grid computing "In a computational
Grid,
information is a critical resource, and gathering this information is a vital
activity. The information services component of the Globus Toolkit, the
Monitoring and Discovery Service (MDS), gathers information about Grid
resources by means of the Grid Resource Information Service (GRIS) and the
Grid Index Information Service (GIIS)".
The proposal for the "Extending the Remote File System Services"
specification
in the Enterprise Location System has not finalized support for a toolkit, by
design the Enterprise Location System recommends interfaces and tracking
service installation through implementation of connection points. As different
network engineers and developers in the Grid community rate the concept,
implementing the design by large can conceive support in the same way as the
Grid.
In this article series, I will support the concept with an example of how
this
concept could be implemented, with interfaces and tracking service
installation.
c. The proposal for the Enterprise Location System defines connection point
interfaces like the "Tracking_Submit" and "Tracking_Receive" functions that
must be implemented by any resource service extension integrated with the
sensor-controlled network. Invocation of the "Tracking_Submit" and
"Tracking_Receive" functions will be stringently verified for parameters and
op-codes. Parameters are passed to the "Tracking_Submit"and "Tracking_Receive"
functions by passing arguments in a formatted string such as "contributor=",
"contribution= ", "response= success or failure or response file" The op-codes
are required for the functions to execute certain services in resource
reporting and access
d. For readers interested in implementing resource service extensions, the
required support from op-codes will be made known and published as part of the
framework. This means that any reader interested in developing a resource
service extension will be supported with guidelines and published
specifications. The fundamental step would be to develop the extension and
implement the "Tracking_Submit" function and "Tracking_Receive" function with
the signature, formatted parameter interpretation and op-code support.
e. The Enterprise Tracking Agent (ETA) will have a class scope and the
resource service extensions will have a library or extension scope. Such class
or library scope is well known in today's development scenarios, the sensor-
controlled network makes it possible for any network user to direct the scope
of the resource management solution in the network.
f. In proposal, this implementation of the Enterprise Location System
extends
the management and services for remote file systems. We will understand how
this done, through the next set of services and design examples.
Understanding The Implementation Of The Accessnconnectdecision Management
Agent In This
Enterprise Location System
a. What AccessNConnectDecision management agent resources are
available?
The Enterprise Resource Locator (ERL) service is proposed in the Enterprise
Location System. The sensors installed on the various network computers use
connection points to report the available resource descriptions to an
Enterprise Remote File System Server (ERFSS) and Enterprise Resource Database
(ERDb). The Enterprise Resource Database services use the Enterprise Location
System-Simple Model to store the resource definitions in the database. These
resource definitions are then available for any network user or Administrator
to enumerate and use in locating resources in the enterprise network.
b. What resources are available?
The Enterprise Resource Locator (ERL) service is proposed in the Enterprise
Location System. The sensors installed on the various network computers use
connection points to report the available resource descriptions to an
Enterprise Remote File System Server (ERFSS) and Enterprise Resource Database
(ERDb). The Enterprise Resource Database services use the Enterprise Location
System-Simple Model to store the resource definitions in the database. These
resource definitions are then available for any network user or Administrator
to enumerate and use in locating resources in the enterprise network.
c. Whether newer resources can be located in the enterprise network?
The schema of the Enterprise Resource Database (ERDb) is not static or is
not
expected to store well-known resources only. At this stage the reader needs to
understand that the schema is defined on the guidelines of a Simple Model. In
the Enterprise Location System, any resource available on a network computer
running any version of an operating system and resource services can be
tracked. The network user looks up existing resource definitions in an
Enterprise Resource Database (ERDb) and then sends out XML Locator queries to
the sensors in the enterprise. Sensors support preprocessing these XML Locator
queries and send results for the Administrator to follow up or enforce
management actions.
This article does introduce the reader to the information that the
AccessNConnectDecision resources support parameters for network services,
interfaces, sensor based definitions and sensor based lifecycles. As we
proceed with the next few articles, we will understand the implementation and
follow up with the management actions.
d. How can applications be optimized based on the configuration of the
underlying system?
The identification part of the question is answered, as most management
applications do not work in mixed networks. For any Administrator, to manage
mixed networks there are limitations imposed by the underlying system. To
address such limitations, the Enterprise Location System does propose a
mechanism to track resources in identifying usage or in measuring performance
or in knowing resources available in neighborhoods. The optimization and
configuration part of the question is answered, as the sensor-controlled
network does interface with Directories to support this requirement. To
optimize or configure specific resources on a network computer, the first
recommendation in the sensor-controlled network is to update the supported
Directory (LDAP-conformant Directory) with the resource(s) available on the
network computer. Once the resource definitions are published in the Directory
as Directory objects, the requirement is to implement a policy based solution
to manage these Directory objects. The sensor could optionally create and
publish policies for these Directory objects. When the management service
needs to optimize or guide resource access or availability, it sends a XML
Locator command with rules attached. The rule is either the policy name to be
read from the directory or the XML format configuration. The sensor on
preprocessing the XML Locator command will extend its role to support
performance measurement and optimization if the resource service provider
supports functions to init, reset, shut down or control operations. This
feature is classified as critical monitoring services in the Enterprise
Location System. Details will be presented in ensuing articles.
Reuse The Sensor Design And Enterprise Resource Database Support
The new concept proposes support for publishing, tracking and
synchronization
of resources in a Database termed as the ERDb. The article does present the
design and service possible through the sensor-controlled network.
a. 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.
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.
Configuration for a typical Remote File System node supporting connection
points: Illustration II.
<application>
<directory 1>SMBIOS</directory 1>
<directory 2>AccessNConnectDecision</directory 2>
<global identifier format>
<refresh_global_identifier>
Disabled
</refresh_global_identifier>
<include_directory>
Enabled
</include_directory>
<refresh_include_directory>
Enabled
</refresh_include_directory>
<include_global_time>
Disabled
</include_global_time>
</global identifier format>
<global identifier>
SENSOR_2-WAY_SMBIOS-AccessNConnectDecision_REMOTEFILESYSTEM-NODE
</global identifier>
</application>
b. The server section will along other configuration options, describe the
identity of the Enterprise Remote File System Server (ERFSS) and the identity
of the Enterprise LDAP Resource Server (ELRS) or Enterprise Remote File System
Server (ELRFSS).
The functionality on an ERFSS will update, synchronize resource definitions
and information available on the sensor's network computer into an Enterprise
Resource Database.
The functionality on an ELRS or ELRFSS 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.
c. Looking at domains and capabilities for Windows platforms and NetWare
platforms, the sensor-controlled network could be planned with a Windows
platform Enterprise Resource Server (WindowsERS) or a NetWare platform
Enterprise Resource Server (NetWareERS) or NetWare platform Enterprise Remote
File System Server (NetWareERFSS) . The sensor-controlled network proposes
interoperability and Enterprise Resource Database services to work effectively
in a mixed grid.
d. Additionally we could have an Enterprise Remote File System Server
(ERFSS)
hosting the Enterprise Location Domain (ELD) infrastructure. The Enterprise
Resource Database synchronization for storing, searching and management of
resources described by sensors is proposed through this ELD infrastructure.
The problems that affect networks today are database interoperability,
database synchronization of schema updates, content updates across the
network. To search and access resources published in an Enterprise Resource
Database, specific model conformance and support for namespace context is
important, the ELS proposal does design an infrastructure that addresses these
requirements. In the next few articles we will revise the SMBIOS to support
the ELS proposal, design and infrastructure.
The Enterprise Location Domain infrastructure will be installed on a server
like other enterprise services. The ELD is not an implementation of the DNS
solution but is capable of hosting and returning sensor names or monitoring
sensor status in planned subnets or smart neighborhoods.
The configuration information defined for the Enterprise Remote File System
Server (ERFSS) and ELD is similar to the Enterprise Resource Server
configuration information presented to the reader.
To describe the ERDb extension to the sensor-connection points: The
following
entry in the application section decides the vendor database enabled extension
to the sensor.
Enabled
When the ERDb extension is enabled for the sensor, then the sensor supports
the functionality to store the described resources from the various
AccessNConnectDecision Connection Point services in an Enterprise Resource
Database. This is done by, transferring the resource xml results and database
schema for the resources to the Enterprise Remote File System Server
(ERFSS).
The sensor invokes the Tracking_Submit function with the op-code "read
ERFSS
resources". When this is 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 "ERFSS resources defined"
initialization results, the Tracking_Submit request will invoke the
Custom_ConnectionPointService_Submit with the "read ERFSS resources" op-code.
On being invoked with the op-code "read ERFSS resources", the
Custom_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\\Custom_ConnectionPointService".
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 Custom_ConnectionPointService_Submit
function with the op-code "read schema". When the invocation of the
Custom_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 Custom_ConnnectionPointService.blob
file in the content directory. This Custom_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 Custom_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 ERFSS 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 ERFSS-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.
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 ERFSS
name, a file name like ConnectionPointService_Error.xml will become
SettingsForEnterpriseResources_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 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.
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.
In the next article, we will review how the sensor could help support
interoperability and connection extensions through an Enterprise Resource
Service Provider. The Service Provider will integrate support for the
enterprise to associate Smart Neighborhood Assistant & remote file system
bindings with definitions, concepts and thus support storing, locating and
managing Smart Neighborhood Assistant resources.
Summary For The Sensor And Remote File System Resource Services
1. What exactly is extended by Smart Neighborhood Assistant services and
how
do I use it?
The new Remote File System support integrates a concept called the "Smart
Neighborhood Assistant". The services proposed by the Smart Neighborhood
Assistant set guidelines to assist, enable smart decision support while
working with the remote file system.
For any interest, the Smart Neighborhood Assistant will be designed with
components that extend the interfaces of the Remote File System
AccessNDecision proposal from support today to support for updates or newer
releases of the Operating System itself. Today we depend on the company
developing the Operating System and File System infrastructure to manage the
remote file system services, this proposal does extend the scope to smarten
the manageability & effectiveness while administering remote file system
access in many versions or capabilities.
We change our focus from just installing Operating System Support & Network
Capabilities in the form of services, clients, connectivity support. We look
at the extensible model to support file access and neighborhood functionality
without the experience of waiting for patches or updates or new software
release for network capabilities.
The model makes it possible to separate the support provided by the company
delivering the Operating System and File System infrastructure to experiences
where players delivering products for the Operating System and File System
infrastructure can extend the Remote File System AccessNDecision proposal.
The AccessNConnectDecision components expect to support services that help
remember, manage & realize extensibility of users and network experiences
while working with files. The components propose to interface with the network
and remote file systems, with the help network client services, shell/explorer
services, and relevant marshalling services to access files and control
access.
2. What exactly are the Smart Neighborhood Assistant components and the new
AccessNConnectDecision components ?
a. We could term the first component of the Smart Neighborhood Assistant as
"NetworkServerSensorServices", this component interfaces with the host, remote
server & supported remote file systems to enable services.
b. We could term the second component of the Smart Neighborhood Assistant
as
"PlugNPlaySensorServices", this component interfaces with the host, remote
server & remote file system to enable services. PlugNPlay in this
conceptualization is what we experience today with resources, new hardware,
drivers, services that are activated, managed & relied on without any explicit
functionality enhancement in the infrastructure running the new services.
Similar factors conceive a model in which any network user could
effectively
rely on "PlugNPlaySensorServices" for dynamic administration and decision
support using the specification of these resources. The
"PlugNPlaySensorServices" for a particular platform will first expect the
"NetworkServerSensorServices" to resolve initial requirements and expectations
for defining the network components that the network resource is available
in.
After defining the network components, the interaction with the network
resource or any new remote server, new remote file system(s) can be supported
by describing the network resource or new remote server or new remote file
system information in a grammatical but extensible model that assists and
manages the remote file system administration.
c. We could term the third component of the Smart Neighborhood Assistant as
"InterceptionSensorServices", this component interfaces with the
infrastructure and file system by intercepting file access. There are many
solutions today that intercept the file or file system access, the Smart
Neighborhood Assistant proposal and design introduces a new mechanism of
intercepting file or file system access. The Smart Neighborhood Assistant
proposal and design coceptualization will manage the interception,
administration and explore network options with enhanced connectivity.
d. We could term the fourth component of the Smart Neighborhood Assistant
as
"PlugNPlayServices", this component interfaces with the host, remote server &
remote file system by reading the grammatical extensible model that describes
functionality & procedures to enable extensible connectivity. With the
interception, read, model resource conceptualization done, the file system
will be conceptually assisted to manage, extend neighborhood functionality and
capabilities.
When we talk about component interfaces we need to understand the
architectural options. To achieve this we look at the architectural services
in the remote file system and services domain and then associate their
bindings with definitions and concepts.
i. UIServices - these are architectural services that help users to
interface
with the Remote File System services.
ii. RoleModelServices - these are architectural services that help users
work
in security or network user involvements. As rules decide services in the
"RoleModelServices" architecture, if the rules are supported for the remote
resource, then the architectural services could support extensible network
administration.
iii. ConnectivityModelServices - these are architectural services that help
users or network solutions to connect onto remote file systems in any network
access.
iv. CaptureInferenceTool - these are architectural services that help users
or
clients or different network interfaces to capture the file system access and
infer principles that guide the file system & administration support.
Decisions for the remote file system are possible by capturing the experience,
if the experience is captured then the model enables information, extensible
rules, connectivity decisions to support decisions for infrastructure
dependencies or effectiveness.
v. BackEndServices - these are architectural services that help network
file
system services. The BackEndService will exist locally or as remote services,
these services interface with the file system to develop and extend the scope.
Today we need to connect to a remote file system and then run an explorer to
interact with a regular view of the remote file system. With the help of this
regular view, the user actively works with the file system.
There is nothing secure or decision dependent in this view. We can make any
number of remote updates or attempt any number of remote updates. The remote
file system does not interoperate with principles that enable extensibility.
This simple option could be addressed by running a BackEndService for a
Network Infrastructure. The BackEndService interoperates with the help of
CaptureInferenceTool mechanisms, Interactive Services and FrameWork services.
This BackEndService administration changes the view of the remote file system
administration with the help of the Smart Neighborhood Assistant.
vi. FrameWorkServices - these are architectural services that help
solutions
in different sets of involvements, Microsoft expects the .NET or Developments
using the .NET to provide the framework. Today the framework for Remote File
System Services is a market set by what we need as infrastructure, we will
realize this through the "Remote File System Access Decision Model".
About The Author
K.S.Venkatram is a computer engineer from the University Of Poona.
|