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.

***** 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.

***** 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.

***** 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.

***** Subsequent Discussion

See the initial comment. We would prefer to link to other ontologies that have these concepts rather than incorporate them in ours.

***** 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.

***** 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.

***** 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.

***** 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).

***** 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.

***** 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.

***** 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.

***** 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 to use the same definition.

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?

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.

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.

Again, various "Kinds of Actor" are used (e.g., Section 2.6) before the categories of "Kind of Actors" are defined.

1. The ontology decomposes Actor into only providers and consumers in Section 2. This does not allow room for other categories of participating actors.

   This is not the case. The ontology does not imply an exclusive decomposition of actors into providers and consumers. This is stated explicitly in section 2.3.2.

2. Stakeholder is an important concept that should be included.

   It is certainly an important concept for architecture in general, but is not particularly important for SOA as compared with other architecture styles. We therefore would prefer to reference a general architectural definition, rather than including the concept in the ontology. There is in fact an excellent and definition in IEEE 1471, a standard that is widely respected in the architecture community. It was therefore not included. However, this decision should be reviewed in the light of the comment that the concept is needed in order to treat governance properly.

3. Services should be considered as kinds of actor.

    

   In earlier versions of the ontology, the Service and Actor classes were not disjoint. The decision to make them disjoint resulted in greatly improved conceptual clarity. This is a fundamental topic that probably requires more discussion with other bodies. We should have that discussion and, in doing so, make the case for Service and Actor to be considered as distinct concepts.

For example, The OASIS SOA Reference Model defines Service as: "A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description." The OG ontology defines Services as "The class Service is defined as a subclass of the Activity class", which, in part, is caused by the confusion between the business and architectural perspectives of a service. Since this is the basis for the rest of the Open Group Ontology, the concept of the definition of the parent class "Activity". The OG Ontology defines "Activity" in a footnote as "the concept of activity described in this ontology is a very broad one – it is that of a system of actions that are performed by actors in response to events." This definition for "Activity" is weakened, not strengthened, by this caveat.

This area clearly needs more discussion to establish whether the OASIS and Open Group uses of the term "service" are consistent and to explore the relation between them.

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.

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.

Rex Brooks
Robert Ellinger
David Ellis
Jeff Estefan
Ken Laskey
Frank McCabe
Danny Thornton