GRIDtoday: DEFINING A CONCEPT FOR A SMART NEIGHBORHOOD

DAILY NEWS AND INFORMATION FOR THE GLOBAL GRID COMMUNITY / JUNE 16, 2003: VOL. 2 NO. 24

Special Features:

DEFINING A CONCEPT FOR A SMART NEIGHBORHOOD - PART III
by K.S.Venkatram, computer engineer, University Of Poona

This article is the third in a series about "Defining a concept for a Smart Neighborhood". 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 genuinely remember sharing the model design with some members of the development community, the sharing then made it clear that they did not understand the design or support or interest themselves with the concept of the Enterprise Location System. Looking ahead I have termed and documented the earlier model to align with the notion of a Grid framework. 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:

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.

MAIN IDEAS OF PART III

The Sensor design and Enterprise Resource Database support:

The ELS 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.

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.

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 Windows node supporting connection points: Illustration I.

Configuration for a typical NetWare node supporting connection points: Illustration II.

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.

3. 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). The sensor- controlled network proposes interoperability and Enterprise Resource Database services to work effectively in a mixed grid.

4. Additionally we could have an Enterprise Resource Server (ERS) 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.

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 Resource Server and ELD is presented to the reader as sample illustrations.

Enterprise Resource Server definition: Illustration III.

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 WMI/DMI/SNMP/SMBIOS/other 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 ERS.

This example does not look at WMI/DMI/SNMP/SMBIOS/other management services in specific focus, it uses the illustration of a "ConnectionPointService" to present the ERS functionality.

The sensor invokes the Tracking_Submit function with the op-code "read 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 "resources defined" initialization results, the Tracking_Submit request will invoke the Custom_ConnectionPointService_Submit with the "read resources" op-code. On being invoked with the op-code "read 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 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 ConnectionPointService.xml will become RESOURCE_DOMAIN_COMMON_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 ConnectionPointService_Error.xml will become RESOURCE_DOMAIN_COMMON_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.

Typical configuration for a Windows node:

For information on this the reader is referred to the "Defining a concept for a Smart Neighborhood Part II" article

Typical configuration for a NetWare server:

For information on this the reader is referred to the "Defining a concept for a Smart Neighborhood Part II" article

Enterprise Resources and Enterprise Resource Databases:

The Enterprise Location System proposes that the Enterprise Resource Servers and other Location Entities enable a network user to store, search and manage resources in Enterprise Resource Databases. Looking at the current issues with enterprise network implementations, the ELS proposal expects to address platform problems, location problems, any lack of access and interoperability problems.

Windows Platforms:

The reader is recommended referring to the "Defining a concept for a smart neighborhood Part II" for information about how the ELS proposal integrates and supports Enterprise Service Provider requirements.

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. These efforts do not map the model in many management and application development areas. In service, the mixed or enterprise network synchronizes support on an interoperable effort rather than such disconnected effort. Like solutions and their lack of such alignment, the disconnected effort will commonly be there within the management and development areas of the same company or will be there for the external world using the company’s services.

In implementing smart solutions, the Enterprise Location Service Catalog Map proposal will ease, extend and control the synchronization with enterprise services. The solution expects to deal with lack of alignment by stating that disconnected effort do not become costly steps but are connected through the sensor-services and thereon devour limitations in enhancing the management areas for the network. The Enterprise Location Service Catalog will be implemented for addressing services and management of information in the network. The description of this concept is not concise, the same will be presented in an ensuing closure artilce for the Enterprise Location System.

ELS and the concept of an Enterprise Resource Service Provider

This article introduces the proposal for an Enterprise Resource Service Provider. The Service Provider will integrate support for storing, locating and managing resources in enterprise service databases through the sensor- controlled infrastructure.

We start by understanding co-existence and then define the requirements to implement an Enterprise Resource Service Provider.

Coexisting with the Enterprise Resource or Data Center Services market: In the scenarios of co-existing with existing Enterprise Services, the ELS supports options for network users to integrate the sensor, connection point to existing Enterprise Services.

On integrating a sensor, connection point with existing Enterprise Services, this functionality then permits the network user to decide or dynamically control the Enterprise Resource or Data Center solution. The integration helps the network user to take ownership of the Enterprise Resource or Data Center solution. Additionally the integration with the ELS will ease effort to integrate with other Resource or Data Center Services, own the manageability in the Enterprise Resource or Data Center solution and coexist in mixed grids.

Designing extensible service providers and reducing costs:

The Enterprise Resource Server proposal provides services to extend schema, publish objects and resources, and synchronize the schema and objects in the Enterprise Resource Database across the enterprise network.

A. The proposal for the ERS services can be split as service requirements to support the following:

1. Service to detect whether the ERS supports native database services.

2. Service to detect the Schema Master in the ERS neighborhood, refer Illustration IV for implementation : 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 is to support schema updates from one server the Schema Master. An ERS working as a Schema Master will have the defined in the configuration.

In order to distribute and synchronize schema updates, entities like ELRS, ELS and sensors help Distribution and Synchronization support for resources. In article context, refer Illustrations "V, VI and VII for their implementations.

3. 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.

4. 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.

5. 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.

