OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OMod] Information aggregation in MOWS (aka "Issue 3")



Below please find draft 1 (fred's version :-) of text for describing the concerns expressed by "Issue 3".  I have taken the liberty of expanding from just the aggregation perspective to include the opposite case.  This opposite case is one where things which end up at the same place may be referring to separate external entities, as opposed to the aggregation case where things addressed to the same place may be directed to different instances of a service.

/fred


Issue 3: Responsibilities of Manageability Provider:  Information Aggregation or Separation


The system providing manageability capabilities for a service must be aware of configuration of the service from the caller's point of view.  This configuration may be dependent upon external hardware or software options. Manageability may need to be implemented differently depending upon the requests made with respect to the caller's point of view.

Consider two examples.  The first case is that of a hardware routed service.  By this, we refer to the case where some hardware device offers up a service at, for example, http://external.example.com/theService.  Upon receipt of messages for that URL, the device forwards the messages to any service from the set
These services are identical, providing access to the same underlying business resource.

If, say, a query regarding metrics were made regarding the service http://external.example.com/theService, it is the responsibility of the provider of manageability to aggregate the results from the three underlying services to provide a meaningful response.

A second example is one wherein a single service is known by two distinct names.  In this case, consider the service at http://services.example.com/creditCheck.  External to the Example Company, this service is known as "http://ourservices.example.com/creditCheck", while internally, this service is known as "http://extservices.example.com/creditCheck".  However, in both cases, the underlying service is performed by the same machine, service, etc.  The service itself is aware of the means by which it is addressed, and it adjusts itself appropriately.

In this case, the provider of manageability must be similarly aware.  Queries regarding the two URL's must be accounted for separately, even though the underlying service is identical, quite possibly with the distinction between the two maintained only using different name servers.

-- 
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]