[Cloud] Some random thoughts about the Cloud Imaging (Control?)Service

[Cloud] Some random thoughts about the Cloud Imaging (Control?)Service

Ira McDonald blueroofmusic at gmail.com
Tue Apr 30 16:42:24 UTC 2013


Hi Mike,

Excellent idea.

Re-using SM2.0 SCS and extending it for Cloud and Software Defined Network
environments makes much more sense.

I agree with all of your suggestions for exposing OutputDevice (noting
that for Scan and FaxIn we need the corresponding InputDevice).

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Tue, Apr 30, 2013 at 11:44 AM, Petrie, Glen
<glen.petrie at eitc.epson.com>wrote:

>  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* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
> _______________________________________________
> cloud mailing list
> cloud at pwg.org
> https://www.pwg.org/mailman/listinfo/cloud
>
>

-- 
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/e2ab6d06/attachment-0002.html>


More information about the cloud mailing list