B. Planning the Design and Implementation of an ELS Location Domain Service Provider:

1. First requirement is the Instrumentation; this means development of an agent that implements ELS/Enterprise Location Domain infrastructure specification; exposes interfaces to work with the information in the model. While developing the Instrumentation, the developer will also need to implement an ELS Location Domain Services Connector. For enterprise requirements the "Enterprise Location Domain Services Connectors" will be designed on the same principles of synchronizing resource content in a mixed grid environment.

2. In the design and proposal for a ELS Location Domain Services Connector, the implementation will need some configuration options to be defined for the solution:

i. The Connector will need to know the ELD database 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 ERS-ELD or ELRS-ELD servers to be contacted for synchronization. These are some classifications of synchronization, Bi directional 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 between ERS-ELD and ELRS-ELD servers.

iv. The Connector will need to know the object classes to be included in the detection and use of the member synchronization process between ERS servers.

v. The Connector will need to know the direction in which the synchronization should occur.

vi. The Connector will need scheduling information for the synchronization process

vii. The Connector will need to know how deleted objects will be dealt with

viii. The Connector will need to know the list of attributes to be synchronized and how the attributes map between ERS-ELD or ELRS-ELD servers.

ix. The Connector will need to know which method is used for creating new objects

x. The Connector will need to know the authentication methods supported

xi. 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.

xii. 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.

xiii. 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 Enterprise Location Domain Services operations that occur while ERS/ELRS services access the Location Domain database.

3. Third requirement is for Component Instrument Interface that interacts with the agent to expose information from the agent. The op-codes support and integration in the sensor-controlled network serves this requirement. This means that the design of the sensor, connection point infrastructure functions as the Component Instrument interface.

4. Fourth requirement is the Service Provider Core.

When we look at the requirements for the Service Provider Core, the ELS proposes critical path support, manageability and ability to extend services for different kinds of resources. This design is useful for any development and can reduce the effort for any vendor to develop the Service Provider Core.

5. Fifth requirement is the Remote Process or Remote Procedure Call mechanisms to permit the information access from remote network computers. The features available through the ELS are enterprise tracking and access of resources from mixed networks or enterprise grids.

6. Sixth requirement is the Front End and Management Application that permits the network user to use the Service Provider and management information. The Enterprise Console features available through the ELS support simple tracking, searching of network resources, ability to guide decisions for network management and grids.

C. Planning the Design and Implementation of an ELS Database Services installation:

1. First requirement is the Instrumentation; this means development of an agent that implements ELS/ELRS/LDAP infrastructure specification; exposes interfaces to work with the information in the model. While developing the Instrumentation, the developer will also need to implement a ELS Database Services Connector. For enterprise requirements the "Directory Services Connectors" and "Database Services Connectors" will be designed on the same principles of synchronizing resource content in a mixed grid environment.

2. 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.

4. Fourth requirement is the Service Provider Core. When we look at the requirements for the Service Provider Core, the ELS proposes critical path support, manageability and ability to extend services for different kinds of resources. This design is useful for any development and can reduce the effort for any vendor to develop the Service Provider Core.

B. Planning the Design and Implementation of an ELRS Directory Services implementation:

Thus after describing the model for Enterprise Services and Connectors for management, the reader is presented with the Enterprise LDAP Resource Server configuration in Illustration VIII.

Refer illustration in IX for support and modality of implementing directory services through the ELRS specification.

NetWare Platforms:

The question that is posed is whether NDS partitions have one-to-one relationships with domains? Feature proposal: This issue is a question of how does the DNS namespace integrate with the NDS? We need to look at whether an NDS object FDN/FQDN contains the DNS name of the partition; it is important to look at how the DNS name association helps find an object in the mixed grid. In integrating NDS partitions with DNS namespaces, different namespaces can be located directly through the DNS. If DNS namespace support is available with the FDN/FQDN then the search and access of the object is possible from different directory services/servers. Such issues may commonly be addressed using DNS naming conventions, planning the model and effective extensions for global search and support.

Coexisting with the Enterprise Resource or Data Center Services market: Novell does not support Enterprise NetWare Servers or scenario planning. This is a problem due to support for resource availability and management experience. Developers do not have enterprise options on this platform, the stage can be set in this article by reflecting on what could be an "Enterprise NetWare Server", the design and support on the NetWare Server will need to support resource availability and access in a mixed grid, extend the management experience and coexist with the implementation of service providers and look at what it takes to manage Data Center solutions.

In the enterprise market, the "Defining a concept for a smart neighborhood" design is an extensible principle that collaborates development and vendor skill in implementing services for mixed, smart support from any location.

In the scenarios of co-existing with existing Enterprise Services, the ELS supports options for network users to integrate the sensor, connection point to existing Enterprise Services.

-- K.S.Venkatram is a computer engineer from the University Of Poona.

( Top of Page )

( Table of Contents )

Special Features:

DEFINING A CONCEPT FOR A SMART NEIGHBORHOOD - PART IIIby K.S.Venkatram, computer engineer, University Of Poona

Introduction:

MAIN IDEAS OF PART III

DEFINING A CONCEPT FOR A SMART NEIGHBORHOOD - PART III
by K.S.Venkatram, computer engineer, University Of Poona