So that also means we should model a Cloud Association and Registration Service (CARS :) that just supports the Associate and Register operations and is the endpoint of the Cloud Print Provider. This service can be standalone (frontend) or part of the Cloud Print System Service.
On May 14, 2012, at 8:22 AM, Michael Sweet <msweet at apple.com> wrote:
> I think Pete is right that we need to show that registration and association go to the Cloud Print Provider (CPP), with registration creating the Cloud Print Service (CPS) that is associated with the Cloud Print Manager (CPM) for the "long term".
>> I'm also now thinking we should show the Cloud Print System Service (CPSS) that the client talks to, since that is how we've been talking about the CPP in recent meetings. The CPSS may not be the same service that the Client sends its Associate request to - Cloud services are much more dynamic and a particular user/organization may have specific resources assigned/dedicated to them. The common association/registration front-end interface directs Clients and CPMs to the appropriate Cloud services assigned for their use.
>> In the diagram we should show a receipt being returned by the CPP for Associate and Register requests. An Associate Receipt would return something like an OAuth2 token with the URI representing the CPSS (probably the same as the one used for the Associate request, but possibly a different service endpoint specific to the user/resources/geographic region), while the Register Receipt is the OAuth2 token along with the URI representing the endpoint for the CPS that is the Cloud's queue for the CPM.
>> Thoughts?
>>> On May 14, 2012, at 5:20 AM, "Zehler, Peter" <Peter.Zehler at xerox.com> wrote:
>>> All,
>>>> The main problem I have with the diagram is that it shows a Cloud Print Manager registering with the Cloud Print Service instead of the Cloud Print Provider. In my (protocol centric) view a upon the receipt of a registration request from a Cloud Print Service, or its agent, the Cloud Print Provider instantiates a cloud environment specific implementation of a Cloud Print Service. The requirements for that implementation are that it implements the PWG Print Service interface, exposes the appropriate objects and attributes, and externally conforms to the state models codified in the PWG model. At a later time the Cloud Print Manager will bind to the Cloud Print Service to provide updated status and capability information and to process Print Jobs destined for the physical printer(s) associated with the Cloud Print Manager.
>>>> I expect the normal cardinality would be one physical device per Cloud Print Manager and One Cloud Print Manager per Cloud Print Service. The PWG model accommodates both Fan-Out and Fan-In of Printers. This allows a Cloud Print Manager to “front end” a number of physical printers. Those printers can be collocated (i.e., printer farm) or distributed (e.g., FedEx printer in Google Cloud Print). Alternatively a single physical device could be associated with a Cloud Print Manager that registers multiple Cloud Print Services. The purpose of such a configuration could be to present different capabilities and/or different defaults for each of the Cloud Print Services.
>>>> The [Print] Client is shown sending an Association request to the Cloud Print Provider. Once the association is established and based on the policies in place for the associated user, a set of Cloud Print Services will be visible to the [Print] Client. The [Print] Client can then interact (e.g., query status, query capabilities, submit print jobs) with the Cloud Print Service.
>>>> Pete
>>>>>>>> Peter Zehler
>>>> Xerox Research Center Webster
>> Email: Peter.Zehler at Xerox.com>> Voice: (585) 265-8755
>> FAX: (585) 265-7441
>> US Mail: Peter Zehler
>> Xerox Corp.
>> 800 Phillips Rd.
>> M/S 128-25E
>> Webster NY, 14580-9701
>>>> From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of larryupthegrove
>> Sent: Friday, May 11, 2012 7:05 PM
>> To: cloud at pwg.org>> Subject: [Cloud] Cloud white board diagram from meeting - converted tovisio/pdf
>>>>ftp://ftp.pwg.org/pub/pwg/cloud/white/Cloud model representation.vsd
>>ftp://ftp.pwg.org/pub/pwg/cloud/white/Cloud model representation.pdf
>>>> Please review and I’ll update drawing before inserting into the cloudmodel draft.
>>>> Larry
>>>>>> --
>> This message has been scanned for viruses and
>> dangerous content by 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. _______________________________________________
>> cloud mailing list
>>cloud at pwg.org>>https://www.pwg.org/mailman/listinfo/cloud>> __________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
__________________________________________________
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/cloud/attachments/20120514/2dea9b2b/attachment-0002.html>