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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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


Subject: Re: [soa-rm] about AWS and SOA Services


Not quite sure how to find it, so could you point me to the MUST you are referring to?  I’m not advocating we reduce the bar, but I’d like to see where we set the bar.

Ken

On Aug 16, 2017, at 2:16 PM, Mike Poulin <mpoulin@usa.com> wrote:

Well, how a bad SOA service differes from a SOA service? A weak SOA service is the one that leaves the customer uninformed and open to surprises of service denial, restrictions or failures. More important, that a weak service has warn a customer that using such services is dangerous and can expose him to whatever troubles.
 
If we reduce our bar from 'must' (as specified in the SOA RAF) to 'should', we will open door for claiming SOA a weak or bad concept. Compromises may be in the price, not in quality.
 
Cheers,
- Michael
 
Sent: Wednesday, August 16, 2017 at 1:10 PM
From: "Ken Laskey" <klaskey@mitre.org>
To: "Mike Poulin" <mpoulin@usa.com>
Cc: "Rex Brooks" <rexb@starbourne.com>, soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] about AWS and SOA Services
Michael,
 
Thanks for this very in-depth compilation.
 
I need to go back to the RAF, but my guess is the inclusion of policy information in the service description is a SHOULD and not a MUST.  Still, I assume your idea of a “weak” SOA service is one that doesn’t act on the SHOULD.  I wonder what the equivalent statements are for GovCloud which is supposed to conform to ITAR regulations in the US.
 
Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H330          phone: 703-983-7934
7515 Colshire Drive                           fax: 703-983-7996
McLean VA 22102-7508
 
On Aug 16, 2017, at 5:54 AM, Mike Poulin <mpoulin@usa.com> wrote:
 

Hi Chaps,

 

here are my belated notes about Amazon AWS and SOA Services. They are based on Amazon's materials issued in response to the GDPR regulation.

 

1. Amazon AWS is a family of Web Services supported by Amazon asa a provider.

 

2. AWS has all pros and cons as a regular Web Service interface has. Amazon provides a description of each AWS separately from the interface and names the interface at a fine-grained level.

 

3. Amazon provides a separate common implicit service contract (see SOA RAF for the definition) for all AWS. In this contract, Amazon does not guarantee any exact functionality and nothing else as well as does not mention any supported policies or regulations. Instead, Amazon lists things it does not take responsibilities for when a consumer uses AWS.

For example, Amazon articulates protection of privacy of the AWS calls only from the point where the information/message reaches the Amazon's infrastructure leaving Internet communication channel unsupported/uncovered. Since it is not know what level of confidentiality GDPR or any other regulation requires, a strength of channel encryption - 64/128/256/512/etc. bit key - can be considered as OK or not enough, making the consumer open to regulation fines.

 

4. It is known that Amazon provides SW and HW infrastructure and supports related major security technology standards. It is unknown a precedent where Amazon would supported a domain/business specific regulation.

 

5. AWS are infrastructure components with standardised WS interfaces. These components may be grouped into:

a) storages like Glacier, S3 and EBS

b) computational like EC2

c) databases like Redshif, DynamoDB, Elastic Cache, RDS

d) tools to manage these resources like CloudWatch, IAM, CloudFormation, Elastic Beanstalk

 

As a result, Amazon Partners port existing applications, like ERP, on the AWS platform. However, quality of the application functionality remains the same as without AWS. For example, if it SAP ERP, even on AWS it remains a monolith with multiple interfaces and all internal queueing and memory block overflow.

 

Overall, AWS appear as well-known traditional IT infrastructure environment that uses HTTP as a communication transport protocol from the consumer side. Since we accept a concept of Data Access Service - an entity that explicitly operated with the database or data store via its drivers (even if they are based on Corba internally) - we, probably, have to recognise that AWS are Technology Utility Services in weaken SOA means. A dependency on business regulations, so typical to Business SOA Services, is not applicable to AWS.

 

6. Nonetheless, a special attention and accuracy is required when we talk about Cloud services. If the Cloud service is like AWS, i.e. performs a Technology Utility function, it may be a weak SOA Service, but if the Cloud service performs any business functionality, its adherence to SOA Service Description requirements - policies and contexts - is mandatory because policies and contexts impact the business outcome and compliance.

 

Regards,

​​​​​​​-- Michael P.

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