Pete,
On Dec 11, 2013, at 9:44 AM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
> All,
>> The thing that confused me about the diagram was the dotted line from the Proxy to the Local System Control Service. It is my view that the Local System Control Service is just another service hosted on the MFD. (Yes I know that an implementation could host the services outside the MFD but from a functional view they are hosted on the MFD.)
Absolutely, I just wasn't sure whether the proxy needed to talk to the local System Control Service...
> One difference I see with a Local System Control Service is that in addition to interactions with the Physical Device it would also interact with the other hosted services. It must do so in order to control the other service and to access the other services instrumented data. The other difference between the Local System Control Service and other hosted services is that the Local System Control Service would have an unfiltered view of the devices subsystems.
Right, however that interface is going to be a lot different than the service-level interfaces shown in the diagram. Perhaps some sort of the containing box
> The other devices would have a service specific view of the subsystems (e.g., Print Service does not present the scanner subunit). Of course this difference would not be obvious from the diagram. While not included in this discussion the Physical Device could easily be replaced by a Physical Device Proxy and the model hold together.
Right. Again, my focus with this diagram was just to show the typical/common situation. If we can find a way to expand its scope without confusing things too much, all the better.
> I would replace the lower portion of Mike’s diagram with something similar to the following diagram. I also added a comment to #3 below.
I'd like to come up with a different way to show the relationship between the System Control Service and other services. And maybe that applies to the interface between the services and physical device/subunits as well? (not a service-level interface and not something we document in the Cloud or Semantic Models...)
> ...
> 3. According to the Semantic Model, there is an extensive client interface to the System Control Service that provides access to both System Control Service elements and System Object elements (SystemConfiguration, SystemDescription, and SystemStatus). However, the diagram shows no System Object either at the Cloud Level or the Local level (“Imaging System” in the lower right hand corner not withstanding.) The sort of information that a User might want to know about the physical location of the “device” (however one may wish to define it) is in the System Description. The UUID for the imaging device is the System UUID. I suggest that, as in the previous diagram, there is both a Cloud Imaging System and, if we are showing things beyond the Proxy, a Local Imaging System.
>> Adding the system object to the diagram would probably be useful. I'm not sure how we would show connections *to* this object, or whether we should (for purposes of simplifying the diagram) just update the system control service boxes to be "system control service and system object"?
> <PZ>The System Object is a construct created and maintained by the Local System Control Service just as the Print Service Object is created and maintained by the Local Print Service. Some of the attributes from the System Object are obtained from the Physical Device, other attributes are obtained from the other Local Services, and some are properties specific to the instance of the Local System Control Service. I do not see any conflict in the other Hosted Services presenting information (e.g., System UUID, physical location) that is “owned” by the Local System Control Service as long as the values are consistent.</PZ>
OK, so do you think we could just leave the system object out of the diagram then?
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20131211/ae0cbd90/attachment.html>