Some questions to think about:
Is it the same service interface if it is offered over a "real time" pipe or as a nightly batch? How about - is it the same service? Does this make SLAs part of the service, or its interface? Might the SLA be part of the difference between a contract and an interface? Does any of the above change when the consumer is a subscriber to events the service publishes? Thoughts? -- Udi Dahan From: [email protected] [mailto:[email protected]] On Behalf Of Michael Poulin Sent: Sunday, March 22, 2009 12:37 PM To: [email protected] Subject: Re: [service-orientated-architecture] Re: Joe on SOA without service-enabled apps 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. >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. - Michael _____ From: Rob Eamon <[email protected]> To: [email protected] Sent: Saturday, March 21, 2009 8:18:24 PM Subject: [service-orientated-architecture] Re: Joe on SOA without service-enabled apps Right. Service is more than just interface. But not much more. -Rob --- In service-orientated- architecture@ yahoogroups. com <mailto:service-orientated-architecture%40yahoogroups.com> , Michael Poulin <m3pou...@.. .> wrote: > > Believe it or not, Rob, I agree with you again: "wrapping a CICS > app with a service wrapper is exactly the same as defining the > service defintion first and then creating the service > implementation (which can use *any* technology or architecture) > behind it." The key word here is "wrapping a CICS app with a > service", not with a service interface as many have read it based > on the similarity between words Service and Web Service (which is > the interface) > > - Michael
<<image001.jpg>>
<<image002.jpg>>
