Hi Mike,
Good idea. See comments below.
Glen
________________________________
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Michael Sweet
Sent: Tuesday, April 30, 2013 4:58 AM
To: cloud at pwg.org
Cc: mfd at pwg.org
Subject: [Cloud] Some random thoughts about the Cloud Imaging
(Control?)Service
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:
[gwp] I like your name "Cloud Imaging Control Service" (CICS). I am
assuming, for the simplest case (no fan-out), there is one CICS for each
MFD (or if you like Device Manager).
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.
[gwp] I don't understand the concept of the CICS "creating new
services". I thought that when an MFD is registered with the Cloud
Provider; it will now be the CICS that is "created" and that the CICS
will already know or poll the MFD for the supported (sub-)services of
the MFD. These CICS sub-services (print, fax, etc) would be to be
advertised the same way Transform Service would provide a list of its
(managed) sub-services. I believe the PWG should table, for a later
time, any activity that defines or creates an entity "... providing a
way for use to define registration of ...." We already have lot to
handle already and individual Cloud Providers will have their own method
and processes for registration. Defining an MFD common registration
process can be done later and independent of the current work.
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.
[gwp] I understood that Users are associated with Cloud Services via a
registration process provided by the Cloud Provider and not by Clients.
Thus, the CICS, at registration, enumerates the available sub-services
to the Cloud Provider Registration Process; during registration, the
Owner defines which sub-services are available for use and to whom.
When a specific User registers with the Cloud Provider or at some later
date; it is the Cloud Provider Registration Process that lists the
available services that the specific User can be associated with. It
would then be the Cloud Provider that will provide the list of available
services to the Client. Once the User has selected a services, the
Cloud Provider invokes the correct CICS with the identified sub-services
being requested.
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
[gwp] can you elaborate some more.
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.
[gwp] What types of remote management?
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:
[gwp]
Client <------> Cloud Provider
|
/------/
|
+----------> Cloud Imaging Control Service for MFD #1
| | |
| \ +------ Cloud Print Service -\ <<< Not
available to this User
| \---> +------ Cloud FaxOut Service -+<----- Cloud
Imaging Manager
| +------ Cloud Scan Service --/
|
+----------> Cloud Imaging Control Service for MFD #2
| | |
| \ +------ Cloud Print Service -\
| \---> +------ Cloud FaxOut Service -+<----- Cloud
Imaging Manager
| +------ Cloud Scan Service --/ <<< Not
available to this User
|
...
|
+----------> Cloud Imaging Control Service for MFD #n
| |
\ +------ Cloud Print Service -\
\---> +------ Cloud FaxOut Service -+ <----- Cloud
Imaging Manager
+------ Cloud Scan Service --/ <<< Not
available to this User
Once the Clients selects the (Sub-)Service then question is whether the
client goes through the CICS or communicates directly with sub-service.
Either way would be ok; just need to decide.
Client <------------> Cloud Imaging Control Service for MFD #14
|
+-----> Cloud FaxOut Service -+<----- Cloud
Imaging Manager
OR
Cloud Imaging Control Service for MFD #14
|
Client <-------------------> Cloud FaxOut Service -+<----- Cloud Imaging
Manager
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 <http://www.mailscanner.info/> , and is
believed to be clean.
--
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/cloud/attachments/20130430/01e06cef/attachment-0002.html>