[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Wikipedia definitions FYI
Martin, Matt: The BPM, Choreography is a different "state" conversation that this one. I think this is about the state for the execution of a single service (like the statement that HTTP itself is stateless), not state for execution of multiple services. The latter is definitely out of scope IMO. The state aspect in question is "Does a service require anything to be known about past interactions between the service consumer and itself" before taking an action (such as a service response). My assertion is that in some cases the answer may be yes, even if it is as simple as a set of tokens to identify the service consumer. I find flaw in making a statement as Wikipedia references that implies all services are stateless. Regardless, this may or may not be relevant to the RM. At the very least I hope it is interesting :-p Duane Matthew MacKenzie wrote: > When we begin talking about transactions and state, we obviously are > getting into the choreography/BPM discussion, which in my humble > opinion *is out of scope* for the RM. > > Respectfully, > Matt > > On 13-Jun-05, at 3:25 PM, Smith, Martin wrote: > >> Hey, I'll settle for one lousy state-maintenance shared service (aka >> BPM.) >> >> Martin >> >> >> -----Original Message----- >> From: Duane Nickull [mailto:dnickull@adobe.com] >> Sent: Monday, June 13, 2005 3:22 PM >> To: Smith, Martin >> Cc: Breininger, Kathryn R; SOA RM >> Subject: Re: [soa-rm] Wikipedia definitions FYI >> >> Martin: >> >> For the record, I disagree with the Wikipedia definition as it is. IMO >> - state maintenance may have to be done behind the service interface, >> but some information may be maintained in custom data stores or >> persistent message stores at the binding level. Certain services may >> have a processing model of 1 Request -> * Responses. A fictional >> example is a service where a user registers to receive stock trades as >> they happen. There are a few things that must be maintained behind the >> service: >> >> 1. details of how the service consumer can receive the response >> 2. tokens to identify the service consumer should they wish to >> modify or >> >> cancel their request >> 3. The last stock trade they received notice of (probably stored in the >> form of archived responses in the transport layer). >> >> I am sure that DHS may have similar designs on a service where they >> could subscribe to events related to use of a certain set of >> identification credentials for people on the "watch list" (I wonder if >> participation in this TC is criteria for being on the watch list ;-) >> >> I would therefore assert that the Wikipedia definition of services as >> "stateless" is illogical and incorrect. >> >> Duane >> >> Smith, Martin wrote: >> >> >>> So, where exactly is state maintained in an SOA??? Going to be >>> tough to >>> execute transactions without state. >>> >>> Martin >>> >>> >>> -----Original Message----- >>> From: Duane Nickull [mailto:dnickull@adobe.com] >>> Sent: Monday, June 13, 2005 3:02 PM >>> To: Breininger, Kathryn R >>> Cc: SOA RM >>> Subject: Re: [soa-rm] Wikipedia definitions FYI >>> >>> The comment about services being stateless is interesting. If we agree >>> with that assertion, it may affect the notion of a service processing >>> model (request to many responses). Also - that seems to be more tied >>> >> to >> >>> >>> the nature of the transport/binding mechanism itself. >>> >>> Duane >>> >>> Breininger, Kathryn R wrote: >>> >>> >>> >>> >>>> Just an FYI. I see Wikipedia is beginning to work on definitions for >>>> SOA as well: >>>> >>>> http://en.wikipedia.org/wiki/Service-oriented_architecture >>>> >>>> Kathryn Breininger >>>> CENTRAL Project Manager >>>> Emerging Technologies >>>> Boeing Library Services >>>> >>>> 425-965-0182 phone >>>> 425-237-3491 fax >>>> kathryn.r.breininger@boeing.com >>>> >>>> >>>> >>>> >>>> >>>> >>>>> How was your service? Please click link below....... >>>>> http://socal.web.boeing.com/ssglibsurvey/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]