Minutes of SWSA Telecon of February 24, 2004

Juan Miguel, Massimo Paolucci, Andi Eberhart, Mark Burstein, Stuart
Williams, Mike Dean, Amit Sheth

(NB: This summary was reconstructed from points made during the discussion
and a review of the documents discussed. - Mark)

We discussed two documents, the WSA Committee final document
 http://www.w3.org/TR/ws-arch/

and an article by Philippe Krutchen of Rational Software entitled
'Architectural Blueprints - the"4+1" View Model of Software Architecture'
IEEE Software 12(6) November 1995 pp. 42-52.  
 http://www.infosys.tuwien.ac.at/Teaching/Courses/SWA/Kruchten4+1.pdf

MB leading and others commenting: 

The question with regards the WSA final document is how we can use it
as a foundation for our efforts. They take a limited view of semantics in
their discussion, although they refer to it in several key places. For
example, in the Service Oriented Model (figure 2-8), one of their key
architectural views or models, they talk about the a SERVICE DESCRIPTION
having a SEMANTICS , which is about the SERVICE TASK.  However, this model
contains a number of concepts that represent aspects of services, and there
should be semantic descriptions associated with most or all of those
things. For example, the person or organization providing the service, the
goal of the service, and the agents providing and requesting the service
also need to be described.  For this reason, we should probably adjust this
model so that semantics is not directly part of the model, and about just
the service task, but should be used to describe all aspects of the service
model.  


Their definition of semantics in this regard was (section 2.3.2.15):

"The semantics of a service is the behavior expected when interacting with
the service. The semantics expresses a contract (not necessarily a legal
contract) between the provider entity and the requester entity. It
expresses the intended real-world effect of invoking the service. A service
semantics may be formally described in a machine readable form, identified
but not formally defined, or informally defined via an "out of band"
agreement between the provider entity and the requester entity."

With regard to the stakeholder's perspective, they talk about web service semantics with respect to several types of agreement between the client and server:

" The two (or more) programs must share agreement (in the sense discussed
in 3.3 Using Web Services) as to the intended meaning of the data. For
example, whether the data is intended to represent an HTML page to be
rendered, or whether the data represents the current status of a bank
account; the expectations and the processing involved in processing the
data is different - even if the form of the data is identical.

There must be agreement (in the sense discussed in 3.3 Using Web Services)
as to the implied processing of messages exchanged between the
programs. For example, purchase ordering Web service is expected - by the
agent that places the order - to process the document containing the
purchase order as a purchase order, as opposed to simply recording it for
auditing purposes.  "

Section 3.5.3 discusses the role of metadata, and potentially even of OWL
in describing the real world entities that are referenced by a
service. This is a definite step in the right direction.

We have to decide in what sense we will try to build on this
model. Certainly we can take advantage of some of the standardization of
vocabulary that they provide for web services.  The main problem with what
they have done is that the whole document describes services quite
abstractly, and does not give us support in terms of protocols or
operational abstractions (guarantees) on which to build architectural
mechanisms supporting the interchange of semantically transparent messages
or information.


---------
Summary of brief discussion of the 4+1 model for software architectures:

Krutchen describes an approach to software architectures in terms of four
different model perspectives or views, tied together by use cases or
scenarios. He first describes software architecture as dealing with the high level structure of the software, quoting Perry and Wolfe, as modified by Boehm to define it as

Software Architecture = {elements, forms, rationale/constraints}


He then goes on to discuss the four views, which are:

The LOGICAL view, which is the object model of the design (when an
object-oriented design method is used),

The PROCESS view, which captures the concurrency and synchronization
aspects of the design,

The PHYSICAL view, which describes the mapping(s) of the software onto the
hardware and reflects its distributed aspect,

The DEVELOPMENT view, which describes the static organization of the
software in its development environment.

The key point of this article, from our perspective, is that the
architectural description that we produce may be comprised of several
different largely disconnected views or models, much the same way that the
WSA Archtiecture consists of the Message, Service, Resource and Policy
oriented models, and a set of Stakeholder perspectives.

For SWSA, we probably will not be concerned with the physical and
development views, as we are dealing with an abstract
architecture that may be realized in a number of different ways for
different environments. The Grid and Ubiquitous computing models may be
entirely different at those levels. On the other hand, the logical and
process views will have their counterparts for us.

On the other hand, it is fairly easy to see that the different models
discussed in the WSA document are relevant.  We will need to deal with the
message oriented model when discussing choreography and process
mediation. We will need to deal with the service oriented model when
discussing service discovery, selection and task composition. We will need
to deal with the resource oriented model when discussing discovery and
resource management policies. We will need to deal with the policy model
when addressing security and authorization policies for service
utilization.