I agree that considering what we have been calling the Cloud Imaging
Service as a cloud-based System Control Service is attractive in that it
is not restricted to a given imaging service and that the function of
exposing services to clients is common. However, I think of this Cloud
entity (what we call the Cloud Imaging Service) as more a virtual Imaging
System (or MFD), including a System Control Service. According to the spec,
" The SystemControlService responds to queries about the System Object's
configuration, status and descriptive information. The SystemControlService
acts upon requests to modify the System Object." Therefore, the System
Control aspect applies to the configuration of the Cloud Imaging entity.
But in actually providing the imaging services, the Cloud Imaging entity
embodies the characteristics of the MFD , what I think is referred to as the
System Object itself.
The System Control Service aspect would be the way we address creation
(which is to say, exposing) and modification of the available services
(although there is still the question of creation of the Cloud System
Control Service.) I agree that working on a Cloud parallel to the System
Control Service would be a good approach to the management of the Cloud
accessible imaging services . And I agree that including this aspect would
provide a more complete model. I also have concerns about taking on too
much right now. But I think it should be considered.
From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of Petrie,
Glen
Sent: Tuesday, April 30, 2013 11:45 AM
To: Michael Sweet; cloud at pwg.org
Cc: mfd at pwg.org
Subject: [MFD] RE: [Cloud] Some random thoughts about the Cloud Imaging
(Control?)Service
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 <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, 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/710fc1b1/attachment-0002.html>