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


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/leave_workgroup.php.




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