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



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]