Hi Paul,
I don't know about the name, nor how well it resolves any problems, but I
think there is some justification for what you call a Notification Service.
The idea of the model is to define a conceptual interface (that is, the
communication between actor elements). In network printing, the actor
elements are the traditional Client and Service. IPP went a bit further and
showed the Service as an IPP Printer composed of a IPP Server and an IPP
Print Service (although the defined interface was just to the IPP Service.)
The Semantic Model V2 gets into much more detail in the conceptual
components of a service and further, packages the Services into a System
(although Peter seems to suggest that the System was just an artifice).
In the Cloud model, it was necessary that the "local" services have an
interface with the Cloud Services. Although we have allowed Services to have
"client" capabilities before (for cascading services), this Local -Cloud
Service interface was different from the Client Service interface, so we
created a "Proxy" between a local service and the Cloud Service. The
Cloud Services are to accept this new interface with the Local Proxy.
Therefore, although the Cloud Imaging Service supports the same Client
interface as a Networked Imaging Service, it must also support the Proxy
interface, which requires that the conceptual components of a Cloud Imaging
Service different from and corresponding non-cloud Imaging Service. But I
doubt that either the Cloud WG or the SM WG will do a conceptual breakdown
of a Cloud Imaging Service. So it might be more convenient to keep the Cloud
Imaging Service the same as a Network Imaging Service and have it's "Client"
capabilities interface with a Cloud based Proxy that in turn interfaces with
the Local Proxy. This Cloud Based proxy would have two "service" interface
sets (and perhaps more, for supporting asynchronous notification) as
distinguished from the Local Proxy that has two "client" interface sets.
Although, from the model viewpoint, the Cloud Imaging Service to Cloud Proxy
interface is "internal" and not specified just as the Local Proxy to Local
Imaging Service interface is "internal" and not specified, it would be a
good exercise to see if both these interfaces could be satisfied by the
already established basic Client-Imaging Service interface set. The Cloud
Based Proxy could also aggregate communications for all the Cloud Imaging
Services it supports just as the Local Proxy aggregates communications for
all of the Local Imaging Services it supports. And asynchronous cloud to
local communication could be between the two proxies.
This would be interesting to discuss on Monday.
Thanks,
Bill Wagner
From: Paul Tykodi [mailto:ptykodi at tykodi.com]
Sent: Thursday, January 02, 2014 3:11 PM
To: 'William A Wagner'; cloud at pwg.org
Cc: ipp at pwg.org; 'Semantic Model 3.0 Workgroup discussion list'
Subject: RE: [IPP] Cloud Concall Jan 6 at 3PM EST
Hi Bill,
Happy New Year to you as well! Thank you for all the effort you have put
into the forthcoming Cloud specification to date.
Overall I think your approach is sound and that it addresses the challenges
of implementing the PWG Semantic Model within a Cloud environment quite
well.
In terms of the issues you raise in point #4 below, do you believe we could
resolve them by creating a notification service to handle the communication
about the status of jobs and services?
Thanks.
Best Regards,
/Paul
--
Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC
Tel/Fax: 603-343-1820
Mobile: 603-866-0712
E-mail: ptykodi at tykodi.com
WWW: <http://www.tykodi.com/> http://www.tykodi.com
This e-mail reply and any attachments are confidential and may be
privileged.
If you are not the intended recipient, please notify Tykodi Consulting
Services LLC
immediately by replying to this message and destroying all copies of this
message
and any attachments. Thank you
From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of William
A Wagner
Sent: Thursday, January 02, 2014 2:21 PM
To: cloud at pwg.org
Cc: ipp at pwg.org; 'Semantic Model 3.0 Workgroup discussion list'
Subject: [IPP] Cloud Concall Jan 6 at 3PM EST
Happy New Year! We have a Cloud WG conference call scheduled for Monday 6
January at 3 PM ET. There was some interesting traffic on the mail list
last month, but unfortunately no resolution to the impasse that we seem to
have arrived at. We cannot seem to get past the description of operations
and I have concluded that this is a problem with the model itself in that it
is not consistent with the structure that the IPP WG has in mind. Since, so
far as I understand, IPP has not really addressed the concept of an Imaging
System and perhaps thinks it unnecessary even for entities performing
multifunction services. The model I proposed (and which appeared to be
accepted) is system oriented in that information common to multiple
services was provided through the system but information specific to a
service (such as job specific information) was provided by the corresponding
service.
I have no wish to impose a particular model upon the group, but I cannot
continue with the specification without a model approach that the working
group and I understand. I proposed an approach last month (below), to which
I have received no response. This would eliminate all System communication
(and mention) with respect to using Imaging Services via the Cloud (I have
updated the diagram). Since this would be a major rewrite of the
specification ( and all of the sequence diagrams). I would not proceed with
his approach without active working group consensus.
I suggest that establishing a model approach, either based on what I propose
or some other ideas, be the subject of Monday's conference call. Based on
consensus (or lack of same, or lack of comment), we can decide whether
continue this project is warranted.
Thanks,
Bill Wagner
From: William A Wagner [mailto:wamwagner at comcast.net]
Sent: Thursday, December 12, 2013 2:22 PM
To: 'Michael Sweet'
Cc: 'cloud at pwg.org'; 'ipp at pwg.org'; 'Semantic Model 3.0 Workgroup discussion
list'
Subject: RE: [Cloud] Simplified Cloud Imaging Diagram for a typical MFD
All,
My intention is to determine how (and whether) to proceed with the Cloud
Model specification. It is apparent that there was some basic difference in
my approach and IPP SIX, and in attempting to address specific comments
(such as the name and content of what is now GetSystemNotification), I was
just hiding the inconsistency.
I propose a few points to revise the Cloud Specification in way that it will
not raise IPP objections. If these can be resolved, I will proceed with the
Cloud document.
1. The model deals with use of the Imaging Services, not with
administration/management/maintenance. Or, if communication for
administration/management/maintenance must be addressed, it be in a separate
section.
2. Eliminate all reference to Device (whatever its meaning). All
specified communication is to Services from Proxies or Clients. Necessary
information relating to physical entities is obtained via Services. I would
like to retain System as an element that contains Services that are somehow
related in that the SystemControlService is aware of them.
3. Although we should understand how communication from Proxy to the
Local Services could be conducted using the standard network interface
identified in the Semantic Model, defining that communication is not a
part of the Cloud Imaging Model and is not in the specification. It might
provide the basis for a useful white paper.
4. In an attempt to define a more efficient Proxy-Cloud communication,
the current Cloud Imaging specification provides for registering and
maintaining communication on System basis (via the Proxy and the
CloudSystemControl Service) as well as on an Imaging Service basis. The idea
was to communicate information common to multiple Services just once rather
than for each Service. I proposed this expecting some objection. But the
comments just acted to overload this communication with information that a
SystemControlService would not normally have. That is, the Proxy has the
ability to aggregate and communicate information from all local Services; it
is perhaps unreasonable to add this requirement to the
CloudSystemControlService to the extent that it knows, for example, what
Jobs are canceled, etc.
a. The model can be simplified to just deal with imaging services. The
Proxy does not register the Local System with the CloudSystemControlService
nor does it communicate with the CloudSystemControlService. Information for
each Local Service is communicated to the corresponding Cloud Service
independently via the Proxy. The Proxy must periodically query each Cloud
Service with a GetFetchableJobs, and probably with a channel check and a
check for canceled jobs. GetSystemNotifications goes away, at least for
non-management functions.
b. Alternatively, we posit some other service associated with the
Cloud Imaging System that has detailed access to all associated Cloud
Services.
Thanks for your consideration and comments.
Bill Wagner
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
William A Wagner
Sent: Wednesday, December 11, 2013 11:58 AM
To: 'Michael Sweet'
Cc: cloud at pwg.org; ipp at pwg.org; 'Semantic Model 3.0 Workgroup discussion
list'
Subject: Re: [Cloud] Simplified Cloud Imaging Diagram for a typical MFD
Michael and Ira,
I offer the following observation, subject of course to expert comment.
The IPP multifunction approach is evolving from IPP where there was just one
type of service and the client dealt just with a Printer Object, that it
accessed via a print service. Any necessary information about the physical
"output" device came though the Service connection. I am not sure how IPP
multifunction will evolve, but it could also have the normal user deal with
just the service he is interested in and any necessary information about
the "endpoint" comes though the Service connection. The IPP "System Control
Service" would then be devoted to monitoring and management of the "Imaging
System" and any physical components that were a part of it.
True, the Semantic Model evolved from IPP. But the current version of the
Semantic Model specifically addressed an MFD, considering how to handle
multiple types of imaging services. So the Printer became expanded to an
Imaging System and a System Control Service was defined to provide access
to System Elements. I have perhaps overstressed the "Imaging System" and,
as Ira points out, the system may not relate to a device in the case of a
distributed .. Perhaps the basic imaging services user need never even be
aware that there is a system.
So, if I drop my MFD mindset, a reasonable network model has the Imaging
Services User just accessing the desire imaging service. Access to the
System Control Service is limited to supervisory/management/maintenance
users. As far as the basic User is concerned, there is no Imaging System
and no *Imaging Device*; there are Services and elements in the Service
provide information on the location of the endpoint, the IPP *physical
device*.
However, for practical purposes, there may still be justification for the
Proxy to access the Cloud System Control Service (or some other Cloud-based
component) that can provide/accept summary information for/from the Proxy
just as the Proxy can provide summary information for the Local Services.
The alternative, which would be simpler but involve more traffic, would be
for the Proxy to just communicate with each Cloud Service independently.
So, the diagram would show the both Cloud and local Services (including
System Control Service) as being within Imaging Systems and the Proxy would
interface with each Cloud Service and each local service.
Thanks, Bill Wagner
Basic Model 2.jpg
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Wednesday, December 11, 2013 9:04 AM
To: William A Wagner
Cc: <cloud at pwg.org>; <ipp at pwg.org>; Semantic Model 3.0 Workgroup discussion
list
Subject: Re: [Cloud] Simplified Cloud Imaging Diagram for a typical MFD
Bill,
On Dec 11, 2013, at 1:24 AM, William A Wagner <wamwagner at comcast.net> wrote:
Michael,
Thank you for the diagram. Some observations, rather that objections,
particularly in areas that appear different from the model and diagram we
had previously agreed to and that seem inconsistent with the Semantic Model.
1. We had avoided showing the interface between the proxy and local
services, although the intention in defining the Proxy->Cloud operations
was that the Proxy could communicate with the local services using the
standard client-imaging service operations.
True, but since we had our discussion in Monday's Cloud concall I felt it
might be useful to expose it, at least for a "big picture" diagram. And
this *does* mirror the IPP model diagrams in RFC 2911 and IPPSIX (figures 1
and 3) where a local print service is connected to the IPP Server or IPP
Proxy. IPP Server + Print Service == IPP Printer.
2. But having shown these connections, I wonder about the dotted line
from the proxy to the Local System Control Service. I would expect that the
Proxy acts as a proxy for the Local System Control Service to the same
extent that it acts for the imaging services.
I made the line dotted mainly because we hadn't defined a concrete
relationship - the proxy might get a list of services to register from the
local system control service *or* it might get it from another source (web
interface, etc.), which gets it from the local system control service.
Architecturally we may not care beyond the fact that the Semantic Model
defines the local system control service in the model for an imaging
device/system - that is something we should probably decide on and document
in the Cloud model.
3. According to the Semantic Model, there is an extensive client
interface to the System Control Service that provides access to both System
Control Service elements and System Object elements (SystemConfiguration,
SystemDescription, and SystemStatus). However, the diagram shows no System
Object either at the Cloud Level or the Local level ("Imaging System" in the
lower right hand corner not withstanding.) The sort of information that a
User might want to know about the physical location of the "device" (however
one may wish to define it) is in the System Description. The UUID for the
imaging device is the System UUID. I suggest that, as in the previous
diagram, there is both a Cloud Imaging System and, if we are showing things
beyond the Proxy, a Local Imaging System.
Adding the system object to the diagram would probably be useful. I'm not
sure how we would show connections *to* this object, or whether we should
(for purposes of simplifying the diagram) just update the system control
service boxes to be "system control service and system object"?
4. The diagram does not clear up the difference between a IPP Physical
Device and a Semantic Model Device. By the SM definition definition,
the Imaging Services are physically embodied within one or more physical
devices. In most cases ( and certainly for a basic MFD), the Imaging System
represents the elements of the Device and the System Control Service
provides access to the values of these elements. Therefore, in an SM based
model, I suggest that there are no lines from Imaging Services to the
Device. Indeed, after the last Cloud call, I am eliminating all reference to
"Device" as an actor in the cloud specification, in favor of System.
Ira made some good comments, but I'll add one: you'll notice that the proxy
is only connected to services. Only the local services are connected to the
physical device. I believe that both mirrors our discussions and matches
the Semantic Model and IPP notions of separation.
5. You presented a good argument for making IPP Identify Printer a
service operation, primarily by stating that a normal user would be using a
connection to a Imaging service not the System Control Service. I am unsure
of the intent or limitations of the Client to Cloud System Control Service
path shown in the diagram (is ListAllServices the only operation allowed?)
However, although discovery is nominally of Imaging Services, it seems that
the in the Semantic Model physical elements of interest in discovery should
be accessed via the System Control Service, suggesting that a normal client
should have at least read access to the System Control Service. It would
seem reasonable that it could also trigger an Identify via this path.
I should probably remove all of the operation names from the diagram and add
letter/number identifiers (as Smith has suggested). I shows
"ListAllServices" as the most likely operation a client would use in order
to discover which imaging services are available, in preparation for
creating a job, etc. on a specific service. Clearly the client would be able
to perform any supported operation of the system control service, and I
agree IdentifyDevice is one of the expected operations.
So, the diagram appears to reflect a IPP model using IPP terminology and
does not reflect the Semantic Model of a System containing Services with
system specific elements accessed via a System Control Service. Am I missing
something?
Actually, I believe the bottom half of the diagram looks a lot like Figure 6
of MFD Common Model (PWG 5108.1), just turned on its side and combining the
marker and scanner subunits as the "physical device" (also a SM term that is
shared with IPP - perhaps you would prefer "Multifunction Device" or
"Multifunction Device/Subunits" here?)
...
Please remember: Semantic Model came from IPP. While some of the terminology
was changed in the move to support multifunction services, and some of the
responsibilities are moved around (i.e. system control service), the overall
model remains the same. The IPP Printer is an IPP Server talking to an
Imaging Service, just as a web service binding using the Semantic Model
schema and WSDL files is an XML-RPC server talking to an Imaging Service.
In both cases the imaging services are talking to the hardware subunits (as
needed) with implementation-defined coordination with the System Control
Service.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140102/a3164eb1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 42347 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140102/a3164eb1/attachment.jpg>
