Please see comments below, marked with
[JMC].
Kind Regards,
Joseph Chiusano
Associate
Booz Allen Hamilton
700 13th St. NW
Washington, DC 20005
O: 202-508-6514
C: 202-251-0731
Visit us online@ http://www.boozallen.com
From: Goran Zugic
[mailto:]
Sent: Tuesday, October 25, 2005
10:58 PM
To: Chiusano Joseph; ebSOA OASIS TC
Subject: Re:
[ebsoa] SOA Collaboration Semantics
Joe,
Thanks for your feedback. These are my
answers:
- The run-time architecture is based on analysis of over
130 collaborative installations. It is based on FERA which classifies and
categorizes capabilities required to support all of the use cases analyzed.
The components are actually reference functional modules that have
specified functions and interfaces. Our run time SOA is based on that
model and each component has a well defined role and interface to communicate
with other components to support the collaborative
process.
[JMC] Thank you. The information you provided
above is valuable to understand the background and history of
the run-time architecture. I should also emphasize that my original
question was: "Since the run-time architecture is greatly
concrete, is it intended that products be based on it? Is it intended for
exemplary purposes? Other? ".
-
SOA IM is based on the process definition in FERA that requires certain level
of specificity of the process detail. True, FERA does not require QoS details,
but it provides a robust security policy model.
[JMC] It seems to me that if the
security policy model is robust as you say, it would be reflected in the SOA
IM hierarchy shown in Figure 1 of the SOA IM document. Why would it not be
(sorry, I don't understand).
The IM is derived from FERA
process characteristics and there are additional data elements required
for the run time semantics that are used for quality, escalation, monitoring
and other administrative aspects of run time execution. The SOA IM contains
sufficient level of detail to extract the semantics and to execute it over the
run time SOA. True it is a process based model, and that is intentional,
because that maintains the fidelity of business requirements throughout
the entire deployment. In this framework, it is less important to define what
is a service then to satisfy all basic principles of SOA.
[JMC] How can one "satisfy all
basic principles of SOA" if the most fundamental concept of SOA - "service" -
is not
defined?
That is why it is an SOA IM.
[JMC] Given that "Service" does
not appear in the IM hierarchy, I would asser that it is *not* a SOA IM, and
that portraying it as such is - a best - a huge
stretch.
However, the Service entity is defined in Section 2.1.35 in SOA IM
document.
[JMC] Great - why not put it in
the IM hierarchy?
Hence, you see activities, decisions, events, roles, rules and metrics
as key entities. A service can therefore be any activity, or a decision that
has defined inputs and outputs, conditions for its invocation, metrics for its
performance, rules for its execution, matrix with the input processing
logic and few other entities in the model.
[JMC] Great - then that should be
reflected in the IM hierarchy, with "Service" being related to all of these,
IMHO.
Hence the entire model in fact defines services, their
orchestration,
[JMC] Not all SOA instances
involve orchestration - that is a feature (aspect) that is determined
according to business need. So building in orchestration "natively", IMHO,
makes this an orchestration IM (or a process IM), not a SOA
IM.
their business rules and other aspects required for
SOA definition, deployment, maintenance and continuous operational support.
The entire IM and the architecture is an SOA based on the principles of
service orientation.
[JMC] I believe that it cannot be
this, since "Service" is not even included in the IM hierarchy, much less as a
central focus.
Just like in the sport of soccer nothing is really
called soccer, but everything else defines the game, players, referees, goals,
spectators, ball, pitch, etc.
[JMC] Yes, but there are
fundamental components you mentioned, such as a soccer ball. How can this be
SOA (soccer) without depicting a soccer ball
(Service)?
I am not implying anything more
than I am saying here, but it appears to me that the SOA IM was originally
written as a process IM, and some text regarding "service" was added in as an
afterthought (just my opinion).
Given its current state, I
frankly don't see its value to this TC or standards work in
general.
Thanks,
Joe
Regards,
Goran
----- Original Message -----
From:
Chiusano Joseph
To: Goran Zugic ; ebSOA OASIS TC
Sent: Tuesday, October 25, 2005 4:10
PM
Subject: RE: [ebsoa] SOA Collaboration
Semantics
Goran,
Thanks for sending these documents - it's clear
that a great deal of work has gone into them.
I have a few questions, please:
Run-Time SOA: I get the notion of a reference
architecture as shown in Figure 1 on p.3. Having said that, I would expect
that any run-time (concrete) architecture that is depicted as being based on
the reference architecture is merely for exemplary purposes, yet the
run-time architecture is simply presented without any indication of its
purpose. Since the run-time architecture is greatly concrete, is it intended
that products be based on it? Is it intended for exemplary purposes?
Other?
SOA Information Model: Though this is called a
"SOA" information model, this document looks
more to me like a "Process Information Model" that is actually independent
of SOA (that is, I did not see anything that restricted it to SOA). In fact, in order to call something a "SOA"
information model, I would assert that there are several other areas that
would need to be incorporated beyond processes - e.g. security, policy, QoS,
etc. Even considering the process perspective, there is nothing that I see
in this information model that speaks distinctly to a service-oriented
paradigm - in fact, figure 1 (p.24) does not even have a "Service" concept.
What is the intended use of this document for
ebSOA?
Thanks,
Joe
Joseph Chiusano
Associate
Booz Allen Hamilton
700 13th St. NW
Washington, DC 20005
O: 202-508-6514
C: 202-251-0731
Visit us online@ http://www.boozallen.com
From: Goran Zugic
[mailto:]
Sent: Friday, October 21,
2005 2:21 AM
To: 'ebSOA OASIS TC'
Subject: [ebsoa] SOA
Collaboration Semantics
Hello ebSOA TC,
Semantion is pleased to announce the completion of its FERA-based
SOA contribution to ebSOA TC.
The SOA Collaboration Semantics document
http://www.semantion.com/specs/soa/SOA_CS_V0.1.doc
contains FERA-based SOA semantics specification that together with
two previously submitted documents, Run-time SOA and SOA
Information Model, represent Semantion's SOA specification
framework.
The
new releases of the Run-time SOA document and the SOA
Information Model document are available at
http://www.semantion.com/specs/soa/SOA_IM_V0.2.doc
http://www.semantion.com/specs/soa/Run-time_SOA_V0.2.doc
These documents should be reviewed in the following
order:
- Run-time SOA
- SOA Information Model
- SOA Collaboration Semantics
Please let me know if you have any questions or need more
information regarding the submitted documents.
Regards,
Goran
Zugic
Chief
Architect
Semantion
Inc.
http://www.semantion.com
416-995-7532
