Re: [wsdm] Long-lived interactions requirement proposal

[Shel Finkelstein <shel.finkelstein@sun.com>]

Well, I keep seeing a session-based model entering the requirements; this is
just one example.

I had thought that the OGSI discussion would be taking place tomorrow; folks
are aware that the session-based model is one of the major negatives some
have raised about OGSI, arguments which I think are very poweful and need
review.
  a) Scalability (state management differences have big implications)
  b) Programming model (session vs no-session)
  c) Combinatorics of BPEL+OGSI model interactions for MoWS

Although the requirements don't say OGSI, they are accepting its model.  I
think that this is happening by default, since OGSI discussion (which was
originally scheduled for several weeks ago) still hasn't occurred.

So this is an Issue, one with non-trivial impact on requirements.  I wish
that all the OGSI material were available now, but I don't see the absence
of that material as a reason that its model should enter the requirements as
is.

As for the examples (e.g., terminate interactions with customer with bad
line of credit):  The example demonstrates why sessions are not the way to
go.  You're marking the customer as a deadbeat, and taking appropriate
immediate actions based on state for the cusotomer described in your
business database, which affect all future requests involving the customer
(implict and explicit).  When you model your business state using a DB,
scaling and semantics are a lot easier than when you separate out individual
business sessions.  But we know that from web servers, and there are a lot
of lessons about that from enterprise beans as well.

Shel

Shel

"VAMBENEPE,WILLIAM (HP-Cupertino,ex1)" wrote:
> 
> 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/leave_workgroup.php.