 |
|
DAILY NEWS AND INFORMATION
FOR THE GLOBAL GRID COMMUNITY / JULY 21, 2003; VOL. 2 NO. 29
|
Special Features:
DEFINING A CONCEPT FOR A SMART
NEIGHBORHOOD - PART V
by K.S. Venkatram, computer engineer, University Of
Poona
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.
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, modeled 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.
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
5. http://www.gridtoday.com/03/0707/101653.html
The reader will be presented the introduction, definition for the Web
Administration and Services, and then this presentation and mechanisms will be
modeled with comparative analysis and extensibility proposed by the sensor-
controlled network.
Terminology and service definition for Web administration and services:
This article does include some terminology and definition that helps readers
understand the proposal of this Smart Neighborhood article.
1. Web Service Definition Language
a. Web Service Definition Language or commonly known as WSDL, addresses the
need for Web Service interaction 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.
b. 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 constitute 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:
i. Types: a container for data type definitions using some type system (such
as XSD).
ii. Message: an abstract, typed definition of the data being communicated.
iii. Operation: an abstract description of an action supported by the service.
iv. Port Type: an abstract set of operations supported by one or more
endpoints.
v. Binding: a concrete protocol and data format specification for a particular
port type.
vi. Port: a single endpoint defined as a combination of a binding and a
network address.
vii. Service: a collection of related endpoints.
WSDL recognizes the need for rich type systems for describing message formats,
and supports the XML Schemas specification (XSD) as its canonical type system.
c. 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.
3. XML Web Services Infrastructure
The reader will need to understand the descriptions of the components of this
XML Web Services infrastructure:
i. XML Web Services directories: These directories provide a repository for
locating and administering Web Services. The information about the Web
Services is published in these directories. The reader will need to know about
the Universal Description, Discovery and Integration specifications for this
smart neighborhood scenario.
ii. XML Web Service discovery: The Web Management scenario will use the Web
Service Description Language to discover Web Services.
iii. XML Web Service description: The Web Management scenario will use the Web
Service Description Language to describe Web Services, formats of messages and
services supported by the Web Service.
iv. XML Web Service wire formats: Interoperability in networks is enabled in
the XML Web Service infrastructure by relying on wire formats such as HTTP and
SOAP.
In addition to the core service definition framework, this specification
introduces specific binding extensions for the following protocols and message
formats:
+ SOAP: The SOAP protocol enables Web applications to exchange formatted
information in the Internet. The SOAP protocol comprises of the SOAP envelope,
the SOAP envelope is the main component of the SOAP message, next is the data
encoding rule component that extends the SOAP message to function for
application specific definitions, the data- encoding component is followed by
the request-response message component. The optional part of the SOAP protocol
is the binding of the SOAP protocol with HTTP.
+ HTTP GET/POST: The HTTP-GET, HTTP-POST commands and protocol format are
specifications to exchange data using name-value pairs. The HTTP-GET protocol
allows services to send URL encoded parameters as name value pairs to the XML
Web Service. The HTTP-GET protocol requires that the URL encoded parameters
are included in the URL of the XML Web Service. The HTTP-POST requires that
the URL encoded parameters be sent as name value pairs in the message content
and not as part of the URL.
+ The Grid Service Container framework, based on the Open Grid Services
Infrastructure: The Smart Neighborhood Scenarios series for the Web Services
infrastructure - Article VII, will preview a proposal for managing such
infrastructure.
+ The Microsoft .NET XML Web Service framework, based on the XML Web Services
Infrastructure: The Smart Neighborhood Scenarios series for the Web Services
infrastructure - Article VII, will preview a proposal for managing such
infrastructure along with the Open Grid Services infrastructure.
iv. New protocols and message formats:
As this article presents the integration of the Smart Neighborhood with Web
Service architectures, the model enabled by the Smart Neighborhood integrates
the sensor-controlled network support with the Web Service support. This
integration makes it possible to track services, resource, network entities
with the help of the ELS protocol, message and resource description formats.
The integration of the Web Service components with the sensor-controlled
network does permit the sensor-controlled model to control access to services,
resources, and network entities across namespaces, domains, networks and
directories with permissions and security clauses. The ELS will base its Web
Scenario search, management and reporting on security configurations such as:
i. Proposal for a "Respond only" option: This configuration identifies that
permission to signal or query a sensor on the network computer is sufficient
for the requestor to access Web Service resources.
ii. Proposal for a "Request Security" option: This configuration uses network
security if requested by the sensor. This means that if the sensor on the
network computer requires network security to be satisfied and secures
transport of information; the requestor will need to associate security
information along with the signal or query transmission. Alternatively if the
sensor requests no network security, then this configuration will work the
same as the "Respond only" option.
iii. Proposal for a "Require Security" option: This configuration option
identifies that the requestor always needs extended network security. The
sensor will respond to search and access queries only if the requestor does
satisfy the security requirements. In this configuration the requestor and
network computer, on which the sensor is installed, transmit a signed key with
the resource access or resource information. Like existing industry support
for security through keys, this configuration will secure the transport of
information through the signed key mechanism.
4. Communication between the Client and the XML Web Service:
i. The communication is through a Proxy object for the XML Web Service on the
network computer; this Proxy is used to call XML Web Service methods.
ii. The XML Web Services infrastructure on the network computer serializes the
method-call and corresponding arguments into a SOAP message and sends it to
the remote XML Web Service.
iii. The infrastructure on the server on which the XML Web Service is
available will receive the SOAP message and deserialize the method-
call/arguments to instantiate an instance of the XML Web Service, and then
executes the method.
iv. The XML Web Service executes the method and returns the resulting value
with the XML Web Service OUT parameters.
v. The function's results and any OUT parameters are serialized into a SOAP
message and communicated back to the proxy object on the requesting network
computer.
vi. The proxy object makes available the method's results to the client.
vii. The sensor-controlled network interoperates with the various XML Web
Services through this XML Web Service client communication. To interoperate
ELS model behaviour with XML Web Services, the proposal for a
WebManagement_ConnectionPointService entity incorporates the functionality for
the Web Service scenario.
5. Preview of the Enterprise Location System and the Enterprise Data Center
Services market:
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.
Any deployment for a "Data Center and Enterprise management model" is
dependent on controlled locatability and management interest. In the
enterprise network, data or service locatability is defined commonly by Schema
Masters. Data Center services today support resource or service updates from
independent network computers to Schema Masters. The article presents the
concept of how the sensor-controlled infrastructure pre-selects extensibility
as the infrastructure model and addresses the focus on Web Services and Web
Service market.
The article describes implementing an 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.
Like any XML Web Service, the Web Service discovery file will be inter-
operated with by the ELS WebManagement_ConnectionPointService. The Smart
Neighborhood model permits communication between the Connection Point, XML
Client, supports the interoperability design for Web Services and importantly
the XML Web Service.
To consider an example for a Replication Event infrastructure, the XML Web
Service for the Replication Event infrastructure could be defined in a
discovery file like the illustration:
Illustration for a XML Web Service called MyWebService.asmx:
<?xml version="1.0" ?>
<disco:discovery xmlns:disco="http://schemas.xmlsoap.org/disco"
xmlns:wsdl="http://schemas.xmlsoap.org/disco/wsdl">
<wsdl:contractRef ref="http://www.contoso.com/MyWebService.asmx?WSDL"/>
</disco:discovery>
Typical Smart Neighborhood for Web Services
The article will use the following terminology for the illustration:
i. Neighborhood XML Service Location Entity: This service represents the model
interoperated by the Sensor - WebManagement_ConnectionPointService - XML Web
Service Client.
ii. Enterprise XML Services Server Entity: This service represents the model
interoperated by the ELS-ERS-ELRS, Enterprise Data Center/Resource Services
with XML Web Service infrastructure. The ERS-ELRS locates hosts for Web
Services through connectors or Web Service mechanisms. The connectors are
mechanisms that outline the Smart Neighborhood concept for locating resources,
services and up to-date definitions in a network.
Scenario for describing how the Sensor interfaces with the XML Web Service
infrastructure is outlined in the steps below:
i. The Neighborhood XML Service Location Entity will initialize the Sensor -
WebManagement_ConnectionPointService using the predefined settings described
in the smart neighborhood publication.
The WebManagement_ConnectionPointService interoperates with the XML Web
Service Client to locate the availability of the Replication Web Service. The
Enterprise XML Services Server entity will receive this location request, as
inferred if the locatability support for Web Services is installed on this
Server Entity, the URL for the discovery document is linked in the
communication result sent back to the XML Web Service Client.
The Client then will request the discovery document from the XML Web Server
and this XML Web Server will return the discovery document to the Client.
For readers not familiar with how the Client connects to a XML Web Service,
the Client reads the discovery document and requests a well- defined
description of the XML Web Service. This service description is used by the
Client to instantiate an instance of the XML Web Service. Proxy mechanisms are
relied on for the Client to invoke a supported method in the discovered Web
Service.
The deployment of Web Services, UDDI services in the network is decided by
hosting Web Services and infrastructure on servers. If there is no Web Service
UDDI support installed on the Server Entity, then the Web Service is tracked
by the support for the Web Service connector. The connector for this scenario
is modeled with the integration proposed below:
ii. The Web Services Manager, Connector will need to know the Web Services
database involved. The Connector will also need to know the number of
connectors that can be installed on the Enterprise XML Services Server Entity.
To understand the alternative supported in this integration, if Web Service
support is available, then discovery is done using this support and
communication. If the Web Service UDDI, discovery is affected due to
communication failures or network infrastructure failures, the Smart
Neighborhood proposes we have a extensible, smart neighborhood where discovery
is not limited to the UDDI concept. As the Smart Neighborhood supports hosting
mixed extensible schema, resource synchronization, and the common failures in
discovering network entities, network instances of resources, services,
connection points to management services for any entity on the network can be
guided, reviewed using the Connector defined through the Smart Neighborhood
proposal.
iii. The Connector will need to know the names of the ERS-ELD or ELRS- ELD
servers with XML Web Service infrastructure to be contacted for
synchronization. These are some classifications of synchronization, Bi
directional synchronization, Selective service or attribute synchronization,
Change synchronization and synchronization of attribute level changes.
iv. The Connector will need to know the Web Services, discovery, monitoring
classes to be included in the synchronization process between ERS-ELD and
ELRS-ELD servers.
v. The Connector will need to know the Web Services, discovery, monitoring
classes to be included in the detection and use of the member synchronization
process between ERS-ELD and ELRS-ELD servers.
vi. The Connector will need to know the direction in which the synchronization
should occur.
vii. The Connector will need scheduling information for the synchronization
process.
viii. The Connector will need to know how deleted Web Services, discovery,
monitoring objects will be dealt with.
ix. The Connector will need to know the list of attributes for the Web Service
to be synchronized and how the attributes map between ERS-ELD or ELRS-ELD
servers. The attributes for a Web Service integrate the protocol and message
format in Web Service Client interfaces with Proxy- Web Service support.
x. The Connector will need to know which method is used for creating new Web
Service objects.
xi. The Connector will need to know the authentication methods supported.
xii. The Connector will need to know the list of containers that will be
involved in synchronization and how they map between ERS-ELD and ELRS- ELD
servers.
xiii. The Connector will need to define options and support Web Service
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, software resource objects and Web
Service object classes for selective attribute tracking sessions.
As we prepare to successively map the results from the
WebManagement_ConnectionPointService into service definitions,
monitoring status is possible by maintaining discovery, monitoring
support objects for events in a "Data Center and Enterprise management
model".
Replication Events:
The Connector will need to create monitoring support objects for Replication
events that occur during a write/read of an object or resource definition. The
monitoring classes, resources objects and sample definitions for monitoring
the Replication Schema service are listed below:
i. Replication(_Connector_Object_EnterpriseCatalogID)\Number of
additions
ii. Replication(_Connector_Object_EnterpriseCatalogID)\Number of changes
iii. Replication(_Connector_Object_EnterpriseCatalogID)\Number of Reads
iv. Replication(_Connector_Object_EnterpriseCatalogID)\Number of Writes
v. Replication(_Connector_Object_EnterpriseCatalogID)\Number of deletes
vi. Replication(_Connector_Object_EnterpriseCatalogID)\Number of
containers
vii. Replication(_Connector_Object_EnterpriseCatalogID)\Number of
Members
viii. Replication(_Connector_Object_EnterpriseCatalogID)\Scheduling
parameters
ix. Replication(_Connector_Object_Attribute_EnterpriseCatalogID)\Number
of additions
x. Replication(_Connector_Object_Attribute_EnterpriseCatalogID)\Number
of changes
xii. Replication(_Connector_Object_Attribute_EnterpriseCatalogID)\Number
of Reads
xiii.
Replication(_Connector_Object_Attribute_EnterpriseCatalogID)\Number of
Writes
xiv. Replication(_Connector_Object_Attribute_EnterpriseCatalogID)\Number
of deletes
xv. Replication(_Connector_Object_EnterpriseCatalogID_Total)\% Processor
Time. The processor utilization, interval calculation will be based on
the start, initialize, invoke and control event support.
Account Management Events:
The Connector will need to create monitoring support objects for Account
Management events that occur during a write/read of an object or resource
definition. The Authentication is based on the ELS model of "Respond only",
"Request Security" and "Require Security" security policies. The monitoring
classes, resource objects and sample definitions for these events are
presented as:
i*. AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RespondOnly\Number of additions
i-a AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RequestSecurity\Number of additions
i-b AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RequireSecurity\Number of additions
ii*.
AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RespondOnly\Number of changes
ii-a
AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RequestSecurity\Number of changes
ii-b
AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RequireSecurity\Number of changes
iii*.
AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RespondOnly\Number of Reads
iii-a
AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RequestSecurity\Number of Reads
iii-b
AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RequireSecurity\Number of Reads
iv*.
AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RespondOnly\Number of Writes
iv-a
AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RespondOnly\Number of Writes
iv-b
AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RespondOnly\Number of Writes
v*. AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RespondOnly\Number of deletes
v-a AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RequestSecurity\Number of deletes
v-b AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RequireSecurity\Number of deletes
vi*.
AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RespondOnly\Number of containers
vi-a
AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RequestSecurity\Number of containers
vi-b
AuthenticationForReplication(_Connector_Object_EnterpriseCatalogID)\
RequireSecurity\Number of containers
vii*.
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RespondOnly\Number of additions
vii-a
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RequestSecurity\Number of additions
vii-b
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RequireSecurity\Number of additions
viii*.
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RespondOnly\Number of changes
viii-a
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RequestSecurity\Number of changes
viii-b
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RequireSecurity\Number of changes
ix*.
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RespondOnly\Number of Reads
ix-a
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RequestSecurity\Number of Reads
ix-b
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RequireSecurity\Number of Reads
x*.
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RespondOnly\Number of Writes
x-a
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RequestSecurity\Number of Writes
x-b
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RequireSecurity\Number of Writes
xi*.
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RespondOnly\Number of deletes
xi-a
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RequestSecurity\Number of deletes
xi-b
AuthenticationForReplication(_Connector_Object_Attribute_EnterpriseCatal
ogID)\RequireSecurity\Number of deletes
Attribute Mapping Events:
The Connector will need to create monitoring objects for the list of
attributes managed by Schema synchronization between ERS-ELD or ELRS-ELD
servers.
a. List of attributes for addition of class-schema definitions
b. List of attributes for revision of class-schema definitions
c. List of attributes for deletion of class-schema definitions
d. List of attributes for addition of class-attribute-schema definitions
e. List of attributes for revision of class-attribute-schema definitions
f. List of attributes for deletion of class-attribute-schema definitions
The samples for these monitoring objects, resource definitions are
illustrated as:
a. WebServices(_Connector_Service_EnterpriseCatalogID)\Publisher Name
b. WebServices(_Connector_Service_EnterpriseCatalogID)\Publisher Schema
Description
c. WebServices(_Connector_Service_EnterpriseCatalogID)\Schema Definition
d. WebServices(_Connector_Service_EnterpriseCatalogID)\Schema Version
e. WebServices(_Connector_Service_EnterpriseCatalogID)\Date associated
with the Schema Definition
f. WebServices(_Connector_Service_EnterpriseCatalogID)\Core\Schema
Class-Attribute Source
g. WebServices(_Connector_Service_EnterpriseCatalogID)\Schema Container
h. WebServices(_Connector_Service_EnterpriseCatalogID)\Schema Map
Description
i. WebServices(_Connector_Service_EnterpriseCatalogID)\Schema Class Name
j. WebServices(_Connector_Service_EnterpriseCatalogID)\Schema Class
Description
k. WebServices(_Connector_Service_EnterpriseCatalogID)\Schema Class
Unique identifier
l. WebServices(_Connector_Service_EnterpriseCatalogID)\Schema Class-
Attribute Name
m. WebServices(_Connector_Service_EnterpriseCatalogID)\Schema Class-
Attribute Description
n. WebServices(_Connector_Service_EnterpriseCatalogID)\Schema Class-
Attribute Unique identifier
o. WebServices(_Connector_Service_EnterpriseCatalogID)\Track\addition
p. WebServices(_Connector_Service_EnterpriseCatalogID)\Track\deletion
q. WebServices(_Connector_Service_EnterpriseCatalogID)\Track\changes
The Connector will need to create monitoring objects for Attribute Mapping
events that occur while mapping attributes from one LDAP Directory database.
The proposal for these Attribute Mapping events Is presented below:
a. Map Results for addition of class-schema definitions
b. Map Results for revision of class-schema definitions
c. Map Results for deletion of class-schema definitions
d. Map Results for addition of class-attribute-schema definitions
e. Map Results for revision of class-attribute-schema definitions
f. Map Results for deletion of class-attribute-schema definitions
The monitoring classes, resource objects and sample definitions for these
proposed Attribute Mapping Events are modeled as read/write results.
i. In previewing the proposal, the focus and interest is in read/write
scenarios for the Attribute mapping, in working across schema versions. In
schema replication or synchronization, failures are encountered either for the
read of the existing attribute version or for mapping to the new attribute
version.
i-a AttributeMapping(_Connector_Object_Attribute_EnterpriseCatalogID)\
ELS\Message\Failures
i-b AttributeMapping(_Connector_Object_Attribute_EnterpriseCatalogID)\
ELS\OpCode\Failures
ii. In this preview and context we would be interested importantly in
read/write scenarios in which for inconsistent or different schema versions,
the existing attribute version will need to be read and then consistently
mapped or replicated as the new attribute version.
The samples for read scenarios:
ii-a AttributeMapping(_Connector_Object_Attribute_EnterpriseCatalogID)\
ELS\Message\SuccessfulReads
ii-b AttributeMapping(_Connector_Object_Attribute_EnterpriseCatalogID)\
ELS\OpCode\SuccessfulReads
The samples for write scenarios:
iii-a AttributeMapping(_Connector_Object_Attribute_EnterpriseCatalogID)\
ELS\Message\SuccessfulWrites
iii-b AttributeMapping(_Connector_Object_Attribute_EnterpriseCatalogID)\
ELS\OpCode\SuccessfulWrites
Service Controller Events:
In this context, well known events for Service Controllers; Web Administration
Services occur when the connector services are started, reset, stopped. Sample
counters for these events are previewed for the read/write schema
administration:
i. ServiceController(_Connector_Object_EnterpriseCatalogID)\Status
(Started/Map/Reset/Stopped)\Number of additions
ii. ServiceController(_Connector_Object_EnterpriseCatalogID)\Status
(Started/Map/Reset/Stopped)\Number of changes
iii.ServiceController(_Connector_Object_EnterpriseCatalogID)\Status
(Started/Map/Reset/Stopped)\Number of Reads
iv. ServiceController(_Connector_Object_EnterpriseCatalogID)\Status
(Started/Map/Reset/Stopped)\Number of Writes
v. ServiceController(_Connector_Object_EnterpriseCatalogID)\Status
(Started/Map/Reset/Stopped)\Number of deletes
vi. ServiceController(_Connector_Object_EnterpriseCatalogID)\Status
(Started/Map/Reset/Stopped)\Number of containers
vii. ServiceController(_Connector_Object_EnterpriseCatalogID)\Status
(Started/Map/Reset/Stopped)\Number of Members
viii. ServiceController(_Connector_Object_EnterpriseCatalogID)\Status
(Started/Map/Reset/Stopped)\Scheduling parameters
ix.
ServiceController(_Connector_Object_Attribute_EnterpriseCatalogID)\Statu
s(Started/Map/Reset/Stopped)\Number of additions
x.
ServiceController(_Connector_Object_Attribute_EnterpriseCatalogID)\Statu
s(Started/Map/Reset/Stopped)\Number of changes
xii.
ServiceController(_Connector_Object_Attribute_EnterpriseCatalogID)\Statu
s(Started/Map/Reset/Stopped)\Number of Reads
xiii.
ServiceController(_Connector_Object_Attribute_EnterpriseCatalogID)\Statu
s(Started/Map/Reset/Stopped)\Number of Writes
xiv.
ServiceController(_Connector_Object_Attribute_EnterpriseCatalogID)\Statu
s(Started/Map/Reset/Stopped)\Number of deletes
xv.
ServiceController(_Connector_Object_EnterpriseCatalogID_Total)\Status(St
arted/Map)\% Processor Time.
This proposal integrates the XML Web Service entities introduced earlier with
the Smart Neighborhood. Each Smart Neighborhood service controller, Web
Service Connector and Web Service deployed can be enumerated and tracked with
sample resource definitions like the list below:
a. WebServices(_Service_CatalogID)\Manufacturer Name
b. WebServices(_Service_CatalogID)\Software Type
c. WebServices(_Service_CatalogID)\Product Name
d. WebServices(_Service_CatalogID)\Product Version
e. WebServices(_Service_CatalogID)\Description
f. WebServices(_Service_CatalogID)\Path to the directory where the product is installed
g. WebServices(_Service_CatalogID)\Size of the core program files installed for the product
h. WebServices(_Service_CatalogID)\Date associated with the Product
i. WebServices(_Service_CatalogID)\Unique identifier for the Product
j. WebServices(_Service_CatalogID)\Core\Program File list
k. WebServices(_Service_CatalogID)\Track\addition
l. WebServices(_Service_CatalogID)\Track\deletion
m. WebServices(_Service_CatalogID)\Track\changes
To manage and monitor the Web Services, the Neighborhood - Web Service model
and Administration context extends to include specific items associated with a
Web Service.
n WebServices(_Service_CatalogID)\XML Web Service Directories
o WebServices(_Service_CatalogID)\XML Web Service discovery
p WebServices(_Service_CatalogID)\XML Web Service description
q WebServices(_Service_CatalogID)\XML Web Service wire formats
Service Status events occur when the connector services proceed with schema
updates and synchronize schema object definitions, the sample status for these
schema updates are listed below:
a. Service Status for addition of object schema definitions
b. Service Status for revision of object schema definitions
c. Service Status for deletion of object schema definitions
d. Service Status for addition of object attribute schema definitions
e. Service Status for revision of object attribute schema definitions
f. Service Status for deletion of object attribute schema definitions
The monitoring classes/sample object definitions for the Service Status
monitoring are as follows:
1. ServiceStatus(_Connector_Object_EnterpriseCatalogID)\Number of
additions
2. ServiceStatus(_Connector_Object_EnterpriseCatalogID)\Number of
changes
3. ServiceStatus(_Connector_Object_EnterpriseCatalogID)\Number of Reads
4. ServiceStatus(_Connector_Object_EnterpriseCatalogID)\Number of Writes
5. ServiceStatus(_Connector_Object_EnterpriseCatalogID)\Number of
deletes
6. ServiceStatus(_Connector_Object_EnterpriseCatalogID)\Number of
containers
7. ServiceStatus(_Connector_Object_EnterpriseCatalogID)\Number of
Members
8. ServiceStatus(_Connector_Object_EnterpriseCatalogID)\Scheduling
parameters
9. ServiceStatus(_Connector_Object_Attribute_EnterpriseCatalogID)\Number
of additions
10. ServiceStatus(_Connector_Object_Attribute_EnterpriseCatalogID)\Number of
changes
11. ServiceStatus(_Connector_Object_Attribute_EnterpriseCatalogID)\Number of
Reads
12. ServiceStatus(_Connector_Object_Attribute_EnterpriseCatalogID)\Number of
Writes
13. ServiceStatus(_Connector_Object_Attribute_EnterpriseCatalogID)\Number of
deletes
Web Services:
Today administration of the Replication, Schema synchronization is critical
for effective neighborhoods. In the scenario where the neighborhood could
include Web Service support, it is also critical that we evaluate events that
occur when the connector services execute on Schema Masters. Today, samples
for these Web events are possible as we manage Schema, object-class resources,
data across an enterprise network. Typical illustrations of these Web events
are presented below:
a. Web Events that include a message/op-code to enable or disable addition of
object schema definitions
b. Web Events that include a message/op-code to enable or disable revision of
object schema definitions
c. Web Events that include a message/op-code to enable or disable deletion of
object schema definitions
d. Web Events that include a message/op-code to enable or disable addition of
object attribute schema definitions
e. Web Events that include a message/op-code to enable or disable revision of
object attribute schema definitions
f. Web Events that include a message/op-code to enable or disable deletion of
object attribute schema definitions
The monitoring classes/ sample counters for these op-codes in Web Events are
presented as integrating the ELS with the Web Administration and Service
infrastructure to manage the LDAP Directory, Data Center schema, network
resources and their synchronization in a network:
i-a
WebAdministration(_Connector_Object_EnterpriseCatalogID)\ELS\OpCode\Numb
er of additions
i-b
WebAdministration(_Connector_Object_EnterpriseCatalogID)\XMLWebService\O
pCode\Number of additions
ii-a
WebAdministration(_Connector_Object_EnterpriseCatalogID)\ELS\OpCode\Numb
er of changes
ii-b
WebAdministration(_Connector_Object_EnterpriseCatalogID)\XMLWebService\O
pCode\Number of changes
iii-a
WebAdministration(_Connector_Object_EnterpriseCatalogID)\ELS\OpCode\Numb
er of Reads
iii-b
WebAdministration(_Connector_Object_EnterpriseCatalogID)\XMLWebService\O
pCode\Number of Reads
iv-a
WebAdministration(_Connector_Object_EnterpriseCatalogID)\ELS\OpCode\Numb
er of Writes
iv-b
WebAdministration(_Connector_Object_EnterpriseCatalogID)\XMLWebService\O
pCode\Number of Writes
v-a
WebAdministration(_Connector_Object_EnterpriseCatalogID)\ELS\OpCode\Numb
er of deletes
v-b
WebAdministration(_Connector_Object_EnterpriseCatalogID)\XMLWebService\O
pCode\Number of deletes
vi-a
WebAdministration(_Connector_Object_EnterpriseCatalogID)\ELS\OpCode\Numb
er of containers
vi-b
WebAdministration(_Connector_Object_EnterpriseCatalogID)\XMLWebService\O
pCode\Number of containers
vii-a
WebAdministration(_Connector_Object_EnterpriseCatalogID)\ELS\OpCode\Numb
er of Members
vii-b
WebAdministration(_Connector_Object_EnterpriseCatalogID)\XMLWebService\O
pCode\Number of Members
viii-a
WebAdministration(_Connector_Object_EnterpriseCatalogID)\ELS\OpCode\Sche
duling parameters
viii-b
WebAdministration(_Connector_Object_EnterpriseCatalogID)\XMLWebService\O
pCode\Scheduling parameters
ix-a
WebAdministration(_Connector_Object_Attribute_EnterpriseCatalogID)\ELS\O
pCode\Number of additions
ix-b
WebAdministration(_Connector_Object_Attribute_EnterpriseCatalogID)\XMLWe
bService\OpCode\Number of additions
x-a
WebAdministration(_Connector_Object_Attribute_EnterpriseCatalogID)\ELS\O
pCode\Number of changes
x-b
WebAdministration(_Connector_Object_Attribute_EnterpriseCatalogID)\XMLWe
bService\OpCode\Number of changes
xi-a
WebAdministration(_Connector_Object_Attribute_EnterpriseCatalogID)\ELS\O
pCode\Number of Reads
xi-b
WebAdministration(_Connector_Object_Attribute_EnterpriseCatalogID)\XMLWe
bService\OpCode\Number of Reads
xii-a
WebAdministration(_Connector_Object_Attribute_EnterpriseCatalogID)\ELS\O
pCode\Number of Writes
xii-b
WebAdministration(_Connector_Object_Attribute_EnterpriseCatalogID)\XMLWe
bService\OpCode\Number of Writes
xiii-a
WebAdministration(_Connector_Object_Attribute_EnterpriseCatalogID)\ELS\O
pCode\Number of deletes
xiii-b
WebAdministration(_Connector_Object_Attribute_EnterpriseCatalogID)\XMLWe
bService\OpCode\Number of deletes
The monitoring classes/sample object definitions for these Web events/messages
in Web Events are illustrated below:
As multiple Network Interfaces can be installed on any network computer, the
proposal resolves unique reporting by including the CatalogID generated for
network interfaces.
i-a
WebAdministration(_Connector_Network_Interface_CatalogID)\ELS\Message\By
tes Total/sec
i-b
WebAdministration(_Connector_Network_Interface_CatalogID)\XMLWebService\
Message\Bytes Total/sec
In this example the bytes will be totaled on the basis of the well- defined
information size in the parameters that are included in the SOAP, HTTP GET-
POST messages.
ii-a
WebAdministration(_Connector_Network_Interface_CatalogID)\ELS\Message\Pa
ckets Received/sec
ii-b
WebAdministration(_Connector_Network_Interface_CatalogID)\XMLWebService\
Message\Packets Received/sec
In this example the packets received will be totaled on the basis of the SOAP,
HTTP GET-POST responses sent from XML Web Service to the Connector for .the
Schema Master.
iii-a
WebAdministration(_Connector_Network_Interface_CatalogID)\ELS\Message\Pa
ckets Sent/sec
iii-b
WebAdministration(_Connector_Network_Interface_CatalogID)\XMLWebService\
Message\Packets Sent/sec
In this example the packets sent could be totaled on the basis of the SOAP,
HTTP GET-POST requests sent from Connector for the Schema Master to the XML
Web Service.
iv
WebAdministration(_Connector_Network_Interface_CatalogID)\ELS\Message\Cu
rrent Bandwidth
In this example the packets sent will be totaled on the basis of the network
regulation for bytes exchanged using the SOAP, HTTP GET-POST communication
infrastructure. As ELS or the Smart Neighborhood is modeled expecting IP as
the protocol, integrating the ELS sensor- controlled network with SOAP, HTTP
GET-POST frameworks is a possible model, but to report network communication
transfers, bandwidth results, the deployment may need third party applications
to track network interfaces/network traffic.
Conclusion:
To summarize the ELS-LDAP directory integration could enhance the network
administration or engineering focus in a Web Service neighborhood. The ELSC
infrastructure interfaces with the Web Administration Services to preprocess,
store, update and synchronize this information across the sensor-controlled
network.
The concept of a Connector for the Smart Neighborhood includes support 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 Web Service connector services are
started, reset, stopped and events for operations that occur while ERS/ELRS
services access the Web Services, Web Services database and the Location
Domain database.
In the next article we will review how these Performance Objects, sample
definitions translate into network communication messages and message
parameters in the protocols like SOAP and HTTP.
-- K.S. Venkatram is a computer engineer from the University Of Poona.
|