OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Fwd: [soa-rm-ra] Issues against Sections 4.2, 4.4, & 5.2


 
Michael,
 
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.
 
Danny

--- On Mon, 11/29/10, mpoulin@usa.com <mpoulin@usa.com> wrote:

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
soa-rm-ra@lists.oasis-open.org




-----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 





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]