[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Wikipedia definitions FYI
FWIW, A nice try maybe. Stateless? Sorry, we are dealing with eventing in WSRP 2.0. We are also dealing with customization and coordination in aggregated services portlets. The feedback I'm getting is that if it drives vendors toward interoperability, its a good thing, but not thinking about services invoking other services is a bad thing for RM work. So my own insistence on a receiving endpoint for an inherently transitive process is not important enough to cause concern if vendors start getting a strong message about service interoperability. I'm not convinced, but I'm listening. Ciao, Rex At 1:16 PM -0700 6/13/05, Duane Nickull wrote: >Concur. Main point is that we should not adopt the Wikipedia >definition carte blanche. > >D > >Matthew MacKenzie wrote: > >>In my opinion, state-fulness is an implementation detail. I don't >>see what we gain by saying that a "service can be stateful" or >>perhaps "must be stateless". Looking at J2EE, for example we see >>that the core concept of the system is Enterprise Java Beans, of >>which there are various types. The two most common are Stateful >>and Stateless session beans. The adjective Stateful and Stateless >>don't hold much meaning to me from an abstract perspective. Only >>when I dive down into applying J2EE to specific architectures does >>SLSB vs. SFSB become interesting. >> >>-matt >> >>On 13-Jun-05, at 3:41 PM, Duane Nickull wrote: >> >>>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/ -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]