GRIDtoday: DEFINING A CONCEPT FOR A SMART NEIGHBORHOOD PART

DAILY NEWS AND INFORMATION FOR THE GLOBAL GRID COMMUNITY / JULY 28, 2003; VOL. 2 NO. 30

Special Features:

DEFINING A CONCEPT FOR A SMART NEIGHBORHOOD PART - VI
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:

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

To set the context for this article 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.

4. Typical Smart Neighborhood for Web Services

In enterprise neighborhoods, the manageability focus today is on 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.

This illustration describes a scenario for Sensor interfaces with the XML Web Service infrastructure. We look at the typical Performance Objects, sample definitions and model their translation into network communication messages and message parameters in the SOAP and HTTP protocols.

This article will introduce through Microsoft Visual C++ .NET interfaces, Smart Neighborhood implementations for these enterprise infrastructures.

We first look at Sensor-ConnectionPoint-XML Web Service concepts, today the XML Web Service framework is based on the XML Web Services Infrastructure. In presenting this we would refer to public consumption descriptions and publications that attempt to illustrate to readers the Web Service framework. As an author, I would like to state that the use of terminology in this proposal is as made available by Microsoft and Microsoft Press for public consumption.

On designing the Sensor-ConnectionPoint-XML Web Service component definition, we prepare to successively map the results from the Sensor, WebManagement_ConnectionPointService into Microsoft Visual C++ .NET or platform specific service definitions. In conceiving this monitoring status would be possible by maintaining objects for Site discovery, Enterprise Resource discovery, Core Service Events and Performance monitoring support in a "Data Center and Enterprise management model".

5. Design for the Sensor-ConnectionPoint-XML Web Service frameworks

Introducting the Model

The .NET framework does support Web Services by the following namespaces:

i. System::Web::Services: Contains the classes to build and use Web Services. The System::Web::Services namespace contains classes that look at developer requirements to create, design and leverage Web Services. The classes that are most common are listed below:

i.1 WebMethodAttribute: An attribute that marks a method as callable from remote Web clients.

i.2 WebService: An optional base class used to build Web Services.

i.3 WebServiceAttribute: An attribute used to add-develop information about the Web Services.

ii. System::Web::Services::Description: Contains the classes to describe the Web Services using WSDL.

iii. System::Web::Services::Protocols: Contains the classes that define the protocols used in the Web Services.

5.1 Class Definition and interfaces

In working for current time schedules and interest, we will look at fragments that model this implementation and subsequently preview the finale for this implementation in the next article for the Web Administration and Service Scenarios.

Illustration for the Web.config

The Web.config file contains configuration information for debugging, custom error and implementation specific options.

?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<!-- DYNAMIC DEBUG COMPILATION Set compilation debug="true" to insert
debugging symbols (.pdb information) into the compiled page. Because this
creates a larger file that executes more slowly, you should set this value to
true only when debugging and to false at all other times. For more
information, refer to the documentation about debugging ASP.NET files.
-->
<compilation
debug="true"
/>
<!--  CUSTOM ERROR MESSAGES
Set mode enable="on" or "remoteonly" to enable custom error messages, "off" to
disable. Add <error> tags for each of the errors you want to handle.
-->
<customErrors
mode="Off"
/>
<!--  AUTHENTICATION
This section sets the authentication policies of the application. Possible
modes are "Windows", "Cookie", "Passport" and "None"
-->
<authentication mode="None" />
<!--  APPLICATION-LEVEL TRACE LOGGING Application-level tracing enables trace
log output for every page within an application. Set trace enabled="true" to
enable application trace logging.  If pageOutput="true", the trace information
will be displayed at the bottom of each page.  Otherwise, you can view the
application trace log by browsing the "trace.axd" page from your web
application root.
-->
<trace
enabled="false"
requestLimit="10"
pageOutput="false"
traceMode="SortByTime"
/>
<!--  SESSION STATE SETTINGS
By default ASP+ uses cookies to identify which requests belong to a particular
session. If cookies are not available, a session can be tracked by adding a
session identifier to the URL. To disable cookies, set sessionstate cookieless
="true".
-->
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;user id=sa;password="
cookieless="false"
timeout="20"
/>
<!--  GLOBALIZATION
This section sets the globalization settings of the application.
-->
<globalization
requestEncoding="utf-8"
responseEncoding="utf-8"
/>
</system.web>
</configuration>

Illustration for the EnterpriseWebService.vdisco definition

