Glen,
Comments inline...
On 2013-04-30, at 11:44 AM, "Petrie, Glen" <glen.petrie at eitc.epson.com> wrote:
> ...
> 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).
>
Right.
> 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.
>My thought was this: the Cloud Provider sets up the Cloud Imaging Control Service (probably when the User/Owner creates an account with them, or as part of a larger "always on" service supported by the Cloud Provider where account creation gives you limited access), and the Cloud Imaging Manager "registers" by starting Cloud Print/Scan/etc. Services through the CICS. Starting services is already something that is defined by the SM System Control Service.
Remember, the CICS doesn't talk to the MFD or the CIM, the CIM talks to the CICS. Having the CIM start the individual services gives the MFD owner control over which services are provided via the Cloud, and conversely the CICS can control which services it allows the CIM to start.
> 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.
>Understand, one of the reasons I am so keen on having a Cloud version of the SM System Control Service is that it solves the "how do I instantiate/discover a Cloud XXX Service" problem without defining the implementation of the overall Cloud solution (the registration/account creation "problem").
So my goal is not to define Registration but Service Instantiation/Discovery. The creation/registration of a CICS is out-of-scope - for the purposes of the Cloud Imaging Model we can say it is pre-existing/provided by the Cloud. But that pre-existing CICS allows the CIM to start whatever services it wants to provide and the Clients to determine which services are available via the CICS.
> 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.
>
We have been using "Association" for Users/Clients and "Registration" for MFDs/CIMs. And conceptually a CICS is always running (or appears so) without requiring additional, out-of-band communication with the Cloud Provider after the initial out-of-band association/registration that creates the CICS.
> 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.
>Supply levels, alerts, input and output trays, page counters, etc. Basically all of the status groups in the Semantic Model - read-only since my focus is on monitoring and not on remote-control/management.
> 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?
>
For example, adding or removing MFD services that are available via the Cloud, changing default and supported settings on the MFD (e.g. forcing duplex, limiting the list of media that is available), managing description elements (name, location, organization, etc.), and so forth.
(basically everything that CWMP is trying to do)
> ...
>> 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.
>
Both, actually. To the CICS to find the service the Client is interested in, and to the Service itself to submit jobs, monitor jobs, etc. The Client could, of course, cache the Service information and/or discover it through other means.
(this mirrors how Clients do things locally)
--
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/20130502/57e09f76/attachment-0002.html>