RE: [wsdm] Long-lived interactions requirement proposal

["VAMBENEPE,WILLIAM (HP-Cupertino,ex1)" <vbp@hp.com>]

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.