- Business services are mapped
directly to broader business needs, especially in cases in which a “top-down”
approach is used for the architecture and design of a service-oriented
system ;
- In terms of the "SOA stack" that we have seen
(slide that Duane has used in his SOA-RM summary presentation), business
services lie above the process tier ; since they are linked to
operations, they are about processes (i.e.
they always have processes "behind" them).
- In fact, we might call this top tier the
“business tier” ;
6. There was a question whether an SOA service had to be
network-accessible. What if all the services are on the same machine? What if
the data transfer was sneaker-net on a floppy? The essence of my response (and
later thought) was that everything on the same machine and specifically designed
just to be on the same machine is not SOA. Everything can be on the same machine
as an implementation but it should have been designed with the idea that it
could be distributed and the parts could be owned by different entities. As far
as sneaker-net, that is a data transfer capability that may be brought to bear
through a service interaction, but it is an implementation that is opaque to the
requester.
7. In formal definition of a service, it say “is accessed by means of a
service interface” and the question was whether there can be more than one
service interface to the same service. The answer is obviously yes (I used the
example in one of our email threads of a local and metro telephone number to the
same pizza parlor) but it may be worth clarifying.
[JMC] I wonder if that would really be different transport
bindings, rather than different interfaces. I see the need for multiple
interfaces to the same service as critical in the future (or even now). For
example, there may be one or more consumers of a service that - for whatever
reason - are required to provide the service additional information open
invocation vs. the other consumers. This means that there is a different
interface for those service consumers - i.e. a different data
model.
As we know, one cannot provide multiple data models for
the same service in a WSDL document, because WSDL does not know about specific
service consumers. I believe that this has to be done by offering a separate
interface (meaning WSDL Interface, what was once called PortType) for the
different service consumers. It would be great to have a standard that enables
the same WSDL Interface to accomodate all service consumers in this case - this
speaks to the notion of "service context" (which is somewhat like execution
context) that I referred to in some recent
postings.
8. Point that seemed to resonate but really wasn’t made in RM: entity
providing a service may not be the same as the one providing the underlying
capability.
[JMC] Excellent point. There are also potential legal
implications (though outside the scope of our spec) - for example, what if
someone were to provide a service for a Web site that uses screen-scraping
techniques (as done with mainframes) behind the scenes, and charged money for
access to that Web site?
9. re description:
- is the idea made enough that building description with links aids in
reusability and explicit reusability (vice just using the same string as used
elsewhere) aids interoperability? Or is this a point to include in the RA?
[JMC] I
would say RA.
- Is the idea made enough that “description” is the important concept and
service description is the one we talk about the most; however, description of
needs (the consumer end) is also (equally?) important?
[JMC] I
would say RA, since it's about the service
consumer.
10. No one had a problem with
the concept of “shared state” but many were confused by the term because they
thought of state as being something persistent that changed value.
- Shared state needs to be added to glossary.
- Is there a better term/name or do we need a few more lines of
description?
[JMC] Perhaps
we can also call it "public state"?
11. There is an inconsistency between lines 277-282 and lines 477-480 on
how shared state relates to a simple response to a data request. See
<emailDialog> below for some follow-up discussion
12. Description of reachability in section 3.3.1.1 says metadata on
protocols is part of reachability. Is this consistent with the discussion on
reachability in section 3.2.1.3, i.e. reachability as part of visibility?
<emailDialog>
[This expands on item 11.]
1 - I interpret RWE as
result/effect of a service to consumer and provider, especially response of
service to consumer. Why do we need to predicate "effect" with "real
world"? Why not use the term "effect"?
The RWE term resonated and I don't know there was documented rationale. It
follows from the idea that you use SOA to accomplish real things and this is not
just an academic exercise.
[JMC] I seem to recall RWE being used in some of the semantic
Web services specs, but I can't recall which one(s) (not OWL-S). Perhaps that's
where our inspiration came
from.
2 - Several problems with the term "shared
state":
a) Is the "shared state" the same as
RWE?
[JMC] I
think that the shared state is a side-effect of the real-world effect; it is a
shared awareness. For example, if the real-world effect of making an airline
reservation, the shared state (between the airline and the consumer) is their
shared awareness of the
situation.
End of my
comments.
Thanks,
Joe
I
think we will need to do some clean-up here. Note, lines 277-282
The consequence of invoking a service is a
realization of one or more real world effects (see Section 3.2.3). These effects
may include:
1. information returned in response to a request for that information,
2. a change to the shared state of defined entities, or
3. some combination of (1) and (2).
and then lines 477-480
Instead we focus on the set of facts shared by the
parties – the shared state. Actions by service providers and consumers
lead to modifications of this shared state; and the real world effect of a
service interaction is the accumulation of the changes in the shared
state.
I would lean toward lines 277-282 where change in shared state is separate
from what is equivalent to an HTTP GET.
b) Is "shared state" RWE
that are common to consumer and provider?
From lines 141-144
public actions result in changes to the
state that is shared at least between those involved in the current
execution context and possibly shared by others. Real world effects are, then,
couched in terms of changes to this shared state.
So the answer is yes for consumer and provider and possibly others who may
have reason to view the shared state, such as the example in lines 489-491
Flowing from the shared facts, the passenger, the
airline, and interested third parties may make inferences – for example, when
the passenger arrives at the airport the airline confirms the booking and
permits the passenger onto the airplane
c) Can there be NO "shared
state"?
In responding to question 2a, I would say yes because I could just be
returning information. I need to run this past the other editors to see how we
resolve the inconsistency in the text.
d) I would like to add that
when reading the example, I thought maybe that the intent was to actually imply
"state". E.g., using the airline booking example, the effect is a booking
but it goes through several states (request, confirm, deny,
cancel). Could that be what is implied here? Maybe I'm reading
too much into this???
I don't think that interpretation would be inconsistent but it wouldn't be
limited to that. For example, I could respond with a message that Seat 6A is
reserved for you but that does not require a state variable be maintained for
Seat 6A and that the reservation changes that state.
Maybe the answer to above is simple, but did not
come across that way in reading the SOA RM.
Part of the rationale for my presentation was to uncover areas where the
wording might be improved. I'm sure in some cases we will leave the wording as
is and rely on maybe an FAQ page. In others, we'll attempt to refine.
3 - My view of the "Execution Context" is that
it delves into the business process modeling domain. Was that the
intent?
I believe business process is part of execution context; the connection is
being explored more as part of the reference architecture. My latest thought is
that in the same way as I would characterize WSDL as being the implementation of
a necessary but small part of the description, I would consider BPEL as the
implementation of a necessary but small part of the execution context. Note,
"small" is relative depending on what else is needed for a given context.
BTW, I think the SOA RM is a great
start.
Glad to provide community service :-)
</emailDialog>
Ken
------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]