<Quote>
I never contributed to such a draft, and I wish you would please make sure
your facts are straight before making such assertions.
</Quote>
This is the draft you contributed to:
http://www.oasis-open.org/apps/org/workgroup/ebsoa/download.php/9895/wd-ebsoa-047.pdf
Goran
----- Original Message -----
From:
Chiusano Joseph
To: Chiusano Joseph ; Goran
Zugic ; ebSOA OASIS TC
Sent: Sunday, October 30, 2005 3:23
PM
Subject: RE: [ebsoa] SOA Collaboration
Semantics
<Quote>
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.
</Quote>
I
have been very patient with the discussions. I asked a question about how you
viewed the work being used in the future, and you did not respond to that
question. So my assessment at that point was that I was skeptical of the
usefulness and value of the work, because you were unable to articulate how it
would be used in the future. My response was based on your
response.
<Quote>
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.
</Quote>
I never contributed to such a draft, and I wish you would
please make sure your facts are straight before making such assertions.
Furthermore, I (and any OASIS member) have the right to contribute to and
leave any OASIS TC (and then re-join) according to OASIS processes, without
any other OASIS member really having anything justified to say about it.
From this point on I will not respond to any of your comments,
and urge you to see someone within OASIS if you have issues with OASIS members
contributing to the open OASIS process.
Joe
From: Chiusano Joseph
[mailto:]
Sent: Sun 10/30/2005 3:17
PM
To: Goran Zugic; ebSOA OASIS TC
Subject: RE: [ebsoa]
SOA Collaboration Semantics
Goran,
Please keep in mind that you are working
in an open process where people (like myself) provide feedback on submitted
content, even if they have not read the entire document. Anyone in this
process has the right to comment on any part of materials submitted before
reading them in their entirety. I simply looked at a figure that was labeled
to be a "high-level information model" for SOA, and noted the absence of what
I believe (especially based on the work that is being done in the SOA-RM TC)
is a fundamental piece. I am not required by OASIS policy to continue reading
the entire document at that point before I provide feedback on my observation
to a TC.
I suggest that if you cannot donate
something to OASIS and then abide by OASIS rules in evolving your donation,
that you rescind it - and immediately.
Joe
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