In reviewing officially published Microsoft documentation for .vdisco/.disco definitions, the .disco file describes the Web Service and other links for helping applications and network services to .discover a Web Service. The disco definition can include descriptions for Web Services on the same server or remote server.

<?xml version="1.0" encoding="utf-8" ?>
<dynamicDiscovery xmlns="urn:schemas-dynamicdiscovery:disco.2000-03-17">
// We will add the discovery node definition for the EnterpriseWebService
// as we implement this support, the exclude entries will ease the search
// focus while discovering the availability of the Web Services.

<exclude path="_vti_cnf" />
<exclude path="_vti_pvt" />
<exclude path="_vti_log" />
<exclude path="_vti_script" />
<exclude path="_vti_txt" />
<exclude path="Web References" />

</dynamicDiscovery>

Illustration for the Global.asax code

<%@ Application Codebehind="Global.asax.h"
Inherits="EnterpriseWebService.Global" %>

Like marking the pages for introducing this Microsoft initiative, the Global.asax file is documented by Microsoft as a file that enables the user to manage application-level events. This file is recommended to be saved in the root directory for the ASP.NET Web Application or ASP.NET Web Service. The Global.asax.h is the dependent file for the Global.asax code, this contains code for the Web HTTP Application Start/End, Application Begin/End Request, Session Start/End interactions.

Illustration for the Global.asax.h code

using namespace System;
using namespace System::Web;
using namespace System::Collections;
using namespace System::ComponentModel;
using namespace System::Web::SessionState;

namespace EnterpriseWebService
{
/// <summary>
/// Summary description for Global.
/// </summary>
public __gc class Global : public System::Web::HttpApplication
{
protected:
void Application_Start(Object *sender, EventArgs *e)
{

}

void Session_Start(Object *sender, EventArgs *e)
{

}

void Application_BeginRequest(Object *sender, EventArgs *e)
{

}

void Application_EndRequest(Object *sender, EventArgs *e)
{

}


void Session_End(Object *sender, EventArgs *e)
{

}

void Application_End(Object *sender, EventArgs *e)
{

}
};
}

// EnterpriseWebService.h

#using <System.Web.Services.dll>
using namespace System;
using namespace System::Web;
using namespace System::Web::Services;

