Hi Everyone,
My concern then was that IEEE standards require payment and I simply
can't afford the price for the privilege to go over that standard to
assure myself 1) that it is appropriate and applies to the same
level of abstraction as the SOA-RAF, 2) that it encumbers our
specification by requiring others to likewise pay the price in order
to fully conform with the RAF. If we simply take the items we need
out of that spec and cast it in the correct level of abstraction, I
would probably be fine with it, but I can't know that now.
My concern now is that we are about to land in another quagmire. I
have no problem with the principles included in the testing section,
and provided that we have the two or three diagrams that show the
testing process as it needs to be included in the process of using
the RAF to produce a domain-specific Reference Architecture, then
I'm fine. Any major recasting of the whole section is not
acceptable. I don't want to spend another year trying to get another
single section up to snuff or better. I think it is necessary, but
it might be better to pull it out and do a White Paper if its going
to take another round of endless discussions.
Cheers,
Rex
On 11/29/10 6:56 PM, Ken Laskey wrote:
1eb601cb903a$42297ff0$c67c7fd0$@org"
type="cite">
Recall when we discussed the testing section, we
made several modifications and additions but noted it was
short on definitions and void of graphics. There was a
group action (unrecorded) for folks to consider the text and
propose appropriate models. We never followed through on
that.
I know Rex had problems with some of the
specificity relating to IEEE-829. My intent was to have a
firm grounding from which I could emphasize the new
challenges introduced by SOA, but the text could be read as
requiring more than I had intended. I’d like Rex to point
out where his heartburn originates so we make sure that any
modifications consider, if not fully address, his concerns.
Ken
---------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H305 phone:
703-983-7934
7515 Colshire
Drive fax:
703-983-1379
McLean VA 22102-7508
We provide UML models in all of
the RAF model sections. Are you volunteering to
create UML models for the testing section? Doing
that and relating it to other models in the document
should provide some architecture underpinnings.
From: mpoulin@usa.com <mpoulin@usa.com>
Subject: Fwd: [soa-rm-ra] Issues against Sections
4.2, 4.4, & 5.2
To: soa-rm-ra@lists.oasis-open.org
Date: Monday, November 29, 2010, 12:14 PM
FYI
-----Original Message-----
From: mpoulin@usa.com
To: danny_thornton2@yahoo.com
Sent: Mon, Nov 29, 2010 8:13 pm
Subject: Re: [soa-rm-ra] Issues against
Sections 4.2, 4.4, & 5.2
The text in the section SOA Testing Model may be more focused on
the SOA specifics, I agree but in essence:
1) in modern practice,
Architects usually provide or sign-off
the test-cases that can proof that
developed product is in line with the
defined architecture. That is,
testing, if specified properly, can
confirm that the architecture stands
on the solid ground of developed
products. SOA testing does this job
for Service Oriented solutions
2) SOA requires new or
very extended foundations in the
implementation and, thus, in testing.
If SOA testing is done in the manner
of testing for monolithic applications
or distributed objects, this
compromises the foundation of SO
Architecture and makes it a BUZZ
Theory
3) nowadays,
standardized SOA must be accompanied
by standardized testing. Later on,
when the concept of service
orientation and business services
becomes a commodity, i.e. nobody
should be told that services must be
tested in the environment that
contains consumers, other engaged
services and resources (rather than
stubs), this section may be omitted in
the following standard versions.
- Michael
-----Original
Message-----
From: Danny Thornton <danny_thornton2@yahoo.com>
To: soa-rm-ra@lists.oasis-open.org;
mpoulin@usa.com
Sent: Mon, Nov 29, 2010 6:34 pm
Subject: Re: [soa-rm-ra] Issues
against Sections 4.2, 4.4, & 5.2
|
What is
foundational AND architecture
in section 5.4, SOA Testing
Model?
--- On Mon, 11/29/10, mpoulin@usa.com
<mpoulin@usa.com>
wrote:
From: mpoulin@usa.com
<mpoulin@usa.com>
Subject: Re: [soa-rm-ra]
Issues against Sections 4.2,
4.4, & 5.2
To: danny_thornton2@yahoo.com,
soa-rm-ra@lists.oasis-open.org
Date: Monday, November 29,
2010, 2:12 AM
I have to
look into section 4.1.1.2 again
(while I agree that
Figure 46 needs
corrections) before
making my opinion.
However,
I certainly disagree
with the proposal to
remove Section 5.4,
SOA Testing Model. If
you prefer, I can make
a definition of SOA
Testing Environment.
I
insist on this section
because the majority
of problems with
actual SOA projects
roots in inappropriate
testing for services;
it is quite different
than
traditional
testing as in the
sphere of tools as in
the sphere of
environment. Moreover,
particular testing for
services affects
service development a
great deal.
If
testing is organised
right, the development
will have much less
chances to screw the
projects.
If the
testing things are not
in the standard,
anyone can write
another White Paper on
our White Paper and
fully 'compensate' our
recommendations.
-
Michael
-----Original
Message-----
From: Danny Thornton
<danny_thornton2@yahoo.com>
To: soa-rm-ra@lists.oasis-open.org
Sent: Mon, Nov 29,
2010 5:41 am
Subject: [soa-rm-ra]
Issues against
Sections 4.2, 4.4,
& 5.2
There are no outstanding issues against Section 4.2, Service Visibility Model,
Section 4.4, Policies and Contracts Modek, and Section 5.2, Security Model.
Since the PR2 release, Section 4.4, Policies and Contracts, had pieces cut and
placed into section 3 and also had a significant rewrite. Section 4.4 now has
an emphasis on policy framework and enforcement. Figure 46 is no longer in sync
with the text and needs to be rediagrammed.
I recommend the following updates to the RAF:
1) Removal of Section 4.1.1.2 Assigning Values to Description Instances.
The data structures for service description vary depending on the implementation
constraints or expressive needs of the description. Section 4.1.1.2 will not
apply to the actual structure of many service descriptions.
2) Removal of Section 5.4, SOA Testing Model.
The SOA Testing Model does not have diagrams or definitions. It does have good
information and I would recommend this as a referenced white paper in the RAF.
Issues with Section 5.4 have been noted in previous emails.
3) Update of Section 5.3, Management.
Danny
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|
|
|