Let me explain: Business SOA = SOA. Technical SOA is just a technical part of SOA services. We clearly see a tendency of Technical SOA occupying more and more territory of Business SOA implementing more and more intelligent technical solutions and replacing less intelligent manual operations in Business. The intelligent technical solutions are very costly because they are still accompanied by enormous amount of not that intelligent technical solutions that consume billions world wide providing none or very little business value.
The key factor of this cost is the persistence of the IT specialists who still try to merge their business knowledge with inadequate unified abstract technical programming tools. Even worth, IT people (primarily, those who work for SW vendor companies) give business titles to those programming tools creating a 'circle of absurd' by doing so. Many other developers surrounded by the 'circles of absurd' spend millions on applying technology to the wrong subjects under right banners... and, obviously, fail. Here are a few examples of recent things that have formed the 'circles of absurd':
• Web Services - the technology that does not address services but only service interfaces and that does not necessary need Web to execute;
• SOA - service-oriented architecture, which has been substituted by different technologies that not necessary provided any orientation on services and, in any case, had nothing to do with the notion of architecture. Fortunately, this element of the 'circle of absurd' has been broken through and many people rid off technocratic mindset in the area of SOA;
• BPM - nobody knows up-front what this term means - BP management, measurement, monitoring, modelling or migraine. Anyway, IT believes that if it automates manual operational activities and runs them as a program, it is the fact of business process management (omitting another fact that when a manual operational activity gets replaced by the program, the business process dematerialises together with its management).
I do not think that I am only the one who has recognised that the bridge between people intelligence and technical programming tools is the semantic technologies. Recent article "Semantic Technologies in Integration and SOA", published by Vasudevan Ramanujam, gives us very good accumulation of the thought and examples of the tremendous business value of semantics. I would like personally to express gratitude to Vasudevan Ramanujam for this work.
While the article lists several technical areas where semantic-based approach promises a lot of benefits, I will focus on SOA (what a surprise!). The author outlines following "value add at two levels of Service-Oriented Architecture:
• Service Creation
"
• Service Definition
• Service Orchestration
• Service Management and Governance
Additionally, the semantic aspects of the service interface are described as:
• "Knowledge Interface description
• Interface relationship description
• Data/parameter transfer description
• Transformation description
• Annotation for existing data."
I guess that the 'service construction' and the interface areas of SOA services are meant by the author as "two levels". I can sign under the 'service construction' group. However, the 'interface' group requires some comments. These comments base on the given in the article explanations about the separation of roles between the users and the system with regard to the semantics of the interfaces, particularly:
• "An administrator/user initially creates the description of the services which will be converted into triples and stored in the repository. Relationships for these services are also created
• Administrator adds the Context/key words/description/Meaning
• System discovers the service based on the initial set up and context
• System will also be able to discover the service relationships
• System can infer the context and relationships
• System will be able to add context based on the service usage pattern to contextualize the services
• A User will be able to discover and use services-the back end inference, if required, will be done by the system"
So, taking about the semantic aspects of the service interfaces listed above, I have to ask what would be an "Interface relationship description"? If this is about relationships between interfaces, I am not aware of any such things and it would be interesting to learn more about it. If this is about relationships between the interfaces and the service they relate to, I do not see any semantic aspect in this - the things existing in the service interface may be re-interpreted inside the service but why such interpretation should be driven by pre-defined ontologies? I think that the service business functionality is enough constraint for possible semantic variations between the service interface and its body.
It is not obvious to me what the difference between "Data/parameter transfer description" and "Transformation description" is. I do not think that semantics defines data transfer per se while the transfer target is an obvious subject for the semantics related work. Also, "Annotation for existing data" is the trivial statement - data without semantic annotations has no business value at all. Moreover, SOA Services do not deal with data, even Data Services; SOA Services work exclusively with the data semantics, with the meta-data. Physical data models are attributes of implementation, not to the service architecture. The same data values may have different semantics for different SOA Services. Thus, data semantics or annotation is a priori assumed characteristic of data in SOA Services.
Regarding the roles and responsibilities listed in the article I have more serious comments.
First of all, service description may be only recorded by the Administrator and never ever created by "An administrator/user" in SOA environment. The Service Description document is, actually, created by the service provider only (according to OASIS SOA standards). The user has only one choice - take it or forget about it. Even if the user requests certain policies to be used by the service, these policies may be included into the Service Contract, not into the Service Description. However, the service provider can eventually consider the user's request and modify the service respectively changing the Service Description.
If we talk about Service Registry or Repository, the Administrator "adds the Context/key words/description/Meaning" to the records. Nonetheless, the "Context/key words/description/Meaning" are defined by the service provider only.
The phrase "System discovers the service based on the initial set up and context" is very unclear to me. What does mean "System discovers"? Why the system needs to know about the service? Isn't it a task of the service consumer? Plus, the service context or, as OASIS SOA defines it more accurately, service Execution Context exists outside of the service independently from the Administrator. The service Execution Context must be included into the Service Description and related Service Contracts as the condition which the service provider guarantees the service characteristics in. So, I do not see how semantics plays here .
The statement "System will also be able to discover the service relationships" is beyond my understanding. What does it mean for the service consumer and/or for the service provider? How the system understands the service relationships when in many cases these relationships are the knowledge of the service consumer only (expressed in the particular combination of the service invocations)? If we talk about aggregate services that can pre-define the engaged services, this knowledge belongs to the services, not to the service run-time environment, i.e. to the system. So, I do not see a reason for applying the semantic power in this case as well.
The next statement "System will be able to add context based on the service usage pattern to contextualize the services" puts everything up-side-down. System cannot add a service Execution Context (add to what?) because it is the service Execution Context itself. The service is contextualised always regardless the abilities of the system. The user, indeed, can change the "service usage pattern" as needed moving from a 'multiple use' to re-use mode. However, related change in the semantics in this case is totally attributed to the user, not to the system and not to the service.
Finally, "A User will be able to discover and use services-the back end inference, if required, will be done by the system"; is it because the system can understand the service's semantics? Even if it is true, why we need to use this system's intelligence? If the service is OASIS SOA Service, i.e. a service-oriented application, I think it can/should manage its back end by itself; if the back end is a data source, there should be another service that translates between the business data and the data model used in the data source. Semantics in this case is the first class citizen, no doubts, but, again, it is not attributed to the system.
In my book 'Ladder to SOE', I discuss how Semantic SOA would help in achieving a mutual understanding between service consumers and providers of what the service functionality and service results -Real World Effect - really mean in their agreement. This role of semantics is the cornerstone in the turn from Technical SOA to Business SOA. Here is only one example: Technical SOA promotes an idea that changes in the service implementation are irrelevant to the service consumers until the service interface used by the consumer stays immutable. Actually, this is not right in Business SOA - the business functionality provided by the service, i.e. the functionality realised by the service implementation, has much more value than service interfaces. In other words, a change in the service implementation (the latter is still transparent to the consumers of the business services), which affects business functionality constitutes the change in the service. Such change can break the Service Contract with the service consumers while all interfaces stay the same. This directly relates to the semantics of the Service Description and Service Contracts and, as a result, affects the interaction with the service.
Service-oriented ecosystem promotes sharing of the data semantics in the enterprise. The semantics of the Service Description must be clear to the service consumer in order to make the decision whether to use particular service or not. This does not necessary mean that the consumer must use this semantics in the interactions with the business service: both consumer and provider can agree off-line on a translating intermediary used in the business transactions or interactions with the service. Yes, I do mean business transactions that assume certain business responsibilities of the engaged intermediary, i.e. the latter cannot be just a piece of IT infrastructure in this case.
If I were summarised the cases where semantics becomes the crucial element of SOA, the list would include:
1) Service definition, modeling and design
2) Look-up for the Service Description
3) Forming the Service Contracts
4) "Service Management and Governance"
5) Service aggregation/orchestration (in the area of selecting proper services)
6) Service Change Control and maintenance
7) Service Registries and Repositories
8) Service implementation via processes and the business objectives of the latter
9) Integration between manual and automated parts of the business service
I hope, you will continue this list.
Firsly I apologise if I am missing some point.
I have to recognise that I am also messed up with how "semantic" concept is been applied to SOA, as different people seems to be understanding different things.
In my understanding, 'semantic' implies that the every chunk of information "has a background", forming all a semantic model or ontology.
A model is semantic when it represents the nature of an object as is, i.e. unbiased to any "point of view".
2 applications interoperate semantically when, sharing this background, they are able to understand, no what they say (interface) but, what they mean (background). They are able to understand the status of the background of each other (I can provide an example if required).
As a consequence, the important thing about semantics are not the interfaces themselves, but the model behind them, which is shared by both parties. In fact, I guess, different interfaces could be used to inquire the background.
So, with this understanding and, sorry if I am wrong, I try to address your questions:
[...]*If this is about relationships between interfaces?[...] This sentence suggests that the whole of interfaces forms or belong to a semantic model. In my opinion this is an oxymoron since, the purpose of interfaces is communicating 2 parties, not creating a model or truly representing an entity.
[...]If this is about relationships between the interfaces and the service they relate to[...]. Well, we come here in the definition of service (which you probably know better than anyone else). In my underdanding, a service is created to fulfill a business necessity, but not for representing an entity (ontology). So again, I think there is an oxymoron here.
As a service is a business concept, and probably would need the composition of several entities/ontologies, I see the semantic layer down in the stack of the architecvure, and not in the (almost) top SOA layer, probably in middleware. This middleware would enable semantic interoperability for the famous semantic web and extended enterprise and the promissed SOA reusability would be there.
But this is just technical. Second question would be: is this feasible in todays enterprise world? I do not think it is at short term.
Does it make any sense?? (sorry any inaccuracies or missed concepts). I appreciate any corrections.
Adolfo
Adolfo,
Let me answer a few of your questions assuming that I agree with the rest of your statements.
>>A model is semantic when it represents the nature of an object as is, i.e. unbiased to any "point of view".
I do not think this “unbiased� state has been reached anywhere but in Babylon before the bad things happened. To me, a semantic model is a particular "point of view" agreed among the group of uses of this model.
>>2 applications interoperate semantically when, sharing this background, they are able to understand, no what they say (interface) but, what they mean (background). They are able to understand the status of the background of each other (I can provide an example if required).
Let me rephrase your sentence in ‘my’ English: “...are able to understand,� not how they say (interface) but what they say. If these 2 applications share/agree on semantics, what they say automatically translates into what they meant.
>> [...]*If this is about relationships between interfaces?[...] This sentence suggests that the whole of interfaces forms or belong to a semantic model. In my opinion this is an oxymoron since, the purpose of interfaces is communicating 2 parties, not creating a model or truly representing an entity.
[...]If this is about relationships between the interfaces and the service they relate to[...]. Well, we come here in the definition of service (which you probably know better than anyone else). In my underdanding, a service is created to fulfill a business necessity, but not for representing an entity (ontology). So again, I think there is an oxymoron here.
Adolfo, I am sorry but my sarcasm in these two sentences somehow skipped from your attention. Can you imagine a relationship between two independent interfaces? I cannot. If we need a semantic bridge between the service and its interface, let me ask: is this interface the right one for the service?
>>As a service is a business concept, and probably would need the composition of several entities/ontologies, I see the semantic layer down in the stack of the architecvure, and not in the (almost) top SOA layer, probably in middleware. This middleware would enable semantic interoperability for the famous semantic web and extended enterprise and the promissed SOA reusability would be there.
Where semantics situates – at the top or in the middle of the SOA stack? Well, why is this important? The fundamental definition of ‘service’ and service-oriented relationships, are these concepts at the top of SOA stack or not? Indeed, the “middleware would enable semantic interoperability� but does this mean that semantics does not exist or is not needed at the top of SOA stack?
>>But this is just technical. Second question would be: is this feasible in todays enterprise world? I do not think it is at short term.
I do not say it is a short-term process. However, business SOA is feasible if you properly combine willingness and money.
Hi Michael,
I think the key issue here is, if is possible to find a canonical unbiassed model? I think you agree that this model would be THE more suitable for reuse since it is "neutral". When the model is not canonical, and there is a coupling between variables, extensibility is somehow 'out of control'.
I do not think this “unbiased� state has been reached anywhere
Well, depends of the "scope" of "your universe". If your universe has an small number of "dimensions" surely is possible to find a cannonical representation of their entities (the idea is borrowed from algebra). If your universe has 200 dimensions (your scenario), I do not think any human can do it, and the only option is empiric, and a bit "accidental", with unpredictable results, that can be only managed statistically. Reusability is the (one of) EAI problem that SOA is supposing to address but, at the long term, does it falls in the same thing? Just wondering.
But, can we hierarchize the dimensions of our universe (i.e. a dimensional company model)? Well, I have some work on it. I think is theoretically feasible.
If you create a canonical model considering X dimensions, but you change the number of dimensions (a new department, a new regulation, new requirements...), the model is not longer canonical. Is this the current problem of SOA projects?
If these 2 applications share/agree on semantics, what they say automatically translates into what they meant.
Not sure if I understand what you mean by "agreeing semantics". Lets take an example of an arbitrary accounting item 'Changes in inventories of finished goods and work in progress' transmitted between 2 accounting apps. If both parties do not agree on underlying background (i.e. accounting principles, aggregation on accounting items, time scope...) they will understand different things. This is where semantic interoperability takes place. But, if they agree, no matter the interface(s) because the intend is to communicate "the internal status". We are not that tied then to an specific interface. Another example can be 'Competency Models'. Does both parties make the same breakdown of a competency?
But, I agree that this semantic agreement is not always required, specially in transactional or control messages.
For business processes (not in Fussion concept), which runs within the same company, the background is previously agreed or even not needed. This is why I 'suspect' that semantic layer for interoperability, and SOA layer to support BPM, can be at different levels.
Can you imagine a relationship between two independent interfaces?
Sorry about this Michael. I understood not relationship "between interfaces", but the idea that all of them together conform a semantic model. (e.g. following the idea of WSRR to index interfaces forming an ontology (?)). I missunderstood your case.
but does this mean that semantics does not exist or is not needed at the top of SOA stack?
I see semantics, as the static model down the architecture for semantic interoperabity as commented above. And, the SOA layer, derived from the semantic layer, at the top, giving support to processes. The reusability spinning around the inmutable semantic layer, because the SOA one is already biased, and reusability can be "accidental" at this level. I think there is a lot of confusion as well between "common model" and "canonical model".
but does this mean that semantics does not exist or is not needed at the top of SOA stack?
Well, depends on evolution level of BPM. For a 'hardcoded' BPM probably a syntactic layer would be enough (is not it?). In fact, this models cannnot be canonical as they are biased by human/process necessities. But, not sure if in Fusion processes they should also share the semantical background to be able to 'think'. Actually, I have moved down in the stack. But, if the question is, if I see the semantic layer down in the hierarchy, response is yes. Maybe the concept of 'topic maps' would fit.
SOA is feasible if you properly combine willingness and money.
Depends on what exactly you mean by 'SOA'.
In reference to reusability I think there are problems that cannot be solved empirically and require a rational approach (kind of semantic middleware/integration).
So, from the rational point of view, I see SOA in the future after lower layers are clearer. From the practical point of view, I think current semi-empirical efforts are a required step, is possible even to get a business model, but I am afraid reusability will always degradate with time. This does not mean that work will not be required anyway, sure it is.
Somehow, this is the ethernal discussion between reason and facts. Reason guarantees success, but is not always practical. Facts are practical but not always guarantee long term success.
Well, I am exploring these ideas and more teorethical that practical, so far, so, please, take it as input, and not at all a criticism. I lack a robust theory to criticism any point. For the moment, I found the problems but not yet full solutions.
Regards,
Adolfo
Adolfo, you have touched many serious and ‘large’ topics that I think are too much for a Comment section. Let us to discuss them off the ebizQ line. Thus, I’ll with a few comments only.
I think that semantic model cannot be canonical in general because it must work in the context of particular enterprise, first of all, then, across a group of partners (only). Expecting omni-semantic model is unrealistic, IMO. If an enterprise has its own ‘canonical’ semantic model and new department/group comes, this group must sign off this semantic model. If the enterprise has right organisation for Business and Technical Enterprise Architects, this job will be done well.
My agreed semantics = your example. “We are not that tied then to an specific interface� – agree.
As of “evolution level of BPM�, in my book ‘Ladder to SOE’ (http://www.amazon.com/Ladder-SOE-Resourceful-Efficient-Technology/dp/1848761627/ref=sr_1_1?ie=UTF8&s=books&qid=1281001667&sr=8-1), I argue that at the top of the business pyramid in any enterprise, there are only a few (5 to 7) business processes exist when everything else is articulated as business services. That is, SOA sits at the very top of business while BPM comes much lower when the business services get implemented in the business via business actions (a process is an ordered sequence of actions).
I think that semantics has to be presented in all possible levels and layers. It is another how it is utilised at different levels and contexts.
“Depends on what exactly you mean by 'SOA'� – by SOA I mean the ‘thing’ defined by the OASIS RM for SOA and RAF for SOA (draft) standards. SOA is a service-oriented architecture which positions between Business and Technology, which works in both Business and Technology but does not belong in full to Business or Technology.
Good luck.
Hi Michael,
Adolfo, you have touched many serious and ‘large’ topics that I think are too much for a Comment section
Well, yes, we are approaching the elephant by different paths, so both scenarios are different, and is complicated to discuss isolated issues.
I think that semantic model cannot be canonical in general because it must work in the context of particular enterprise
Do not agree here but I prefer to keep some info to protect as IP, at this moment. I have also to progress on mine.
I argue that at the top of the business pyramid in any enterprise,
First, I have more time now to read your book, so is the next thing I will do. I do not know if I will see a (quite clear) "identification" of different layers in the stack but I think it is required. Any company has data with different aggregation levels (e.g. transactional data, reporting data, statistical data.....) and with different purposes (e.g. support processes, communicate with business partners, report to regulators.....) and I find hard to see all in a multipurpose flat structure. Then would be easier to refer to specific layers on discussions. That is why asked what exactly you call SOA, but I will drill down before more in your work.
Thanks Michael,
Adolfo
Michael,
one comment. I liked the approach in this article about "Services are not Lego's Blocks".
I think is quite the same that we discussed above. Specially the sentence To conclude services are re-usable but differently from the Lego blocks, services can be shared simultaneously across processes or composite services.
It comes to my mind that 'Reusability Principle' in SOA could be further specified. I guess a good mathematician could help on clarifying the reusable concept. However, I agree with you that feasibility of 'Lego Blocks' has to be demontrated.
Regards,
Adolfo
Principle of Service Reusability:
'Services contain and express logic that can be reused in the execution contexts; services can be positioned as reusable enterprise resources'
The focus here is on "can be reused", not "should be reused" or "must be reused". Since SOA services does not anticipate how future consumer would use the service, actual reuse may never happen. This absolutely does not mean that not reused (so far) service should not be recognised as a service.
SOA service should be ready for reuse, nothing more. The value of the service is in realisation of business function while 'reuse' is one of the advanced service's features but not a purpose or goal.
It looks to me that there are different types of 'reusability', and the word, itself, is a bit generic, but, with today's state of arts, yes, fully agree with you.
Adolfo
Dear Michael,
Thanks for the detailed review of the article and your perspective on some of the concepts i mentioned and the corrections i need to consider. I just had a few clarifications in this which i have mentioned below. Elicit your views on the same. Thanks again
Regards,
vasu
“Interface relationship description"
Vasu - I used it in more generic context with the definition that an interface represents (or can be made to represent) the business context of the service; such set of related interfaces could be orchestrated dynamically together to address a business functionality. For instance “claims management� could be a business functionality and we could create the ontology which the system could use based on the incoming request (could be either from a user or another system)
Vasu - An administrator/user – I should have defined more clearly what a “user� and “administrator� meant – I meant a business/system user from the provider system who will provide the definitions/descriptions of the service. Same applies to the next comment also
System discovers the service based on the initial set up and context
Vasu - When a “user of the service� (the user could be a consumer or another application) enters the system the system can automatically identify the service (he requires or may require) based on the relationships defined and that learnt by the system, based on the previous behavior (of the user/application)
System will be able to add context based on the service usage pattern to contextualize the services
Vasu – In the above two cases I do agree the user/application who uses the services provides the context, but it is the system that needs to take that context and process it. Whenever I used “System�, what I meant is that the system will be able to process this decision (in short, Look Up) and take appropriate action.
Dear Vasu,
thanks a lot for the clarifications. I have two points to comment on:
1) I have difficulties to formulate relationships between independent interfaces. One service can orchestrate other services and interact with them via their interfaces. However, this does not justify any relationships between used interfaces.
2) we use term 'context' differently. I follow the OASIS SOA standard definition where service execution context is a set of policies to be applied at the interactions between consumer and service as well as to the service execution. In you text, 'context' sounds like a name of the application of user, or similar to this.