---------------------------------------------------------- AZ001: Service as Logical Representation How one should take this basic definition: ''a service is a logical representation of a repeatable business activity that has a specified outcome.'' Why its genus ''a logical representation''? If you speak of the service as a model, it is one thing. If the service in general, it is a wholly different situation. Again, why its deferentia is chosen as ''a repeatable business activity that has a specified outcome''. The same can be applied to fishing, mining, agriculture (the primary industry) or manufacturing (the secondary industry) as well. A service is a complex business process, involving a service provider (agency) with its skill, experience, ingenuity, or expertise and service customer delivered intangible goods: new knowledge, learning, information, advice, experience, plan of actions, defence, safety, care, and other life necessities (food, shelter, utilities). So an adequate service definition is supposed to cover all its connotations: from child care services to marriage services to religious and burial services. ---------------------------------------------------------- AZ002: Cause and Effect Re. ontological statements, they could be worded more carefully, imho. For instance, it is asserted, '' there can be changes and events that are not effects of anything''. In fact, there are not such changes and events, any of them always is either a cause or effect. This is in the nature of changes. ---------------------------------------------------------- AZ003: Distinguishing Characteristics As a suggestion, as a distinguishing characteristic may serve ' to satisfy the requirements of the public, to perform the duties of the office, to promote the interest of the customer, to be of use, utility, advantage, benefit, good, purpose, profit or assistance, in some requested changes, in the customer's knowing, physical possessions, tangible assets, etc.'. ---------------------------------------------------------- EB001: Nature of Services Ravi Sharma wrote: SOA deals with all three at least, namely - Business - Information (applications and data) and Technical services to cater to the whole enterprise. The business services are catering to business components that can be grouped into business functions. Example of technical service is a web-service for message delivery or for notification or service for network related management, security services, etc. This is the hype version of SOA, whose purpose is to sell webservice implementations (read: "new software technology") to management, and allow a bunch of pundits to sell books and "newspapers". The services that we know how to implement with software, and the only ones that are really implemented, are all relatively simple technical services that are pure information technology. There are two major exceptions to this: - financial services -- because they are *entirely* information technology (there hasn't been any substance there since the G7/8 went off specie-backed currency, and the requirement for specie reserve affects only financial policy, not financial transactions) - media (books, newspapers, music, video) -- because they are now also entirely information technology (even though they are still evolving the business practices to deal with the fact that there is no longer a need for any physical media to change hands) Business management in general isn't going to invest much in yet another software networking technology -- we have had our 3 strikes. So the SOA folk have to say "business", even though what they can envisage never gets out of the .com think of 10 years ago. Ken Laskey got it right: I find it useful to differentiate between a business service and a SOA service. Business services are described in the more traditional sense of providing a business function, yes with predictable business outcomes, i.e. real world effects. That is, there is some material or labor involved in changing the state of the physical world. The software itself does not do that. It could conceivably control devices that do such things, but the real-time control community has had functional distributed systems technologies for at least 15 years, and doesn't need the high-overhead re-invention that is SOA technology. And unsurprisingly, the same is largely true of the finance industry and, more recently, of some highly visible elements of the media business. A SOA service is an IT artifact that *may* be an effective way to realize that business function. Specifically, when that function can be fulfilled solely by the communication of information. Conversely, SOA will be inappropriate and have no role in certain business functions. Even though these functions can be implemented as "business services", like building maintenance. ---------------------------------------------------------- EW001: OWL - isDirectionActivityOf isDirectionActivityOf has two sets of global domain and range constraints. I believe the second set ( ) to be spurious. EW002: OWL - hasDirectionActivity and Choreography Also, you should really make a choice if want hasDirectionActivity to be a subproperty of hasComponent with a domain of Activity *or* if you want to specify Choreography as a subclass of Composition with cardinality restricted to zero for hasDirectionActivity. Suggest changing domain for hasDirectionActivity to Composition (of course, isDirectionActivityOf would also change to stay in sync). Otherwise I would expect the anonymous restriction to be unsatisfiable (since the domain constraint means that individuals with hasDirectionActivity must be Orchestrations, but Orchestrations must have 1 value for that property). >>>> Subsequent discussion On your second point, the domain of hasDirectionActivity is Orchestration, rather than Activity. Orchestration is a subclass of Composition, and is disjoint with Choreography. (There is no explicit statement that it is disjoint, but this is implied by the cardinality restriction.) I didn't think there was a problem with this - but will look again to see whether I'm missing something. Yes. That's what I meant to say in the first sentence. It was a typo. Substitute "Orchestration" in place of "Activity" in that first part of my first sentence to get my meaning. The point again being that the restriction (call it R1) on hasDirectionActivity in the class description for Choreography must be a subset of the members of Orchestration because of the domain constraint on hasDirectionActivity, but there can't be any members of Orchestration with zero values for hasDirectionActivity because of the restriction (R2) in the description for Orchestration, so the set matching R1 is empty - making it unsatisfiable. I would think this, in turn, would make Choreography unsatisfiable (since it is a subclass of R1). Thanks, yes - now I take your point. Your proposal to make Composition the domain of hasDirectionActivity would fix this problem. Alternatively, we could remove the restriction from the class definition of Choreography and say explicitly that Choreography and Orchestration are disjoint. ---------------------------------------------------------- EW003: OWL - inverseOf isRegisteredIn The inverseOf isRegisteredIn should be "registers" rather than "register". ---------------------------------------------------------- EW004: OWL - Virtual Actor I also wondered about the description of VirtualActor. Did you mean to define a VirtualActor as an Actor and a System that can only have values of type (Actor AND Realization) for hasComponent (slightly reformulated, but I believe it is equivalent semantics to what is in the file)? >>>> Subsequent discussion Yes, this is the intent. The logic behind this definition is probably the most complex of any in the ontology, so subjecting it to close scrutiny is probably a good thing. ---------------------------------------------------------- FC001: Nature of Services I'm concerned about some basic SOA concepts and terminology, and the failure of IT people to recognize that SOA is about business and the use of technology to support business. So what we do is business, how we do it may be IT (could also be paper or telephone). The OASIS SOA Reference Model has gained considerable recognition. It defines SOA services as being offered across organizational boundaries. You don't cross organizational boundaries without dealing with business. So here are some concepts with a business perspective. Question marks indicate a need to establish appropriate terminology. Service-a delivery of business value to a consumer by a provider (across organizational boundaries). "Service" may be used to describe both a type of value (e.g., a shoe repair service), and an instance of value delivered (e.g., my shoes, repaired). Provider-a business entity that offers a capability and accepts an obligation to deliver a service (a shoe repair service provider). Consumer-a business entity that defines a service requirement, i.e., defines the context for delivery of a service. Role(?)-Provider and consumer imply a relationship of two participants. There are more complex relationships involving multiple participants. There will always be consumer-provider relationships within a complex relationships where a consumer engages a provider, i.e., brings the provider into the relationship and defines the context. But when describing a complex relationship, the it is necessary to refer to the multiple participants and their roles in the relationship, i.e., the obligations they have accepted. In some cases multiple roles may be filled by the same business entity. Service unit-an organizational unit that is responsible for the capability that provides a service. A service unit may use other services to fulfill its obligations, but these are generally not visible to the service consumer. It is important to be able to talk about service units because a service oriented enterprise is composed of service units. Operation (?)-a service unit may accept a variety of request types or requests for "operations." It may have a request type for the offered service and adjunct operations regarding a potential or pending request. For example, it may offer to provide a quote, and it may offer to provide status on a pending request. These operations may also be described as "services," but they arise from a particular consumer-provider relationship, particularly those that are in reference to a pending request. A service unit may also offer different types of services that use the same capability, so retail sales may be a different type of service from wholesale. Port(?) There is also a need to refer to a point of contact for obtaining a service. IT people think of this as a port. It could be a URL or a physical business address. ---------------------------------------------------------- FL001: Model-Driven Implementation The SOA ontology says that it aims to be (potentially) a basis for model-driven implementation of an SOA. How shall this exactly be done? Are there several levels of the ontology defined in order to refine the ontology in several models or are you thinking about some automatical code generations (more general ontology at top level and an additional grounding to existing services lateron)? >>>> Subsequent Discussion The aim is that the ontology should potentially be a basis for model-driven implementation. We have not developed a formal process for using it for this purpose. I am aware of work that has been done to generate WSDL service definitions automatically from business domain ontologies. The SOA ontology could be used in conjunction with business-domain ontologies to do this consistently. Generatng full service implementations is much harder than generating the interface definitions and would need extensions to the ontology. We haven't explored this yet. Work in this area is much more advanced in the OMG. They do not use ontologies as such, but their approach does have some relation to ontologies. Exploring and developing this relation is probably the best way forward. ---------------------------------------------------------- FL002: IOPE In other ontologies for web services there is often the notion of input, output, preconditions and effects (IOPE). There are effects in the SOA ontology, but no preconditions defined on a service? Is this on purpose? >>>> Subsequent Discussion See the initial comment. We would prefer to link to other ontologies that have these concepts rather than incorporate them in ours. ---------------------------------------------------------- FL003: DEscription of Effects The effect is simply an OWL-DL-class. Are any languages envisioned for describing effects (such as KIF, SWRL, RuleML or R2ML)? - KIF and SWRL are e.g. used in OWL-S. ---------------------------------------------------------- FL004: Rules and Policies Rules and Policies: are there links or recommendations to other languages that allow the specification of Rules (SBVR, SWRL, URML, etc.) or Policies (KAOS, Rei, Ponder2, etc.)? ---------------------------------------------------------- FL005: Non-functional Service Properties Is there a way to specify non-functional properties of a service (Quality of service, costs, etc.)? Not only for software services, but also for other services this would be quite interesting (Joe's car wash does always cost $5, except on Sunday then it's $7) ---------------------------------------------------------- FL006: Contracts How is a contract detailed? Are there any mandatory properties that need to be described? (e.g. costs) ---------------------------------------------------------- FL007: Solutions Solutions: In the context of services one often talks about goals that need to be achieved by the composition of services. And this composition is then normally a possible solution. However, in your ontology I don't find any correspondence between solution and composition (or the notion of goal itself). >>>> Subsequent Discussion We don't have a notion of goal, but we do have a notion of requirement, and a solution is something that satisfies a requirement. We do, in section 4.8, define Orchestration and Choreography subclasses of the Composition class, to address two important kinds of service composition. The Solution and Composition classes are not disjoint, so a composition can be a solution. ---------------------------------------------------------- FL008: Composition Definition Are there constructs that define how a composition of services (in your terminology a system) shall be achieved? (sequences, alternative flows, etc.)? I didn't find any. >>>> Subsequent Discussion No, there are no such constructs. These are probably among the things that would need to be added if the ontology is to be used to drive full model-driven implementation. Again, though, we would prefer to link to another ontology (perhaps based on BPMN?) that has these constructs, if one exists. ---------------------------------------------------------- FL009: Requirements, Design and Implementation The part about requirements, design and implementation in my opinion is not that specific for an SOA. Are there thoughts to describe this in an own ontology (as e.g. the Software Process Engineering Metamodel, SPEM, simply focuses on these parts, too) and simply integrate this other ontology into the SOA ontology? >>>> Subsequent Discussion We would have liked to import these from another ontology, but did not identify an appropriate one, and needed these concepts to explain others in the ontology. I understand that SPEM provides a means of describing activities, and there is in fact work elsewhere in The Open Group to use SPEM to model the phases of the Architecture Development Method of The Open Group Architecture Framework (TOGAF). From the point of view of our ontology, we don't analyse these phases in the way that the SPEM work does - we simply classify them as instances of the Architecture Development Activity class. ---------------------------------------------------------- FL010: Messages and Message Types Concerning the messages and message types: how is the relationship thought to WSDL or SAWSDL? Are there already examples how WSDL (or better annotated WSDL like SAWSDL) can be combined with the SOA ontology? >>>> Subsequent Discussion My understanding is that OWL-S incorporates WSDL concepts. I would see defining the relationship with OWL-S as the way of connecting our ontology with WSDL (but more work is needed on this). ---------------------------------------------------------- FL011: Relationship to Business Process Modeling Standards How is the relationship to business process modeling standards such as BPMN? You mentioned that the SOA ontology related the Service to other areas such as business process modeling but not exactly how. >>>> Subsequent Discussion I believe that our concept of Activity corresponds closely to the BPMN concept of activity, and see BPMN as providing a detailed analysis of concepts related to activity that we don't cover. Again, more work is needed to explore this properly. ---------------------------------------------------------- FL012: Abstraction of "Anything" Figure 25: Architecture Building Block is an abstraction of Anything? How can the concept of "Anything" be abstracted? Probably the arrow might go the other direction? >>>> Subsequent Discussion We use "Anything" as shorthand for "an instance of the OWL Thing class" - ie, anything in the universe of discourse. We are not saying that the concept of "anything" can be abstracted. We are saying that an abstraction of anything in the universe of discourse can be an ABB. So if "car-wash machine" is something in the universe of discourse, then "abstraction of car-wash machine" can be an ABB. ---------------------------------------------------------- FL013: Architecture Development and Design How is the Architecture Development Activity linked to the Design? There is no connection in your specification, but probably it might be part of the design (as is the development of an architecture often during the design phase in software engineering) >>>> Subsequent Discussion The relation between architecture and design is somewhat difficult to capture. As you point out, we haven't tried. But we don't preclude a relation. An architecture cannot be a design (because Architecture is disjoint with Abstraction, of which Design is a subclass). But I dont think there is any reason why a design shouldn't be an ABB, for example, or why a Design Activity shouldn't be a component of an Architecture Development Activity. If someone comes up with a specific need to establish this connection, we might explore this further, but we wouldn't want to do so otherwise. ---------------------------------------------------------- FL014: Use UML for Diagrams A question not about the concepts in the SOA ontology: Why didn't you use UML class diagrams in your models? That would make it much easier (at least for software engineers) to understand what they are about... ---------------------------------------------------------- FL015: SAWSDL I am looking forward to some examples how the SOA ontology can be combined with OWL-S; but I think that the combination with SAWSDL is much more benefitial to explore (since SAWSDL is a W3C recommendation and OWL-S was just a submission and is not further developed anymore as far as I know). ---------------------------------------------------------- JE001: Nature of Services It is very important that we (the key Open Stds organizations of OASIS, OMG, and The Open Group) collectively harmonize on some of the core SOA concepts; otherwise, we will all be doing the practitioner and business stakeholder community at large a huge disservice. >>>> Subsequent Discussion I agree that we need compatibility. We should recognise, though, that different viewpoints often produce different definitions. For example, London can be defined, from a political point of view, as "the capital of the UK" and, from a geographical point of view, as "the lowest crossing point on the river Thames." Both definitions are equally valid, and equally useful (and the connection between them is interesting to historians). We shouldn't try to force everyone touse the same definition. ---------------------------------------------------------- JS001: Service as Logical Representation AA> ... how should one take this basic definition: "a service > is a logical representation of a repeatable business activity > that has a specified outcome." Why is its genus "a logical > representation"? If I need some service, I want somebody or something to do something. I don't want a statement in logic (unless my request happened to be for a copy of some formula). AA> ... Again, why is its differentia chosen as "a repeatable > business activity that has a specified outcome". Why must a service be repeatable? Many needs are unique. And why must it be a business activity? What does it mean for the outcome to be "specified"? Does that mean "specified in advance"? But what about emergency services that respond to unpredictable events? ---------------------------------------------------------- KL001: Distinguish Business Service from SOA Service I find it useful to differentiate between a business service and a SOA service. Business services are described in the more traditional sense of providing a business function, yes with predictable business outcomes, i.e. real world effects. A SOA service is an IT artifact that *may* be an effective way to realize that business function. Conversely, SOA will be inappropriate and have no role in certain business functions. ---------------------------------------------------------- KL002: Service as Logical Representation Whether the service itself is "a logical representation" or there SHOULD be a logical representation of a service is a point for discussion; I would lean more to the latter. The business service should indeed be repeatable because otherwise you appear to be dealing with randomness where you really want some certainty. If I bring my clothes to the cleaners, I expect my clothes to be returned clean, not someone else's clothes, not the clothes still soiled, not a pound of corned beef instead. ---------------------------------------------------------- NC001: Nature of Services I agree with you Ed, that there has been much "hype" over the promise of SOA enhancing business functions. But does hype necessarily mean untruth? Points of interest in your post: This is the hype version of SOA, whose purpose is to sell webservice implementations (read: "new software technology") to management, and allow a bunch of pundits to sell books and "newspapers". First of all, one important aspect of SOA can involve a review of the business process and reengineering the process itself. It is not have to be just about fielding a "new software technology" or changing the way that information is shared between systems using web services as opposed to the legacy point-to-point interfaces. This is another one of the positive attributes of web services altogether. SOA can finally address the need to truly integrate business functions with IT and create a potential for maximum reuse of IT assets in an organization -- those have been the largest, most difficult challenges in business over the last two decades from all the trade rags that I've read. Thus, the "hype" to business is to finally fix the disconnect between business functions and the IT center and to lower costs through potential reuse of IT assets. The services that we know how to implement with software, and the only ones that are really implemented, are all relatively simple technical services that are pure information technology. No doubt they are pure information technology at the interface level, but to say they are "relatively simple technical services" is, I don't believe, accurate. Just getting a simple web service to "work" is surely no big deal, however, the coordination of technologies necessary to field a working, discoverable, secure, manageable, and valuable implementation of web services for an organization is far from trivial. > A SOA service is an IT artifact that *may* be an effective way to > realize that business function. Specifically, when that function can be fulfilled solely by the communication of information. One might argue that many functions are fulfilled solely by the communication of information. However, other functions are also dependent upon, however not solely, by the communication of information. For instance, I place an order for a product on a web site. The business function of fulfilling an order is totally dependent upon receiving the details of where to ship what I've ordered. In fact, the process can go no further without my shipping address. Otherwise, the ordered items can be selected from the warehouse, packaged and staged for shipping, but without the destination address, the process is stopped dead in its tracks. I think the reason for the hype to management is because they won't "buy the technology" for technology's sake--just because it "promises" to improve IT-asset reuse or agility or flexibility-- the business execs have to see the business value, and without that tie from IT to business, too many organizations will never see the value at all. ---------------------------------------------------------- RS001: : Distinguish Business Service, Technical Service, and SOA Service SOA deals with all three at least, namely - Business - Information (applications and data) and Technical services to cater to the whole enterprise. The business services are catering to business components that can be grouped into business functions. Example of technical service is a web-service for message delivery or for notification or service for network related management, security services, etc. ---------------------------------------------------------- RS002: Nature of Services Ed 1. Regarding business Services in SOA, I am surprised to see your omission of Manufacturing, ERP, Supply and Value Chain related business services in vogue in Industry today that have emerged beyond what historically started as web services! 2. Even for financial sectors (Basel II) in many areas such as for insurance and loans, the business services are being implemented. 3. Yes there is some hype and the real danger is “spaghetti code” but business functions, business processes and business models as well as performance monitoring all benefit from business componentization and related services. 4. Information services will be highly importance for cross agency communication and citizen services in the Governments. 5. A comment on how manufacturing logistics and transportation costs are reduced by using (business) communications and information services and actual delivery of material at the point of use has a large information or business services component. In the days of no cell phones, one had to often trace a person by visiting or finding them if they were away from landlines thus cross service enterprises will continually increase use of business services for overall material cost reduction and for efficiencies in integration costs. ---------------------------------------------------------- RW001: Service as a Logical Representation John F. Sowa wrote: I endorse Azamat's questions: AA> ... how should one take this basic definition: "a service is a logical representation of a repeatable business activity that has a specified outcome." Why is its genus "a logical representation"? If I need some service, I want somebody or something to do something. I don't want a statement in logic (unless my request happened to be for a copy of some formula). AA> ... Again, why is its differentia chosen as "a repeatable business activity that has a specified outcome". Why must a service be repeatable? Many needs are unique. I would think that the meaning of repeatable is more along the lines of "If I order a Bud on Monday I get a Bud, if I go back to the bar on Tuesday and order a Coors, I get a Coors." rather than "If I order a Bud on Monday I get a Bud, if I go back to the bar on Tuesday and order a Coors, I get a Bud." The repeatability is that I get what I order, not that I always get the same thing or always get what everyone else orders. And why must it be a business activity? I am afraid that business will always get the attention. However, if someone could model the process by which women chose clothing in a store, men would value this much more than most of the business models produced. I am just not sure this is possible. A working model would be worthy of a Ph.D. in any number of disciplines and possibly a Nobel prize. There are other human/machine and machine/machine interactions that would be subject to modeling that would not be generally understood as business. Scientific instrumentation is a more serious non-business application that could be described in this way. What does it mean for the outcome to be "specified"? Does that mean "specified in advance"? But what about emergency services that respond to unpredictable events? They still should have a behaviour that is specified in advance. Specifying something in advance does not mean that all inputs are ignored. You still have to train firemen even though you are not sure if they will arrive at a drowning or an electrocution or a fire. Their services are describable in advance even if you do not know what is on fire. The inputs will be used to guide the process and it may take a very large specification in this case - most of which is not written. Their training and experience builds a model in their minds that they draw on. It could be documented with all of the possible input values identified and it could then be used to train new firemen. It would never be completely finished since new input values would always appear and have to be evaluated. If perfect understanding of all possible future inputs was a requirement for models, then we would never model anything of reasonable complexity. Sharma, Ravi wrote: Ron Just a short comment that behavior can also be extracted by examining data or other inputs such as decision and dwell time to accurately model the business process. In all the years I went shopping with my wife, I was never able to discern the pattern or come close to modeling even the smallest part of the process. Actually clothing stores would be most interested in capturing this customer experience as we did when I was at GM to capture the buying preferences for cars and even today surveys-analysts such as J D Powers are making hundreds of million dollars in revenue due to this data mining knowledge even if a-priori all inputs for the process or behavior are not known! I was thinking more about husbands than retailers, the retailer is only going to lose the sale. The downside is much more long lasting for husbands. I am not sure that men are any more rational but I bet it was easier for GM than it is for most husbands to determine buying preferences. ---------------------------------------------------------- ---------------------------------------------------------- Commenters AZ Azamat Abdoullaev EB Ed Barkmeyer EW Evan Wallace FC Fred Cummins FL Florian Lautenbacher JE Jeffrey Estefan JS John Sowa KL Ken Laskey RS Ravi Sharma RW Ron Wheeler ----------------------------------------------------------