Title: RE: [ebsoa] SOA Collaboration Semantics
Thanks John. How would you
support your position? Please elaborate.
Joe
From: John Hardin
[mailto:]
Sent: Sun 10/30/2005 12:38 PM
To:
Goran Zugic; Chiusano Joseph; ebSOA OASIS TC
Subject: RE: [ebsoa] SOA
Collaboration Semantics
This is an interesting thread, and of course we welcome
dissenting opinions when it is constructive. After several reviews of the
material, and considering the current status of any coherent organizing model
for an overall SOA, I am fully confident that the FERA model makes an excellent
organizing set of principles for Service Oriented
Architecture.
-----Original Message-----
From: Goran Zugic
[mailto:]
Sent:
Sat 10/29/2005 8:09 PM
To: Chiusano Joseph; ebSOA OASIS TC
Subject: Re:
[ebsoa] SOA Collaboration Semantics
Joe,
This is how I
view professionalism in this kind of communication:
1. Do not
criticize the content until you have not fully read it.
2. When
you criticize something always state your standpoint. Do not come up with a
negative critique before you explain your position and have fully understood the
other side's position. In order to achieve this, step one is a prerequisite. As
you know, our solution is explained in three publicly available documents. You
said you will clarify your viewpoints, I am looking forward to seeing them
whenever they are ready.
3. Whenever you ask for an answer,
or try to find an answer with the help of others, be patient with the
discussions until all positions are clear. Do not rush with critiques such
as: "... I am still highly skeptical of their usefulness and value..." or
"... I frankly don't see its value to this TC or standards work in general..."
or "...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 ...".
Arbitrary critiques are not hard to produce, in comparison to years of hard work
and years of professional experience; both of which were needed to produce
the specification framework that the ebSOA TC is working on right
now.
When I joined the ebSOA TC back in March of this year, the
only ebSOA TC architectural specification document (dated August 2004) that was
present, was a high level abstract draft that you also contributed to. You left
this in its beginning stage, and I have not seen any further contributions
since. Coneveniently you reappeared as soon as the FERA-based SOA submission was
completed, and your intentions were questionable at best. What I want to know,
is wether you would like to help the process, or hindered it like you have been
doing thus far.
The way I see this, is that I
will not waste my time with the chicken and egg scenario with endless
discussions about SOA, services, service orchestration, choreography, and many
others. However, we can further our discussions, as long as constructive
exchanges based on our clearly stated positions, and most importantly, the
respect for each others work are present. Counter-productive arguements without
merit, which you have displayed, serve as a barrier to our
communication.
Assuming that we will have more positive and
more constructive communication in the near future, I look forward to hearing
from you about your position, views and outlooks, on SOA and all aspects
surrounding it.
Goran
-----
Original Message -----
From: Chiusano Joseph
To:
; ebSOA OASIS TC
Sent: Wednesday, October
26, 2005 5:02 PM
Subject: RE: [ebsoa] SOA Collaboration
Semantics
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
