It looks, Lawrence, we have conceptually different definition of the business service and this scares me.
To me a service becomes a business service not through an association but through core of the service realising a Business service, Business function, Business feature, or Business process. You may have a Business feature which is not associated with any particular Business function at the moment but tomorrow it may work for several different Business functions. I do not accept (even for completeness or elegance purposes) a definition of, e.g., a shovel as a financial tool only because a banker use it in his garden. I am also afraid that definition of a service via association may be very confusing: the same service may be associated with different in their nature things - what such service is? Please, please, rethink "We didn't think the meta model should be overly draconian about what's mandatory, in order to accommodate different opinions or development processes. " Naming things by what they are is not 'draconian' but realistic, otherwise we would be doing politic, not technology. About different opinions, why we so "politically correct" about this? What do you think, really think about an opinion that considers a submarine as an airplane (both of them can swim and fly)? We will not be able to move forward if we cannot agree and common opinion on the fundamental things. If you want an example, here you are. Assume we have a business service than calculates credit risk exposure. We also need some stored data to be delivered for this calculation. This data is interpreted in business semantics, i.e. it is the business data. If we use a Web Service to deliver this data to our calculation engine, may we call this Web Service a business service? Remember, business service is a product which has to be treated as a product with its own business functionality and expected business Real World Effect. Isn't mentioned Web Service is just an extension of database driver (in 98%)? What business functionality it provides? - None. Data store is not a business entity. Such Web Service may be considered and technical infrastructural service and only in the case if database driver is considered as a service. I've got the point of 'a canonical Business Type Model'. However, I stack at the "model is then used to identify core business services that manage the data for these business types. " To me, business services do not manage any data, they manage functions that use data represented in accordance to the business meta-data definition. Look, if a name of a database table filed is 'price', it does not mean PRICE in all cases: some applications/services/business logic can use the value in the 'price' field as a COST, which is not exactly the same thing, or as a FEE... The meaning of the field is assigned to it not in the database but in the meta-data of each service. I would understand following model: a business service needs a business data; the business service involves data service and represents its business meta-data model; the data service knows how the meta-data of particular business service is mapped on the physical data store schema and which values have to be returned. This allows me having a notion of, e.g., Client in different services, where the Client is defined by different meta-models, for example, one meta-model contains 3 fields and another meta-model contains 5 field. The data service knows how 3- and 5-field models are mapped onto the 'canonical Business Type Model', defined in the data store, and extracts corresponding fields for both services using the same data source. I think that my approach is service-oriented, at least. - Michael ________________________________ From: "[email protected]" <[email protected]> To: [email protected] Sent: Thursday, April 9, 2009 9:32:00 AM Subject: [service-orientated-architecture] Re: den Haan explains SCA --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3pou...@.. .> wrote: > > Lawrence, you ared doing a wonderful work! Thanks! :-) > > I have three questions to your post: > > > 1) why a Business Service is a Business Service if it has zero business model > elements, i.e. has no Business Service Subjects (in your definition)? Good question. I went back to my colleagues and asked why did we do that? Was it a completeness issue, i.e. you could add a business service to the model without knowing just yet what business subject it was related to? This would be essential behavior for tools. Or was it actually a rule? i.e. business services do not have to be related to business subjects. In which case, why is it a business service? The answer was a bit of both... primarily we felt we didn't have all the possible business subjects identified, so wanted to leave that open. Also, there may be services that provide "business utilities" that might be hard to classify against the business subjects you might typically find in business models. We didn't think the meta model should be overly draconian about what's mandatory, in order to accommodate different opinions or development processes. So a particular methodology adopted by an organization might want to make something mandatory, when its optional in our meta model. or vice versa... > > 2) in "if a Service doesn't have these associations to objects in the > business model, then it isn't a business service" - you, probably meant > 'subjects' rather than 'objects', didn't you? > Yes. I meant subjects > 3) what does mean "Business Types"? > our SAE approach suggests organizations build a canonical Business Type Model "A model of all the data that the Solution software needs to access and possibly update. This may be in the form of a detailed Business Type Model, which defines all the attributes, associations and constraints of all business types that the Solution software will need to process." The model is built from these constructs: 1. Business Types (a.k.a. Entity Types, Entities, Conceptual Classes) 2. Attributes 3. Associations 4. Generalizations (a.k.a. inheritance) 5. Invariants (a.k.a. Constraints or Integrity Conditions). The model is then used to identify core business services that manage the data for these business types. We have specific techniques as to how to perform the identification - it isn't a simple one-to-one mapping. regards Lawrence
