Michael,
There are, typically, multiple valid solutions to an engineering problem,
and insofar as IPP plans to provide a complete solution to multifunction and
cloud imaging, it is unclear that there is any advantage in pursuing an
abstract model. At this point, I admit that I do not understand the IPP
approach to multifunction or whether there is a system, and the Cloud model
we are dealing multifunction. So maybe we should just wait until those
concepts are clear in IPP.
1. With respect to the notification service, I agree with your objection.
And from the Semantic Model, the System Control Service does not deal with
jobs, so aside from reporting on the existence and state of system services,
it cannot provide information on Jobs. So we are left with the local proxy
communicating with individual Cloud Services, or the idea of a Cloud proxy
that parallels the local proxy function. This Cloud Proxy just a modeling
component allowing the cloud services to remain modeled as classical imaging
services supporting no new operations, and allows the local proxy some
efficiency in communicating with just one cloud endpoint. However, the idea
of a common point for Cloud Imaging System Communication assumes that there
is an Imaging System and not just isolated imaging services. It seems to me
that IPP does not yet include the concept of a system containing multiple
imaging services of different types, so no aggregating element that Cloud or
SM define will find a match in IPP.
At any rate, we can have the local proxy communicate with individual
services as you suggest, although since the communication is with a specific
service, it would seem that GetNotifications rather than
GetPrintNotifications, GetScanNotifications, etc would be sufficient.
2. IPP devices and SM devices are not the same. An SM Device represents the
hardware implementing one or more services and exposes all subunits involved
in those services. Although not specifically stated, a device appears be the
hardware containing the System. The model itself does not identify a device
as distinct from a system. An IPP device appears to be some collection of
subunits but does not correspond to a service.
I think it reasonable that in the Cloud Imaging model, we do not concern
ourselves with device or subunit management. If the Semantic Model intends
to address subunit management, the subunits are associated with each service
(except, oddly, the system control service). I certainly do not understand
the comment " System Control Service is responsible for maintaining the
state of all devices and subunits managed by the System Object."
Thanks,
Bill Wagner
----------------------------------------------------------------------------
--------------
-----Original Message-----
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Michael Sweet
Sent: Monday, January 06, 2014 11:18 AM
To: <cloud at pwg.org>
Cc: <ipp at pwg.org>; sm at pwg.org
Subject: [Cloud] Normalizing the Cloud Imaging Model with the Semantic Model
and IPP
All,
After reading through some of the email traffic over the holiday break, I'd
like to outline some of my thoughts regarding how I think IPPSIX fits with
the Semantic Model and how we should proceed with adding notifications to
the Semantic Model.
1. Notification Service
I don't see how a first-class notification service makes sense. As
implemented in IPP, notifications describe state changes to a Printer
(service and its constituent devices/subunits), its Jobs, and its Documents.
In the Semantic Model, this would mean that all services could support
notification operations (Create<service>ServiceSubscription,
Create<service>JobSubscription, Renew<service>Subscription,
Cancel<service>Subscription, Get<service>Notifications) and job ticket
elements (Subscriptions group?) Naturally, services that are not job-based
would not support job subscriptions.
If you wanted to monitor for service/device state changes across all
services, you would talk to the System Control Service and send a
CreateSystemServiceSubscription request with a list of events you are
interested in. And then poll using GetSystemNotifications requests.
Depending on the binding you could have GetSystemNotifications support the
usual wait-for-events, maximum time to wait, etc. and also include a
recommended polling interval in the response (just like IPP already does).
That just leaves how a Proxy might efficiently be notified when it has work
- since the System Control Service isn't a job-based service and does not
have visibility into the jobs of each service, it can't generate JobXxx
events for the Proxy so it knows to ask a particular service for updates.
The simplest solution is to just have the Proxy talk to each of the services
it is registered with - GetPrintNotifications, GetScanNotifications, etc.
2. Devices and Subunits
Both IPP and the Semantic Model have a notion of devices (Output Device in
IPP, Imaging Device in SM) with associated subunits (marker, input trays,
output trays, etc.). Subunit state for all devices is reported through the
corresponding attributes/elements, with a roll-up state in the
printer-state-reasons attribute/StateReasons element. There is no way to
associate subunit state with a particular device, although MOST services
only have a single associated device.
For IPPSIX I added operations and attributes that allow a Client to query
and a Proxy to supply/update the state of a particular device and its
subunits. This is needed not only to support the existing fanout model in
IPP and the Semantic Model, but to allow multiple Proxies to communicate
with a single Infrastructure/Cloud service - otherwise a Proxy would always
be responsible for state roll-up of all associated devices and subunits
(right now it is an implementation choice).
One of the key concerns I've heard with this approach is that, in the
Semantic Model, the subunit state is read-only and System Control Service is
responsible for maintaining the state of all devices and subunits managed by
the System Object. My response to this is:
1. Subunit state management and propagation is an implementation detail and
not part of the model. Specifically, the Semantic Model does not define an
interface between the services for coordination, etc.
2. Correlation of subunits with services and devices is likewise an
implementation detail and not defined by the model.
3. The new operations manipulate separate sets of device attributes and not
the read-only roll-up attributes reported by the Printer/Service.
Thus, I don't think we have a problem with extending the Semantic Model to
support Get/Set<service>DeviceElements operations. The semantics of those
operations can be well-defined and how a particular Imaging System does
correlation and roll-up of the device elements/state can remain an
implementation detail.
(conceptually we could add/expose DeviceId elements to each of the subunit
status groups to formally correlate a subunit with a device; the
inter-service interfaces would still be an implementation detail but it
would make external correlation possible)
Thoughts?
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair