--- In [email protected], Michael Poulin <m3pou...@...> wrote: > > Rob, is this an organic mismatch? > > When I look at Service Description, service interfaces represent > approximately 1/5 of information about the service. So, how much > in 'not much more'. We, probably, have to return to Steve's T- > service and B-service but mean Technology and Business views on the > service rather than pure business service and technology service. > > In my opinion, a B-service (view) is much closer to the A > Consumer's view on the service. Why? Because consumer has to 1) > find the service based on its functionality; 2) valuate promised > RWE; 3) make a decision that found service suites consumer's needs; > 4) and only then consider available communication means including > interfaces; 5) make an agreement with the service provider and form > a Service Contract. All these are IT activities.
Steps 1, 2 and 3 take how long to evaluate. About 15 minutes? Tops? Okay, that's an extreme statement but seriously the work in making a service discoverable and describing what it does is pretty minor in comparison to defining the service interfaces and its implementation. Even item 5 is pretty minor (though important from an management perspective) in the scheme of things. That's why I said "not much more." > > From the architecture perspective, interface is also not the only > one thing to consider but this depends on the concrete > architectural goals. For example, an architect may be very much > concern about 1) flexibility - ability to modify architecture in > response to the changes in business needs; 2) high availability; 3) > security; 4) massive data transfer; 5) transactional behavior; 6) > vertical scalability , etc. All these contribute into the interface > definition but interface itself is nothing more than a reflector of > all listed concerns and from only one perspective - communication. > The service body is responsible for performing in accordance with > all these 'ilities'. We do not care how it does this work, we care > what it does, e.g., does it do long-running transactions or not. > > I think I've illustrated my point. Yes, a great set of -ilities on which we agree are great items for consideration when defining an architecture. All of these should be addressed in some way for a service definition, even if to say, for example, that "massive data transfer is not a concern at this time." I agree as well that the service body/implementation must support the -ilities that the service description specifies. In rereading your original comment to AW: "an access to a business functionality does not make it a service; it is just one of many access channels: an interface does not change the core of the things." I read more into that comment than was there. I agree that just adding an interface is not sufficient to expose a particular capability as a service. Where we may diverge is in how much effort there is to making it a "proper" service. IMO, there isn't much more to it. Making it discoverable, describing its behavior, listing its operations and interfaces, etc. can be accomplished in any number of ways--none of which are overly difficult. The hard part is identifying the right granularity for the service and defining loosely-coupled interfaces to access the operations. The service implementation needs to support the -ilities but those aren't always necessarily "high-end" measures (e.g. a 2 hour outage in the middle of the night for whatever reason may be perfectly acceptable). "Wrapping an application" is probably a misnomer. Define a service. Create the implementation. The implementation might be accomplished with existing components--as long as they provide the functions and -ilities of the service definition, however it is defined. -Rob
