I'm still a skeptic on Sematics, as a guidance approach I think they can work a bit if human assisted but I think TBL is wrong about them. There are real mathematical limits around automatic ontology matching for instance. Using semantics to enrich the information set is a good thing but expecting to be able to process it is (IMO) rather optimistic.
Steve On 20 July 2010 02:11, Gervas Douglas <[email protected]> wrote: > > > <<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<http://www.amazon.com/gp/product/1848761627/sr=8-1/qid=1279486828/ref=olp_product_details?ie=UTF8&me=&qid=1279486828&sr=8-1&seller=>that > the bridge between people intelligence and technical programming tools > is the semantic technologies. Recent article "Semantic Technologies in > Integration and SOA", published <http://www.soamag.com/I41/0710-1.php>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<http://www.amazon.com/gp/product/1848761627/sr=8-1/qid=1279486828/ref=olp_product_details?ie=UTF8&me=&qid=1279486828&sr=8-1&seller=>', > 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.>> > > *You can find this article at: > http://www.ebizq.net/blogs/service_oriented/2010/07/business_soa_facilitates_semantic_technologies.php > * > > *Gervas* > > >
