wsdm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsdm] MOWS Request Processing Digest Notification Act in Interop Scenario.
- From: "Sedukhin, Igor S" <Igor.Sedukhin@ca.com>
- To: "Heather Kreger" <kreger@us.ibm.com>
- Date: Fri, 11 Mar 2005 11:58:05 -0500
sure
-- Igor Sedukhin
.. (igor.sedukhin@ca.com)
-- (631)
342-4325 .. 1 CA Plaza, Islandia, NY
11749
Should we add this to our action
items list?
Heather Kreger
STSM,
Web Services Lead Architect for SWG Emerging Technologies
Author of "Java and
JMX: Building Manageable Systems"
kreger@us.ibm.com
919-543-3211 (t/l 441)
cell:919-496-9572
"Sedukhin, Igor S"
<Igor.Sedukhin@ca.com>
03/09/2005 07:51 PM
|
To
| "Mitsunori Satomi"
<Mitsunori.Satomi@hds.com>,
<wsdm@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsdm] MOWS Request
Processing Digest Notification Act in Interop
Scenario. |
|
Well, right. The [mows-events:ManageableEndpoint] is a relic. I
don't
even know how come nobody including myself ever noticed it there
before.
That same section contains topics noted with the relic and without
the
relic. In any case, this is not a critical issue, as you say since
topic
space says it all properly anyways. I would consider this as an
errata
for the after-interop time.
--
Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11749
-----Original
Message-----
From: Mitsunori Satomi
[mailto:Mitsunori.Satomi@hds.com]
Sent: Wednesday, March 09, 2005 7:09
PM
To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
Subject: RE: [wsdm]
MOWS Request Processing Digest Notification Act in
Interop
Scenario.
Igor,
> -----Original Message-----
> From: Sedukhin, Igor S
[mailto:Igor.Sedukhin@ca.com]
> Sent: Thursday, March 03, 2005 8:29
AM
> To: Mitsunori Satomi; wsdm@lists.oasis-open.org
> Subject: RE:
[wsdm] MOWS Request Processing Digest Notification Act
in
> Interop Scenario.
>
>
Mitsunori,
>
> That is right it should be "Identity". I'll fix
that.
>
> Regarding the MOWS doc. The mows-events:ManageableEndpoint
is the name
> of the topic space. We've
used that to differentiate as the WS-Topics
> spec is not very clear as to
what the name of the topic space should
> be used for. Those path are only
for documentation purposes, though.
> They could not be used when
subscribing because one MUST always refer
> to normative definition of the
topic space at the end of the document
> and then pick a dialect to
express it when subscribing. I would remove
> that prefix in MOWS if we had set for a notation we'd use for
topic
> paths across the documents. I don't think we did,
actually.
I understood that
"mows-events:ManageableEndpoint" is the name of topic
space.
I guess that
in MOWS spec., we define the name of topic space as "MOWS"
so to use this
name ("MOWS") instead of "mows-events:ManageableEndpoint"
is another choice
to describe topic path. But this is not
critical
issue.
> I noticed that all
of the WSDM specifications do not describe the
> notation used for
notification topics. We do describe all other
> notations used in the
documents. I've also noticed that MUWS part 2
> document does not have the
section describing notations used in that
> document. I believe the
section should be there as it must describe
> the notations used in that
document. It is not reasonable to assume
> that someone reading part 2
must always refer to part 1 to understand
> notational
conventions.
I agree with
you.
> In general I believe we may want
to consider the following fixes
> (errata?)
> - add notational
conventions to MUWS part 2
> - add definition of the topic path
notation to the notational
> conventions section of every document
>
- explain which topic expression dialect is used in the spec
document
>
itself
I think that these modifications or
clarifications are better for
readers of WSDM spec.
But I guess these are not critical issue, so we remind these issues
when
we write down new version of WSDM specs (or errata of this
version).
> -- Igor Sedukhin ..
(igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY
11749
Regards,
----
Mitsunori SATOMI
(mailto:Mitsunori.Satomi@hds.com)
Director,
Advanced Software Architect
Hitachi Data Systems Corporation
> -----Original Message-----
> From: Mitsunori
Satomi [mailto:Mitsunori.Satomi@hds.com]
> Sent: Friday, February 25, 2005
10:30 PM
> To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
>
Subject: RE: [wsdm] MOWS Request Processing Digest Notification Act
in
> Interop Scenario.
>
>
Igor,
>
> As I mentioned at con call, I agreed with your following
suggestion.
>
> And I found the simple (editorial) miss description
in interop
> scenario.
> In "MUWS Identity/Characteristics Act"
section,
>
> > 2. Using the same EPR, retrieve
>
muws-xs1:ManageabilityCharacteristics
> property
> >
an verify that [MUWS1] Identification capability URI is included
>
(possibly among others)
>
> I think "[MUWS1] Identify capability" is
correct.
>
>
> And I have a another question about the MOWS
specification document
> (cd-wsdm-mows-1.0.pdf).
>
> As the
event description of "5.2.6 Request Processing State",
>
> >
1008
>
mows-events:ManageableEndpoint/mows-events:RequestProcessingOb
>
servations
>
> I guess "mows-events:ManageableEndpoint/" is not
necessary in this
> line.
>
> ----
> Mitsunori SATOMI
(mailto:Mitsunori.Satomi@hds.com)
> Director, Advanced Software
Architect
> Hitachi Data Systems
Corporation
>
>
> > -----Original Message-----
> >
From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
> > Sent:
Thursday, February 24, 2005 9:00 AM
> > To: Mitsunori Satomi;
wsdm@lists.oasis-open.org
> > Subject: RE: [wsdm] MOWS Request
Processing Digest
> Notification Act in
>
> > Interop
Scenario.
> >
> > You're right, thanks Mitsunori. So there are
two ways to fiz this:
> >
> >
1) Make the subscription to
> >
mows-events:RequestProcessingObservations and keep the
> dialect
simple.
> > That way ANY notification regarding the request processing
will be
> > sent.
> > This is according to MOWS:
> >
[
> > mows-events:RequestProcessingObservations indicates availability
of
> > any information about the processing of any request by
the
> Web service
>
> > endpoint (Figure 12) as observed by
the implementation of a
> manageable
>
> > Web
service.
> > ]
> >
> > 2)
Make the dialect a concrete topic expression.
> >
> > Frankly
either way is fine, I believe. 1) may even be simpler.
> >
>
>
> > -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> > --
(631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749
> >
> >
-----Original Message-----
> > From: Mitsunori Satomi
[mailto:Mitsunori.Satomi@hds.com]
> > Sent: Wednesday, February 23,
2005 8:43 PM
> > To: wsdm@lists.oasis-open.org
> > Subject:
[wsdm] MOWS Request Processing Digest Notification Act in
> > Interop
Scenario.
> >
> > Hi, Igor and wsdm folks,
>
>
> > I and our engineer in Japan found a little problem in the
Interop
> > Scenario document (wsdm 1.0 interop scenarios.doc).
>
>
> > In "MOWS Request Processing Digest Notification Act"
section,
> >
> > 2. Using the same EPR subscribe
to the
> > mows-events:RequestProcessingObservations/Digest
>
> topic using [BN] Subscribe operation. Indicate
the topic and
> > [BN] Simple Topic Expression dialect.
> >
Include an EPR to the receiver of the notification
messages
> >
> > in this case, consumer have to subscribe the
child topic of
> > mows-events:RequestProcessingObservations.
>
> But using [BN] SimpleTopic Expression we can subscribe only
> the
root
> > topic as describing in the WS-Topic specification.
>
>
> > ---- wsn-WS-Topics-1.2-draft-01.doc ---
> > 343
7.1 SimpleTopic Expressions
> > ...
> > 357
Because the only valid TopicExpression in this dialect is a
> >
QName, only root topics can be
> > 358 addressed by this grammar.
For those entities that
> support only
> > this dialect of
TopicExpression,
> > 359 only simple topic spaces, those that
define only root topics,
> > SHOULD be used.
> > ---
wsn-WS-Topics-1.2-draft-01.doc ---
> >
> > I think both are
conflicted, so we have to modify the
> interop scenario
>
>
> document.
> >
> > Regards,
> > ----
> >
Mitsunori SATOMI (mailto:Mitsunori.Satomi@hds.com)
> > Director,
Advanced Software Architect
> > Hitachi Data Systems
Corporation
> >
> > To unsubscribe from this mailing list (and
be removed from
> the roster
> > of the OASIS TC), go to
>
> http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leav
> >
e_workgrou
> > p.php.
> >
>
>
>
---------------------------------------------------------------------
To
unsubscribe, e-mail: wsdm-unsubscribe@lists.oasis-open.org
For additional
commands, e-mail: wsdm-help@lists.oasis-open.org
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]