Alan,
I have read through the 2 Use Case Reports: Embedded Producers
and Customized
Producers. As tomorrow's discussion is focused on the
Embedded case most of my
questions pertain to
it. However I do have a general
question -- I was surprised
that "Customized
Producer" document reinvented alot of what was in the Embedded
Producers document -- By
reinvented I mean tackled alot of the same function though
at times a little
differently (What's all this stuff about stream oriented
operations anyway?). Am I correct that the "Customized"
case is merely the
"Embedded" case
plus the ability of the consumer to allow a producer to expose and
manage instance
settings? Can you clarify?
As for the embedded case, I need some help with
terminology. What are
properties? Are they "producer meta
data"? Are they arbitrary request
parameters? both?
What are WSIA portTypes?
Properties are part of the producer “contract”
in terms of the service’s basic capabilities.
They’re at the binding, as opposed to the request
level, and they’re supposed to be generally applicable to all
embedded services (as opposed to the customized case, in which we begin to talk
about producer-specific adaptations, including producer property sets.)
WSIA portTypes are the facility for describing the API for
adaptation/integration of embedded services, at the (WSDL) descriptor level. We’re looking at the work IBM did with WSXL
as a strawman implementation.
And then specifically on the document:
Section 1: Producers do not
publish an interface to the consumer other than for
invocation with generic
arguments. What does this mean? Why is this defined?
Basically stating that no
producer-specific adaptations are identified in the
interface (again, that’s the Customized
case). It’s supposed
to be an out-of-the-box, as-is integration, so the interface and configuration are very
generic.
Section 3.1.1: URL
rewriting: Note: <img> tags may
also need to be rewritten -- If
the portlet lives behind a
firewall the only way for a client to communicate to it
may be via the portal even
to get basic things like images.
Yes, we’re seeing that other markup entities may
require adjustment to be “contextualized” to the
consumer.
Section 3.1.1: User
profile: What discussions are you
having about privacy? How
does the consumer know
whether the end user wants the producer to have access to
its profile
information? Or is there a basic set of
profile information that users
give up their privacy rights
over?
We’re watching the discussions
in the WSRP security group with interest. We’ll probably align closely with what comes out of that effort.
Section 3.1.1:
Operations/Actions: What are
operations/actions? Why do they
exist? Are there consumer defined actions producers
must be aware of?
operation ~ action, we’ll need
to better account for the nuances here.
This is likely an area of discussion at the face-to-face next week.
Section 7.1: Lifecyle --
"We therefore introduce the concept of a 'Handle' as a
remote opaque reference to
an instance of the service -- this reference may be
equivalent to session
data.". Can you clarify what
handle this is? Is it a
persistent handle? Or merely a runtime handle? Given that "Embedded" doesn't
define customizations it
would seem to be the later.
I would agree, although we may opt to allow the
producer to specify one or the other, in anticipation that most
services are likely to be customizable anyway (even if a consumer opts not to
take advantage of it). The producer also may want a
persistent handle for their own purposes (fault tolerance? audit trail?).
Section 7.2.1: URL
rewriting: there is a need to insert an
additional parameter
(wsai:mapKey). Why? The document references a consumer
maintained mapping table
but doesn't motivate such a
thing -- what specifically is this mapping table used
for and why is it
needed? Even if its needed, why doesn't
the consumer generate
its own mapKey as its doing
the substitution?
In fact, we talked about this area in a call
this morning…you’re right, it’s vaguely outlined, and perhaps doesn’t even need
to be called out specifically in this document (i.e., an implementation
detail?)
Section 7.4.4: Are you planning on defining names or types
to represent markup
fragment rules? I.e. I can conceive of two different consumers
having two
different sets of markup
rules (one consumer embeds you in an HTML table while
another uses frames). In such a world don't the consumer/producer
need to
determine if they are
compatible by discovering each others capabilities?
We’re in the process of
collating a set of abstractions that a producer/consumer could rely on as the
>basic< vocabulary for exposing supported markup conventions. Of course, this can’t be
comprehensive, but we hope it’s able to address the common example you give,
and others like it. Again,
we’re watching the relevant discussion in WSRP closely for guidance in the
portal/portlet scenario, and we’ll abstract from there.
Section 7.6.4: A producer
must specify its supported properties.
Why? or at least
Why all of them? This goes back to my initial questions
concerning what properties
are. I understand why you would specify what WSIA
properties you support but its
not clear why anything else.
I don’t believe we’re talking
about anything but WSIA properties. I suppose
that should be more clearly worded.
Section 7.7: Output --
Thomas raised the question/need that a producer may generate
output that has to be
aggregated into different locations in the markup. Is this
something that should be
covered/identified here?
I’ll have to
review his comments…examples?
-Mike-