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] Groups - Draft - Minutes-SOA-RM TC June-21-2017.doc uploaded


Gentlemen,

I was not able to participate in the last meeting being in the conflict with two other meetings. I am sorry.

Rex has written the last Minutes so well that I can submit a follow-up – my 2p of contribution.

  1. Review SOA-RM – at a glance, I’d be interested in refining the definition of service, which would somehow outline that a service is a “working body” with interfaces that provides an access to the execution of capability and returns the execution results represented as a RWE.     IMO, this clarification would remove certain ambiguity and confusion, e.g. between SOA Services and Microservices. Nevertheless, I will need to review SOA-RM accurately.

 

  1. AWS Public Sector Summit – in the light of previous critics on Public Cloud in the domain regulated sectors of industry, expected enforcement of EU GDPR regulation (scoped world-wide) on the private data protection across domains/industries makes the use of AWS way too risky for businesses until Amazon proves it is GDPR compliant (which means that Amazon has to kill its economy of scale as it is today)

 

  1. DevOps – as a methodology for speeding development has a few traps: 1) it is especially effective in the cases where development can be substituted by assembly, like with Microservices; if assembly is not possible, the time benefits are not that significant and an acceleration comes from a merge between development and Ops – automated testing and deployment; 2) efficiency of DevOps is apparent in the single development stream (for one team). If the task for development requires two or more development streams, the value of Ops degrades significantly because after each stream conducts its development and testing, they still cannot deliver results to the consumer – there should be a cross-stream integration work and related testing. DevOps as well as Agile/Scrum methods lack the architectural e2e cross-stream integrity and testing (plus, an automation of UAT is extremely expensive ‘tool’).
 
  1. …AWS Lamdbda, severless computing in the cloud environment, that takes the emphasis away from hardware capacity specification to software development environment and continuous development/delivery.    - Well, Peter Drucker said, “There nothing so useless as doing efficiently that which should not be done at all”. Web Services as well as Microservices constitute a very high risk to the businesses of the consumers and expose these businesses to the mercy of WS and MS providers. There is no methodologically assurance that the provider will act in the benefits of consumer even providing returns as expected. I would not use such technologies until my business is protected.

 

  1. … in the SOA-RM one uses a service without having a private copy of it and basically accept changes as they occur, but with microservices one retrieves a private copy and receives notice when there's an update. –    This is a delicate topic or I misunderstand something. If a SOA Service is only an interface (which I disagree with), the consumer does not need to have a private copy of the interface because the SW behind the interface must construct this interface in a way that can handle multiple concurrent requests (based on the assumption that a normal service should be able to serve anyone at any time; otherwise it is a bad service, if at all). If consider that the SOA Service has a body (the working executable) and interfaces, the body should be either multithreaded or work via multiple instances (i.e. the service is, actually, a Factory of instances). In this case, each consumer’s request owns the thread or instance. If the interface changes, the consumer SW will be broken; if the body changes in a way that impacts the Service Contract, the notification of customer is mandatory. Plus, a SOA Service is always bonded with the Execution Context.
Microservices do not have such a bound, they do not know who use them and, thus, no notifications can be sent to nowhere. Microservices have a cloudy concept of the body, which may be humongous and, definitely, cannot be “retrieved” for the consumer. It seems that Microservices are also Factories generating an instance per request but this is the “interface” instance – a typical model used in programming languages. It is unclear to me what may be updated? If this is a new code in the “interface”, then there may be a notification when the instance-in-use should be undeployed to be replaced by a new code, but it is impossible to generate new instance without a new consumer request. Also, it is unclear how a notification can be delivered without a knowledge who use the instance… Ken, to me, the quoted statement is quite unclear; it does not seem right. 

 

  1. Ken noted, with microservices the process of update is also simplified. Ken said that with microservice bounded context the idea of getting a new image is acceptable but downloading say a whole oracle database wouldn't be. So, quick exchange of microservices is doable as long as we keep the pieces small. Well, I have never heard that Microservices have fixed, concrete body. They are interfaces with declared functionality, which is not formally documented-and-tied to the MS. The MS appears as an entrance into an area without boundaries. Also, what is the mechanism that bounds the Microservice with the context?
Cheers,
- Michael Poulin
 
Sent: Wednesday, June 21, 2017 at 7:10 PM
From: "Rex Brooks" <rexb@starbourne.com>
To: soa-rm@lists.oasis-open.org
Subject: [soa-rm] Groups - Draft - Minutes-SOA-RM TC June-21-2017.doc uploaded
Document Name: Draft - Minutes-SOA-RM TC June-21-2017.doc
No description provided.
Download Latest Revision
Public Download Link
Submitter: Rex Brooks
Group: OASIS SOA Reference Model TC
Folder: Meeting Notes
Date submitted: 2017-06-21 11:10:35
 


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