| Michael (and others),
I had intended to spend more time tonight responding to SOA-RM email but my 15-minute drive home took an hour longer and sapped me of energy and patience.
re COS, I need to reread this again. Some interesting ideas but I’m not convinced on the first read.
Drawing on other email responses you sent, I don’t believe developers are just hooked on objects, though I do believe SOA was doomed when it was reduced to middleware and annoyed developers with excess complications. (I could get into complicated vs. complex and argue for living with complexity rather than hiding it in complications, but I’ll spare you for now.) There was also always a mumbled concern with SOA about network latency and responding to faults, but these were hidden in the ESB and never run to ground at a conceptual level. Maybe I’m wired strangely, but I always found service concepts to be simpler than some object principles.
Anyway, stay tuned — maybe not until tomorrow — for the dial-in info.
Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
Let me elaborate a bit on the Concept of Orientation on Service to focus on in out Committee work as the next subject.
1. COS is a single fundamental mechanism/instrument used by all business organisations in all industries worldwide. THis excludes primitive or socialist societies. In all cocieties what preserve saparation of labour and resulted trade of goods to sutisfy people needs, COS flourishes. This is the only way to generating revenue (not necessary profit). Yes, it is not the only one in different cases, but it is the only one that presents everywhere.
2. SOA is an architectural model of COS. As any architectural model, it can be implemented in many different way within the boundaries of concept. At the same time, there may be multiple implementatiyon or practices that contradict COS. On a time-scale such enterprises or business organisations head to default because they cannot provide (in legal way) resources needed to support their own existence. Non-profit organisations are not exceptions - yes, they live on donations, but they generate/solicit donations by thier social activities (end even by the fact of thier declared goals).
Governmnet organisations are not exception as well. They exist and operate based on the funds provided by tax-payers, but these taxes are paid for the services Governmnet organisations provide. [A denyal of paying taxes in the Boston Tea Party was caused by a need to get access to the service managemnet first, wasn't it?]
3. A common problem with IT and several other "SOA Standards" is in that they approach thier activities from the perspective of "delivering a value" (a value in thier opinion), not providing service (=value) to those who are in need (regardless the reasons of need).
4. COS is about buisness centric view on operations in the business organisation including IT, which is well depicted in ITIL v.3 (BTW, its concept is fully in sync with SOA RM and was heavily critisised for this by "practitioners" who did not want to become responsible for thier work).
5. COS has to have its ontology (wider that an ontology for technology becuase it is about behaviour of humans & systems).
6. COS leads to the organisation of business in SO way including organisational and operatinoal structures, finance, internal and external relationships, corporate culture and relationship with customers and social professional organisations in the markets. For example, lobbying Government is in the COS though it is not customer-centric method.
Any thoughts about this?
- Michael
Ken,
Mostly agree with: " “An application is a composition of one or more software components that when implemented together provides a coherent grouping of business functionality."
Proposed enhancements:
"when implemented together..." --> "when executed together...";
"provides a coherent grouping of business functionality" --> "provides a business functionality or a coherent grouping of business functionality"
Disagree with:
"What has been popular over time as a software component has varied: Web Services were of interest during the emphasis on SOA; microservices currently receive the majority of attention." Particularly, Web Service is not a component - it does not provide any business functionality. Moreover, "emphasis on SOA" has not went anywhere, it just comoditised and this is why MS constantly refer to SOA.
SOA is a misleading term, undfortuneately. It talks about 'Architecture' instead of a Concept of Orientation on Service (COS). Discussed MS fully fit with a transition to COS thogh they themselves do not consitute/make an justification of COS.
Instead of debating foriegners' opinions and statement about MS, let out Committee to focus on COS as the next and logical continuation of our work.
- Michael
So would this generalize to
“An application is a composition of one or more software components that when implemented together provides a coherent grouping of business functionality. What has been popular over time as a software component has varied: Web Services were of interest during the emphasis on SOA; microservices currently receive the majority of attention.”
Ken
Hi Ken,
To you original query: “My biggest problem is I have yet to see a good definition of “application”. Is it just the user interface that calls microservices under the hood?” …
Taking the perspective of a microservices architecture evangelist, I’d answer “An application is a composition of one or more microservices and other implementation mechanisms that provides a coherent grouping of business functionality.”
That’s quick n’ dirty but conveys the sense as I understand (in the microservices context).
Came across this article
and while the focus is really on OSGi, its discussion of microservices includes the following:
The first model is the microservices model. With this model, components are defined as independent microservices that any application can use. They also have stateless behavior so they can be replaced and scaled as needed. Additionally, they are independent of each other and of applications that use them, so deployment/redeployment of a microservice doesn't affect applications it serves.
But microservices might be the biggest revolution in componentization. A microservice is a logic component deployed in RESTful form, designed to be accessed through a URL. Microservices easily address issues of component dependencies and avalanches of redeployments due to small component changes because microservices are independent as long as the API call formats are maintained. Microservices won't change the modularity of JVM or provide an efficient way of managing remote-versus-local components, but they could significantly reduce the burden of component management for distributed components.
My biggest problem is I have yet to see a good definition of “application”. Is it just the user interface that calls microservices under the hood?
Any favorite (attributable) definitions of application?
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
--------------------------------------------------------------------- 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
---------------------------------------------------------------------
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
|