[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]