- From: <Daniel_Austin@grainger.com>
- Date: Wed, 2 Apr 2003 10:21:26 -0600
- To: GRitzinger@novell.com
- Cc: public-ws-chor@w3.org, public-ws-chor-request@w3.org
Hi,
I think that, as an Architect, I would design the 'observer' as a web
service itself; that way, it is a first class object in the system with a
well-defined role. Then the observer can be an actor in any specific use
case.
We should make sure that at least one of our UCs includes this
observer role. But I don't think that this needs to be standardized by any
particular working group.
Regards,
D-
*************************************************
Dr. Daniel Austin
Sr. Technical Architect / Architecture Team Lead
daniel_austin@notes.grainger.com <----- Note change!
847 793 5044
Visit http://www.grainger.com
"If I get a little money, I buy books. If there is anything left over, I
buy clothing and food."
-Erasmus
"Greg Ritzinger"
<GRitzinger@novell To: public-ws-chor@w3.org
.com> cc:
Sent by: Subject: Use cases - Observer role
public-ws-chor-req
uest@w3.org
04/02/2003 09:48
AM
I don't recall if any of the submitted use cases include the notion of
an observer, but in some choreography scenarios an observer would be
desirable. For example, during the development or testing phases of the
choreography or to monitor a choreography that is deployed or active.
The observer could be used to report on the choreography state,
failures, usage, etc. I'm not saying that we should complicate the use
cases, they should remain focused on their problem domain, but that we
need to consider this role in general.
Should ws-chor support roles such as observer directly or should it be
deferred to another working group?
Thanks,
Greg
--------------------------------------------------------------
Greg Ritzinger
Senior Software Engineer
Phone 203.225.1822
Novell, Inc., the leading provider of Net Business Solutions.
www.novell.com <http://www.novell.com>
Received on Wednesday, 2 April 2003 11:21:27 UTC