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: RE: [soa-rm] about PoSO and Microservices



Question 1. If the issue is the literal difference  between architecture vs architecture implementation, IMO  this is  the same question as: abstract class vs concreate class; virtual method vs implemented method. Abstract and virtual are signatures with no real, concrete implementation. An architecture starts abstract, describing types of entities, but listing no actual entity. Once you place an actual, real physical components in the architecture it becomes an implementation.


Question 2. The boundaries of SOA and categories of entities included within SOA (the extension of the SOA concept) speaks to how we define the concept of SOA. I continue to be surprised how difficult and technical it is to define an seemingly simple concept. Defining types and variations of SOA will be a significant exercise.  


I cannot immediately answer the SOA boundary question. I can suggest a methodology which will produce an answer. I rely upon ISO standards in Data Harmonization and Terminology. To begin with ISO 704:2009(E) Terminology Work – Principles and Methods,  Concepts have properties. For analysis of a concept, the properties are abstracted to characteristics. The purpose of the abstraction is to identify common features in a set of properties. For example, given the concept of a mouse. Mouse1 has the property of 1 button, Mouse2 has the property of 2 buttons. The abstracted characteristic is a mouse has one or more buttons. Similar concepts have shared characteristics, delimiting characteristics differentiates concepts. Identification of the concept’s unique combination of characteristics helps defines the concept and situates the concept within a network of related concepts. The set of characteristics that form a concept is the intension of the concept. The set of objects included within the concept is the extension. Necessary characteristics are true for all objects in the extension of the concept. A sufficient characteristic may not be true of all objects in the extension, but any object that has a sufficient characteristic is within the extension. For example, the concept woman has numerous characteristics. Not all women have given birth. However, being human and having given birth are sufficient characteristics to belong within the extension of the concept woman. Essential characteristics are both necessary and sufficient.  




From: Mike Poulin [mailto:mpoulin@usa.com]
Sent: Wednesday, September 30, 2015 6:00 AM
To: Natale, Bob <RNATALE@mitre.org>
Cc: Sweet Jr., William H <wsweet@mitre.org>; soa-rm@lists.oasis-open.org
Subject: Re: RE: [soa-rm] about PoSO and Microservices


your suggestion raises serious questions that are the cornerstones of many debates on this topic. Actually, there are two fundamental questions, IMO:
1) Where an Architecture ends and its Implementation starts?
          - for this, I have a definition of an Architecture that many consider too restrictive (because it clearly surfaces fallacy claims of the architecture subject vs. discipline. E.g., ‘people’ is not an architectural element, though it is very important to the operations of a business/technology system)
2) What are the boundaries of service orientation? If a certain category of entities adheres to _only_ a few PoSO, not to all, may it be considered service-oriented and to be a Variation of SOA or this is a Variation of SOA Implementation (then, who cares!?..). What constitutes that we still deal with a Variation of SOA or ‘this’ is not SOA already?


- Michael



Sent: Tuesday, September 22, 2015 at 2:16 PM
From: "Natale, Bob" <RNATALE@mitre.org>
To: "Sweet Jr., William H" <wsweet@mitre.org>
Cc: "soa-rm@lists.oasis-open.org" <soa-rm@lists.oasis-open.org>
Subject: RE: [soa-rm] about PoSO and Microservices

Excellent advice, William. (Needs to be adopted in many other contexts by many other groups and individuals.)





From: soa-rm@lists.oasis-open.org [mailto:soa-rm@lists.oasis-open.org] On Behalf Of Sweet Jr., William H
Sent: Monday, September 21, 2015 8:21 AM
To: 'Mike Poulin' <mpoulin@usa.com>; Rex Brooks <rexb@starbourne.com>
Cc: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] about PoSO and Microservices


Very informative article! I am wondering how we can help the industry reach this level of specificity in understanding  the relationship between SOA and the various implementation “styles”.  REST, ServiceComputing, Microservices and more are variations of SOA which are always susceptible to an interpretation  which separates the variation from the main body of SOA work, resulting in “reinventing the wheel”. To help the industry avoid this, perhaps we should include in our SOA ontology a subclass of SOA tentatively named Style or Variation, which is then specialized for each variation capturing what makes the variation unique. Perhaps this would help eliminate some confusion currently found in discussions of variations.




From: soa-rm@lists.oasis-open.org [mailto:soa-rm@lists.oasis-open.org] On Behalf Of Mike Poulin
Sent: Sunday, September 20, 2015 7:26 AM
To: Rex Brooks <rexb@starbourne.com>
Cc: soa-rm@lists.oasis-open.org
Subject: [soa-rm] about PoSO and Microservices



here is my short overview on how Microservices "compliant" with Principles of Service Orientation


- Michael


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