Goran,
I
don't believe it is very professional for you to assume what I am interested in
regarding SOA. In fact, your assumption was quite
innaccurate.
I
will clarify that I am interested in the terminology, the purpose, the business
process improvements it can provide, and many other aspects.
I thank you in
advance for updating your high-level information model to accurately reflect
your stated intent for these specifications. I am still highly skeptical of
their usefulness and value, but time and market will tell.
Joe
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:
[mailto:]
Sent: Wednesday, October 26,
2005 4:58 PM
To: Chiusano Joseph; Goran Zugic; ebSOA OASIS
TC
Subject: Re: [ebsoa] SOA Collaboration
Semantics
Joe,
Thank you for being so frank in
sharing your opinion. Looks like you are interested in terminology of the SOA,
not in the purpose of it, or in the business process improvements that it can
provide. The proposed framework deals with ontology, information models, run
time architecture and semantics for SOA and its implementations, the missing
glue areas in current standard specifications. When you read the proposed
documents in more details, you will get answers to all your questions.
Fore example, Service entity is explicitly defined in SOA IM.
Unfortunately your conclusions have been made mostly based on the only figure
in the SOA IM document, "Figure 1 - SOA Information Model (High Level)", yes
it says "High Level", which does not graphically include Service entity. If
you really read the document you would easily find out that the Service entity
is defined in SOA IM and that it is one of the the core SOA IM entities used
to support key business process entities: activities, decisions and events.
However, in our next release, we will graphically add, for example, the
Service entity to the SOA IM high-level figure to help you and similar readers
whose focus is on the pictures not the content to better understand our specs
and solution.
Few more words about reference and run-time
architecture. As I mentioned in my previous note FERA reference architecture
has been created based on many collaborative (business) process use cases and
installations. The run-time SOA is based on it and SOA Collaboration Semantics
defines all its architectural components' protocols, interfaces and methods.
That is how you provide vendors with specs that can be used to develop
plugable architectural components in a fully interoperable way. How you are
going to implement it, what technology will be used and everything else that
comes with it is completely independent of this specs.
Analogy
with sports. The formalism applied to the abstract definition of the
ball (service) out of the game (context) does not make too much
sense. We can debate if the ball should be defined as "soccer ball" or
"football" forever, and no-one would win that debate. It does not matter if we
follow the ontology of the game. Players will say "pass me the ball", or
"share that orange, you hog", and everyone else will understand that request
given the game being played at the moment.
Smart people defined the
purpose of services and SOA long time ago but nobody has provided the way how
the entire SOA should work. We are the first group that has created the
framework for this kind of the SOA specs. More and more people and
organizations and even some new OASIS TCs starting to realize the importance
of the SOA IM and SOA semantics which are first introduced by us as the key
elements for the complete support for business process modeling,
deployment and execution in SOA.
Goran
-----Original Message-----
From: Chiusano
Joseph [mailto:]
Sent: Wednesday, October
26, 2005 11:04 AM
To: 'Goran Zugic', 'ebSOA OASIS
TC'
Subject: RE: [ebsoa] SOA Collaboration
Semantics
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
