Thank you, Rob, you gave me a few good ideas and just confirmed me in my
'opinion'.
Only one tip: try to look at the whole picture again considering that in SO
environment:
* there may be services without consumers,
* there may be consumers without services
* there may be data without services (corporate data under corporate
ontology; the data that may be used by future services or by existing services
in the future/new execution contexts)
* there may be service without data (but with the service semantics)
- Michael
________________________________
From: Rob Eamon <[email protected]>
To: [email protected]
Sent: Monday, April 20, 2009 4:35:28 PM
Subject: [service-orientated-architecture] Re: Joe on Microsoft's combination
of SOA & Storage
--- In service-orientated- architecture@ yahoogroups. com, Michael Poulin
<m3pou...@.. .> wrote:
>
> It seems coping questions is easier than inserting answers...
Posing questions is a technique to encourage discussion. I'm certain you don't
feel I'm lacking in opinions of how some things are to be approached. :-)
>
> >This may be where we diverge. In an SO approach, wouldn't the
> > business data model be the model presented by the service
> > interfaces? I think a model at a lower level would be considered
> >data oriented rather than service oriented.
>
> I do not think so: service interface represents only 'exchange'
> data while the business meta-data model may be much richer than
> particular interface allows.
Sure. But it is the collective of all interfaces of all services that form the
model from a consumer POV. A particular operation within a particular interface
may provide just a subset but some operation somewhere is likely to (should?)
expose the additional elements.
If no consumer can use a particular data element (i.e. it is not exposed via
any operation/interface ) then from the consumer view it does not exist.
I understand that a service will have some internal data elements to help
manage its work. That's to be expected. But that will be (should be?) fairly
minimal and from a consumer POV completely uninteresting.
> Plus, a business service may have
> several interfaces, even several Web Service interfaces - this
> helps to distinguish between service's business meta-data model
> and 'exchange' data.
I'm back to the collective point above. The data model at the service level is
represented by the all the operations/interfac es exposed by the services. If a
data element isn't exposed then it effectively does not exist (consumer POV).
> Business data model is always data-oriented,
> IMO.
Absolutely. My point about being data-oriented or entity-oriented is the
scope/focus in which those models are defined. In an SO approach the data model
should be defined within the context of services. That context guides and
constrains the definition. It seems to me that articles/blogs about data
services, MDM, enterprise data models, etc. tend to focus on identifying/
sourcing data first, place service-wrappers around them second. IMO that's
backwards for an SO approach.
>
> >Wouldn't that be an entity-oriented approach? <
>
> I meant hear that each service may have its own view on shared
> model of data and interpret the model is its own way if needed.
Right. I think I understood your meaning. Where does the shared model come
from? What is the context of its definition? If separate and distinct from
defining services, then it is probably a data/entity- oriented approach rather
than an SO approach. Services drive the data model.
In a perfect/ideal world, just one service would be responsible for a
particular set of data within that shared data model. So what is shared? The
data model of the interfaces of that service.
>
> >Here's a different view for consideration. An autonomous business
> > service uses its own data and data obtained via other services
> > (not a a lower-layer data "service") to provide the functionality
> > that its contract stipulates. If multiple services are trying to
> > CRUD the same set of data, would that indicate some sort of
> >service design/granularity issue?
>
> My understanding of 'autonomous' assumes that such business service
> does not need any other business services to provide its business
> functionality.
I don't agree here. How a service provides its capability is immaterial.
Whether the service uses 15 traditional applications or a handful of services
to do the work is an implementation detail. From a consumer POV we have no idea
how the service does its work.
Over the life of service, it might change its implementation many times. As
long as the service contract and interfaces remain intact then the service can
change the implementation and the components it depends upon as it wishes. This
is principle 1 of SO: service interface is separate from service implementation.
> This does not preclude the service from using utility services to
> obtain data.
I prefer the term utility components over utility services to avoid confusion.
> However, I would restrict any business service from direct assess
> to a legacy app or data source.
Agreed. If the business service is using the legacy app for its implementation
then the access to that legace app and the legacy data source should be through
the legacy app's public interfaces, whatever they may be. It should not read
the DB directly. This is not an SO concern but simply the generally decoupling
principle to allow more manageable modifications to both the service and the
legacy app.
> I still think that each service may
> have its own view on the same data.
I question this. This makes me suspect the service segmentation.
> For example, I had 3 services working with credit risk
> transactions; the unified transaction model defined 42 fields while
> services needed 5, 3 and 11 fields only.
Might these have been better placed as operations within a single service? In
other words, you didn't have 3 different credit risk services, you had 1 credit
risk service with multiple operations. One credit service that defined 42 data
elements which were exposed in whole or in part by the service operations.
This may seem pedantic but I think the distinction is valuable. The credit risk
data/data model wasn't shared amongst services, but managed by a single
service, manipulated by various operations within that service.
Thoughts?
-Rob
