OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsdm] Long-lived interactions requirement proposal


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:vbp@hp.com]
Sent: Tue 9/30/2003 12:41 AM
To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
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:vbp@hp.com]
> Sent: Monday, September 29, 2003 9:39 PM
> To: 'Sedukhin, Igor S'; wsdm@lists.oasis-open.org
> 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:Igor.Sedukhin@ca.com]
> > Sent: Friday, September 26, 2003 7:07 AM
> > To: VAMBENEPE,WILLIAM (HP-Cupertino,ex1); wsdm@lists.oasis-open.org
> > 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 .. (igor.sedukhin@ca.com)
> > -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
> >
> >
> > -----Original Message-----
> > From: VAMBENEPE,WILLIAM (HP-Cupertino,ex1) [mailto:vbp@hp.com]
> > Sent: Friday, September 26, 2003 1:39 AM
> > To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
> > 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:Igor.Sedukhin@ca.com]
> > > Sent: Thursday, September 25, 2003 10:22 AM
> > > To: VAMBENEPE,WILLIAM (HP-Cupertino,ex1);
> wsdm@lists.oasis-open.org
> > > 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 .. (igor.sedukhin@ca.com)
> > > -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
> > >
> > >
> > > -----Original Message-----
> > > From: VAMBENEPE,WILLIAM (HP-Cupertino,ex1) [mailto:vbp@hp.com]
> > > Sent: Sunday, September 07, 2003 4:43 PM
> > > To: 'wsdm@lists.oasis-open.org'
> > > 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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]