RE: [wsdm] Long-lived interactions requirement proposal

Title: Message

+1 

  

  
-----Original Message-----
From: Sedukhin, Igor S 
  [mailto:] 
Sent: Tuesday, September 30, 2003 
  10:25 AM
To: Vambenepe, William N; 
  
Subject: 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:] 
Sent: 
    Tue 9/30/2003 12:41 AM 
To: Sedukhin, Igor S; 
     
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:]
> Sent: Monday, 
    September 29, 2003 9:39 PM
> To: 'Sedukhin, Igor S'; 
    
> 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:]
> 
    > Sent: Friday, September 26, 2003 7:07 AM
> > To: 
    VAMBENEPE,WILLIAM (HP-Cupertino,ex1); 
> > 
    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 .. ()
> > -- (631) 
    342-4325 .. 1 CA Plaza, Islandia, NY 11788
> >
> >
> 
    > -----Original Message-----
> > From: VAMBENEPE,WILLIAM 
    (HP-Cupertino,ex1) [mailto:]
> > Sent: Friday, 
    September 26, 2003 1:39 AM
> > To: Sedukhin, Igor S; 
    
> > 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:]
> 
    > > Sent: Thursday, September 25, 2003 10:22 AM
> > > To: 
    VAMBENEPE,WILLIAM (HP-Cupertino,ex1);
> 
    
> > > 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 .. 
    ()
> > > -- (631) 342-4325 .. 1 CA Plaza, 
    Islandia, NY 11788
> > >
> > >
> > > 
    -----Original Message-----
> > > From: VAMBENEPE,WILLIAM 
    (HP-Cupertino,ex1) [mailto:]
> > > Sent: 
    Sunday, September 07, 2003 4:43 PM
> > > To: 
    ''
> > > 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.