All,
At yesterday's conference call we talked about the Cloud Imaging Service as a front-end or "meta" service that provided a coherent view of all MFD services registered with a Cloud Imaging Manager/Imaging Device. This service necessarily would need to be able to report all of the service endpoints, names, and types so that a Client or Cloud Imaging Manager would know which services were provided/registered and where, very much like the SM System Control Service.
I've been thinking some more about that and I think the Cloud Imaging Service *is* basically a SM System Control Service with additions to support the interface with the Cloud Imaging Manager. There are several advantages to this approach:
1. A System Control Service provides operations for creating new services, providing a way for us to define registration of new Cloud Imaging Managers/Imaging Devices with the Cloud Provider, something that we had previously tabled as out-of-scope. IMHO, this makes for a much more compelling model that has a chance of basic interoperability from the initial configuration of the Imaging Device.
2. A System Control Service provides a common interface for Clients to enumerate the available services they are interested in, vs. using a different interface depending on whether Cloud or local devices were being accessed.
3. A System Control Service provides a view of all subunits managed by its services; this opens up some interesting managed service options that would otherwise need to be handled through other, proprietary means
4. A System Control Service would allow us to address remote management of Imaging Devices (vs. services), although I believe we should still keep this out-of-scope for the 1.0 document.
In addition to the Cloud Imaging Manager operations, there are a number of additions I think we should make to the existing SM interface as well, which would affect *all* SM services:
1. Provide a way to get Imaging Device specific elements; in IPPSIX this is the new Get-Output-Device-Attributes, which returns the Printer attributes associated with a given device UUID - this is the converse of the Set-Output-Device-Attributes operation that is sent by the Manager to update/set the current configuration/capabilities of the device.
2. Add elements to enumerate the Imaging Devices associated with a service; for IPPSIX I just added parallel attributes called device-uuid, device-uuid-assigned, and device-uuid-supported.
3. Add elements to the Job and Document status groups that show the state on the Imaging Device assigned to that Job or Document. In IPPSIX these are the output-device-document-state, output-device-document-state-message, output-device-document-state-reasons, output-device-job-state, output-device-job-state-message, and output-device-job-state-reasons attributes.
All of the new Imaging Device elements and operations would probably remain optional for non-Cloud usage (implementations/administrators get to choose whether this information is exposed, just as in SM 1.0), but for Cloud I think we have to expose it in order to support the Cloud Imaging Service - Cloud Imaging Manager interface.
Finally, if the Cloud Imaging Service *is* a superset of the SM System Control Service, it might make sense to change the name to Cloud Imaging Control Service. That would express the hierarchy and heritage in (hopefully) a less confusing way:
Client -------> Cloud Imaging Control Service
| |
+----------> +------ Cloud Print Service -\
| +------ Cloud FaxOut Service -+<----- Cloud Imaging Manager
\ +------ Cloud Scan Service --/
\ |
\ +------ Cloud Print Service -\
\-------> +------ Cloud FaxOut Service -+<----- Cloud Imaging Manager
+------ Cloud Scan Service --/
|
...
|
+------ Cloud Print Service -\
+------ Cloud FaxOut Service -+<----- Cloud Imaging Manager
+------ Cloud Scan Service --/
Thoughts?
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20130430/e7bc10bc/attachment-0002.html>