namespace EnterpriseNeighborhood
{
[WebServiceAttribute(
Namespace="http://EnterpriseNeighborhood/EnterpriseWebServices",
Description="Controlling the Smart Neighborhood Enterprise through Web
Services")]public __gc class EnterpriseWebService: public WebService
{
[System::Web::Services::WebMethod(Description="Designing Synchronization for
the Smart Neighborhood Enterprise through Web Services")]
...             EnterpriseSynchronization() ;


[System::Web::Services::WebMethod(Description="Designing Discovery for the
Smart Neighborhood Enterprise through Web Services")]
...             EnterpriseDiscovery() ;


[System::Web::Services::WebMethod(Description="Designing Sensor definitions
for the Smart Neighborhood Enterprise through Web Services")]
...             EnterpriseSensorServices() ;


[System::Web::Services::WebMethod(Description="Designing ELRS service
definitions for the Smart Neighborhood Enterprise through Web Services")]
...             EnterpriseELRSServices() ;


[System::Web::Services::WebMethod(Description="Designing ERS service
definitions for the Smart Neighborhood Enterprise through Web Services")]
...             EnterpriseERSServices() ;


[System::Web::Services::WebMethod(Description="Designing Performance
Monitoring Services for the Smart Neighborhood Enterprise through Web
Services")]
...             EnterprisePerformanceMonitor() ;


[System::Web::Services::WebMethod(Description="Designing Performance
Monitoring Definitions for the Smart Neighborhood Enterprise through Web
Services")]
...             EnterprisePerformanceMonitorClasses() ;

};
}

5.2 Class Implementation and snippets

#include "stdafx.h"
#include "EnterpriseWebService.h"
#include "Global.asax.h"

namespace EnterpriseWebService
{
// SMART NEIGHBORHOOD WEB SERVICE EXAMPLE

...     EnterpriseWebService::EnterpriseSynchronization()
{

// TODO: Add the implementation here

}

...     EnterpriseWebService::EnterpriseDiscovery()
{

// TODO: Add the implementation here

}

...     EnterpriseWebService::EnterpriseSensorServices()
{
// TODO: Add the implementation here

}

...     EnterpriseWebService::EnterpriseELRSServices()
{
// TODO: Add the implementation here
}

...     EnterpriseWebService::EnterpriseERSServices()
{
// TODO: Add the implementation here
}

...     EnterpriseWebService::EnterprisePerformanceMonitor()
{
// TODO: Add the implementation here

}

...     EnterpriseWebService::EnterprisePerformanceMonitorClasses()
{
// TODO: Add the implementation here
}
};

5.3 Web Service Deployment and Validation

i. Copy the Web Service files to the Web Server's Inetpub\wwwroot directory. We will in the next article address running Web Services and deployment of Proxy Servers as the ERLS/ERS neighborhood services.

ii. Open the Internet Services Manager from the Administrative Tools folder.

iii.Expand the Default Web Site node in the Internet Services manager.

iv. Right click the Web Service folder, in the Inetpub\wwwroot directory to pre-validate it's properties.

v. Click Create in the properties dialog box to configure the virual folder as the root of the Web Application.

Web Service Components on Deployment

The components published when the EnterpriseWebService is deployed and installed successfully as a service:

i. The Web Application directory in this example a directory with a name "EnterpriseWebService"
ii. The EnterpriseWebService.asmx file
iii. The EnterpriseWebService.disco file
iv. The Web.config file
v. The \Bin directory.

The Web Service status is mostly logged with a complete set of attributes that can be enabled to weigh the Web Service solution success or failure. This log file is found in the %WinDir%\System32\LogFiles directory and can be read to confirm the status/success of Web Administration and neighborhood support.

If the Web Service is deployed then the validation can be done by checking the Web Server's Inetpub\wwwroot directory, there should be a virtual directory in the same name as the Web Service, in this illustration the Web Service name is "EnterpriseWebService".

After installing the Web Service, locating the EnterpriseWebService is controlled by the deployment and integration of the Web Service with the neighborhood. The Microsoft support context for locating Web Services is listed as:

+ If the EnterpriseWebService is registered using the Microsoft UDDI service, the UDDI link can be used to locate the Web Service. If the EnterpriseWeb Service is connected to the neighborhood using a URL, then this URL transactional mechanism is used to communicate with the Web Service.

+ The step required for any Web Service interaction is the mechanism termed as "supporting proxy for the Web Service". The Microsoft .NET provides a wsdl.exe utility that generates a proxy in the interest of supporting Web Services. The example command line to create a proxy for the EnterpriseWebService is as illustrated:

a. In the language support for creation of the proxy, this article illustration will look at C# support.

b. In the protocol support for creation of the proxy the Enterprise illustration will look at both SOAP/HTTP.

To introduce the Smart Neighborhood to a reader familar with the .NET, we use C# for the sample. The command line support is illustrated as follows:

wsdl /l:cs /protocol:SOAP
http://localhost/EnterpriseWebService/EnterpriseWebService.asmx?WSDL

The command line for the Microsoft .NET Compiler to convert the proxy code to a Microsoft .NET supported DLL. The command line support is illustrated as follows:

csc /t:library /c:system.web.services.dll /r:system.xml.dll /r:system.data.dll

EnterpriseWebService.cs

The Microsoft tool that builds the proxy code into a Microsoft .NET supported DLL. The .DLL can then be interoperated with other classes for the Smart Neighborhood - Web Service Administration, implementation and support for neighborhood-interoperable components.

Management Reflections

Management interest and reflections in my developer, technical focus have always found that weighing interest in effort for "e-Actions" or focus for "rest:is easy:and known" terminology, does not in turn design a core model, it is mostly factual planning and engineering focus that succeeds. My management reflection is technical capability and design planning does always ensure that --custom limited views do not become engineering views -- and technical results for enterprise frameworks will outlive such fallacy in wrong reaping and focus. When the technical management model is for the enterprise, it will reap results in any interoperable, extensible and management effort.

Conclusion:

In the Smart Neighborhood Article VIII C++ implementations will be illustrated for the Sensor-ConnectionPoint-XML Web Services .NET framework, the code snippets for integration will use the Web Service/WSDL Classes and the ATL Server Classes.

For the interest of the Grid readers and management focus, in the Smart Neighborhood Article IX we will review the Sensor-ConnectionPoint-Grid Service Container framework. For readers the Grid Service Container framework is based on the Open Grid Services Infrastructure.

-- 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 - VIby K.S. Venkatram, computer engineer, University Of Poona

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