Title: RE: [wsdm] Long-lived interactions requirement proposal
William,
I have no problem with your second requirement, the first one I propose to
rephrase as follows
- The manageability representation MUST allow access to
session information including messages within the context of the
session
-----Original Message-----
From:
VAMBENEPE,WILLIAM (HP-Cupertino,ex1) [mailto:]
Sent: Tue
9/30/2003 12:41 AM
To: Sedukhin, Igor S;
Cc:
Subject: RE: [wsdm] Long-lived interactions
requirement proposal
Oops, I did a copy/paste and forgot to remove the "control"
part. Here is
the correct version of the new text:
In the glossary:
Remove all references to conversations and define a session
as "a set of
related messages (sent or received by the service) and
their
context".
In the requirements list (section 2), add:
-
The manageability representation MUST allow monitoring (including state
and
access to messages) of the current sessions of a service.
- The
manageability representation MUST allow metrics to be defined at
the
session level.
William
> -----Original
Message-----
> From: VAMBENEPE,WILLIAM (HP-Cupertino,ex1) [mailto:]
> Sent: Monday,
September 29, 2003 9:39 PM
> To: 'Sedukhin, Igor S';
> Subject: RE: [wsdm] Long-lived interactions
requirement proposal
>
>
>
> Hi Igor,
>
>
While in many cases people will choose not to allow external
> control
of
> sessions, I can think of many cases where this would be
>
useful, so it would
> be nice to have this capability in an option. But
you've been
> very open in
> listening to my arguments and I
should do my part to
> reconcile our positions
> so I am ok
dropping the "control" part of the requirement.
> So, the
changes
> to the requirements doc become:
>
> In the
glossary: Remove all references to conversations and
> define a
session
> as "a set of related messages (sent or received by the
>
service) and their
> context".
>
> In the requirements list
(section 2), add:
>
> - The manageability representation MUST
allow monitoring
> (including state
> and access to messages) and
control of the current sessions
> of a service.
> - The
manageability representation MUST allow metrics to be
> defined at
the
> session level.
>
> Thanks for the good
discussion,
>
> William
>
>
> > -----Original
Message-----
> > From: Sedukhin, Igor S [mailto:]
>
> Sent: Friday, September 26, 2003 7:07 AM
> > To:
VAMBENEPE,WILLIAM (HP-Cupertino,ex1);
> >
Subject: RE: [wsdm] Long-lived interactions requirement proposal
>
>
> >
> > This is useful, but for a fine-grained WebApp
management. The
> > AppServer management knows about those sessions
of a SERVLET,
> > for example and can terminate them as you
described. I do not
> > see the need to terminate WebApp session
(over the Internet)
> > of a MapPoint service that my application is
using. I
> > actually don't think anyone would ever allow something
like
> > that in a federated management scenario. This is too
>
> low-level and requires ownership of the resource.
> >
>
> Now, if I own the WS I don't need to ask it to do that. I can
>
> operate the servlet or the app server session&context. So why
>
> would manageability representation of a web service need to
> >
expose control of a WebApp session?
> >
> > -- Igor Sedukhin
.. ()
> > -- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11788
> >
> >
> > -----Original
Message-----
> > From: VAMBENEPE,WILLIAM (HP-Cupertino,ex1) [mailto:]
> > Sent: Friday,
September 26, 2003 1:39 AM
> > To: Sedukhin, Igor S;
> > Subject: RE: [wsdm] Long-lived
interactions requirement proposal
> >
> >
>
>
> > Hi Igor,
> >
> > Thanks for the comments.
Let me add a bit more about the
> > value of controlling sessions of
a service to better explain
> > what I have in mind.
>
>
> > What if you get an alert that your web service is
currently
> > engaged in a conversation with a customer who has
exceeded
> > its line of credit? Or who has just sent you an email
saying
> > his/her credentials have been compromised and somebody
else
> > is using them? Or if you realize that one session of
your
> > service has entered a crazy infinite loop with
another
> > service and is consuming as much resources as it can put
its
> > hands on? Would you pull the plug on the whole service,
even
> > if you have thousands of other customers accessing it?
Or
> > wouldn't you like to be able to terminate this specific
session?
> >
> > Now, what "terminate session" really means
and how it is
> > implemented depends on the managed resource. If you
have a
> > coordinator like ws-transaction, and ws-tmx provide then
you
> > can usually exit in a civilized way by notifying the
>
> coordinator and the managed resource should do so when told
> >
to terminate a session. If you don't have this kind of
> >
coordination infrastructure, there might be a way for you to
> >
contact directly your partners and inform them that you are
> >
pulling out. For example, they might have registered for
> >
notifications on your resource and you might notify them that
> >
this session is going down. If you don't have any such
> > mechanism
then you just end the session and reject any
> > message coming up
that relates to this session. In any case,
> > this is better than
pulling the plug on the server.
> >
> > Isn't this a useful
part of managing services involved in
> > long-lived
interactions?
> >
> > Regards,
> >
> >
William
> >
> >
> > > -----Original
Message-----
> > > From: Sedukhin, Igor S [mailto:]
>
> > Sent: Thursday, September 25, 2003 10:22 AM
> > > To:
VAMBENEPE,WILLIAM (HP-Cupertino,ex1);
>
> > > Subject: RE: [wsdm] Long-lived
interactions requirement proposal
> > >
> > >
>
> > I'm generally ok with these two requirements being in the
>
> > section 2, except the phrase "control of the current
sessions
> > > of a service". I think this is getting too crazy.
After a
> > > while we're going to want to control CPU cache
via
> > > "manageability representation" for a WS that is
not
> > > performing well :).
> > >
> > >
There is no value for federated management of WSs in
> > >
controlling at this level of granularity. We need to make
> > >
high-level processes manageable! That is the pain point I
> > heard
about.
> > >
> > > The fine granular control of the WS
is in the application
> > > management department. You can control
sessions of the
> > > servlet that implements the WS, for example.
I don't know why
> > > I would want to control sessions of the
MapPoint service that
> > > my application may be using.
>
> >
> > > I understand, though the value of providing
information on
> > > which session which message was processed in.
So, I'm ok with
> > > that part of your requirements. Ability to
define per session
> > > metrics is fine too.
> >
>
> > > -- Igor Sedukhin .. ()
> >
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
> >
>
> > >
> > > -----Original Message-----
>
> > From: VAMBENEPE,WILLIAM (HP-Cupertino,ex1) [mailto:]
> > > Sent:
Sunday, September 07, 2003 4:43 PM
> > > To:
''
> > > Subject: [wsdm] Long-lived
interactions requirement proposal
> > >
> > >
>
> >
> > > Hi all,
> > >
> > > As
agreed during the conf call on Thursday, here is a
> > > proposal
on how to add support for services involved in
> > > long-lived
interactions to our MOWS requirement doc.
> > >
> > >
Regards,
> > >
> > > William
> > >
>
> >
> > > Proposal:
> > > ---------
> >
>
> > > In the glossary: Remove all references to conversations
and
> > > define a session as "a set of related messages (sent
or
> > > received by the service) and their context".
> >
>
> > > In the requirements list (section 2), add:
> >
>
> > > - The manageability representation MUST allow
monitoring
> > > (including state and access to messages) and
control of the
> > > current sessions of a service.
> >
> - The manageability representation MUST allow metrics to be
> >
> defined at the session level.
> > >
> > >
>
> > 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_workgroup.php.
> >
> >
> > 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_workgroup.php.
>
>
> 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_workgroup.php.
