Aware Server is built on a foundation of a protocol known as Service Location Protocol or SLP for short. Aware’s distributed service registry allows you to publish attributes along with each service. Take for example of set of kiosks inside a mall where each one is running the Aware Runtime and publishes an IKioskService service contract into the distributed registry. It would be nice from an administrative perspective to be able to tell the “Kiosk on the first floor next to Sears” to do something or for example to show a particular advertisement. Each IKioskService can publish the floor and location on the floor they are running and then any Aware client can easily find that kiosk.
Example kiosk service:
| [ServiceContract(Namespace = "urn:mynamespace", Name = "KioskService")]
public interface IKioskService
{
[OperationContract]
void ShowAdvertisement(AdvertisementDetails advertisementDetails);
}
|
Code to call the service w/ search attributes using ServiceFactory<>:
| using (ServiceFactory<IKioskService> kioskFactory = new
ServiceFactory<IKioskService>())
{
ServiceAttributes searchAttributes = new ServiceAttributes();
searchAttributes["Location"] = "Sears";
IKioskService kiosk = kioskFactory.Create(searchAttributes);
kiosk.ShowAdvertisement(new AdvertisementDetails());
}
|
By default the Aware runtime will publish the following attributes with each service:
| Attribute
|
Description
|
| AwareVersion
|
The version of the Aware runtime
|
| Category
|
The category this service is in. This is simply metadata used by management tools.
|
| CLRVersion
|
The version of the CLR that is loaded into the AppDomain this service is running in.
|
| Cluster
|
The group of servers this service is a part of.
|
| Environment
|
The current Aware environment this service is running in.
|
| HostingModel
|
The hosting model this service was published as.
|
| LocalIpAddresses
|
A comma separated list of the IP addresses on the machine the service was published from.
|
| LogonUser
|
The user that the process housing the service is running as.
|
| MachineDomain
|
The domain the machine is a part of.
|
| MachineName
|
The machine name.
|
| MemoryInMegabytes
|
The memory in megabytes of total ram on the machine.
|
| OSVersion
|
The operating system housing the service.
|
| ProcessId
|
The process id of the housing process.
|
| ProcessName
|
The name of process.
|
| ProcessorCount
|
The number of processors on the machine.
|
| ProcessStartTime
|
The startup time of the process.
|
| ServiceAssemblyVersion
|
The service’s assembly version.
|
| StartedAt
|
The startup time of the service.
|
The next lists of attributes are well known attributes that the Aware Management Tools will use to categorize services, etc and should never be changed or overridden by your services.
| Attribute
|
Where used?
|
| Cluster
|
Used by the provisioning policies as well as the management tools.
|
| Category
|
Management Tools
|
| MachineName
|
Management Tools
|
| StartedAt
|
Management Tools
|
Attributes can be changed and republished at runtime. There are various ways to publish attributes along with your services. The first way to expose attributes is through your configuration file using staticAttributes inside the aware configuration section. Static attributes are great for attributes like Category which is used by the Aware Enterprise Manager to group your services inside the “Running Services” view.
Another way to publish attributes is by doing so in code. Using the AddAttributes event and the following code:
| private void MyServiceHost_AddAttributes(object sender, AttributeEventArgs e)
{
//
// Allows you to add additional attributes at runtime to all the published services in this host
//
e.Attributes["Location"] = "Sears";
}
|
The last way to publish additional attributes is using provisioning policies. The application administrator can attach additional attributes to each instance of your service at provisioning time. This is very powerful when you want to reuse
the same service (binaries) more than once with different configuration and policies. By attaching the attributes calls from web portals, etc. can be routed to different instances of the same service pointing at different databases, etc.
Be the first to rate this post
- Currently 0/5 Stars.
- 1
- 2
- 3
- 4
- 5