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:]
>>>> 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:]
>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> How was your service? Please click link below.......
>>>>>>> http://socal.web.boeing.com/ssglibsurvey/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>
>
