Re: [soa-rm] Fwd: Formal Review for the White Paper "Microservices Architecture"

["Mike Poulin" <mpoulin@usa.com>]

HI All,

 

I tried to use the link to the TOG White Paper and it required me to login in the TOG community, which I am not a member of. DO we assumed to comment on this White Paper? If so, how can we access this document and submit our comments?

 

Should we for a single view of our group or it may be a collection of individual opinions?

 

Following the last meeting, I have two comments:

 

1) comparing SOA and Microservices is EXACTLY the same as before TOG compared SOA and Web Services, i.e. like an apple and a jam. We cannot compare an Architecture to its Implementation! I am writing about this in all my articles and books for the last few years. The ratio here 1 Architecture : M Implementations

 

2) having an architecture, which is not a Thing in a Ivory Tower, we make certain assumptions that the architecture places certain constraints on the implementation - it may be with a lot of variations, but may not compromise the architecture (if it does, we should consider it not a unfortunate implementation, but as an implementation of something else, not our architecture). I am saying that when the architecture is about apple-based products, the implementation cannot produce a yogurt (milk-based) or a dry-mix (multi-fruits based).

 

Thus, taking a viewpoint of the service architect and developers, no implementation of the service may deliver something that would violate the Principles of Service Orientation in the final product. Within these principles, an implementation is not under a regalement. 

 

As a result, we have to preserve Service Boundaries in the service implementation. These boundaries define mechanisms via an implementation of the service may interact with the external world including other services. These mechanisms are: service’s public interfaces – for the communication with the service’s consumers, and the service-client interfaces (requester/listener) – for communication with other services in the role of client. No other links or dependencies of the service execution (of the service body) may be allowed.

 

At the same time, SOA concept appreciates and facilitates a massive dependency of the service operations on the external suppliers=other services. That is, a service is usually provides a quite narrowed functionality by itself while it can offer a lot of different features/functions, which it can acquires in the form of results via cooperation from other surrounding services. This ‘dependency paradox’ guarantees compliance with such SO Principles as Autonomy/Independence, Separation of Concerns, Composability and others.

 

If we standardize components or Microservices themselves, it is OK. If we standardize the implementation of a Service via Microservices, we have to cut off all possibilities for sharing the Microservices between Services other than through the official interfaces of the Services – public and service-client ones.

 

Regards,

- Micahel Poulin

 

Sent: Wednesday, April 27, 2016 at 5:58 PM
From: "Ken Laskey" <klaskey@mitre.org>
To: soa-rm@lists.oasis-open.org
Subject: [soa-rm] Fwd: Formal Review for the White Paper "Microservices Architecture"

I am forwarding the announcement of the Microservices Architecture paper from The Open Group.

 

Ken

------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510          phone: 703-983-7934
7515 Colshire Drive                           fax: 703-983-1379
McLean VA 22102-7508

 

Begin forwarded message:

 

From: Reggie Hammond <r.hammond@opengroup.org>

Subject: Formal Review for the White Paper "Microservices Architecture"

Date: April 22, 2016 at 8:44:50 AM EDT

To: <soa@opengroup.org>

Resent-From: <soa@opengroup.org>

Resent-To: <soa@opengroup.org>

 

All:

 

 

The White Paper for Microservices Architecture can now be found here.  Please note:  The review will commence on  April 25,  2016 and it will end May 8,  2016.

 

 

This is to announce the Formal review of the White Paper “ Microservices Architecture” produced by the SOA Work group.  

This paper presents the Open Group’s view point on Microservices and Microservices Architecture (MSA).  MSA is embroiled in a lot of debate particularly of what it is and if it's an evolution or a revolution. This paper is an effort to find the tree in the forest through diligent research of the current viewpoints in the industry and the perspective of the Open Group Work group members. The paper provides a clear and specific definition of MSA and Microservices, distills the core principles and key characteristics of MSA and Microservices, as well as a comparison with Services Oriented Architecture (SOA).

The review uses The Open Group review process, for a white paper, which is modeled after The Open Group Standards Review Process.

 

“A white paper is a discussion or position paper.  It is a mechanism for The Open Group to disseminate information on its current thinking for a subject area to an interested audience, with a view to soliciting feedback and comment.  White Papers have no formal status”.

 

The review will commence on  April 25,  2016 and it will end May 8,  2016.
The (commenting) review group will be the SOA  membership.
The (recommendation formulating) change request review group will be the authors of the white paper
The balloting group will be the SOA  membership-voting members.
 
For the benefit of those unfamiliar with The Open Group Review process, it is a formal process by which a document is approved for publication by The Open Group. You are invited to review and submit proposed changes ("Change Requests"), which would make the document acceptable to you.
 How to Participate
------------------
Participants are requested to review the draft white paper and submit Change Requests (CRs) that they consider will make the document acceptable or otherwise improve it. Change Requests will be submitted on-line via the Plato Review and Comment system. 
The document review will be provided shortly before the review starting date. A pdf of the draft will also be provided
You will be asked to supply your Open Group ID and password to access the review site when available. If you have forgotten your id password, you can request a reminder at:
http://www.opengroup.org/mailpassword.htm
Timetable

The timetable for this White Paper Review is as follows:

• March 18, 2016                                  Review Announcement
• March 25, 2016                                  Review Opens
• May 8, 2016                                       Review Closes
• May 9, 2016 to May 13, 2016             Change Requests addressed
• May 16, 2016                                     Ballot Opens
• May 30, 2016                                     Ballot Closes
• May 31 - June 8, 2016                       Executive approval 
• June 10, 2016                                    Publication

 

 

Regina Hammond
Forum Coordinator
The Open Group
+1 714-925-7240

 

 

 

The link to the event is www.opengroup.org/london2016

.