Udi, based on OASIS SOA RM/RA, here are my answers: Is it the same service interface if it is offered over a "real time" pipe or as a nightly batch?
- Probably, they are different interfaces, but not necessary How about - is it the same service? - it may be; you do not specify any other requirements to conclude it may not be the same services Does this make SLAs part of the service, or its interface? - neither-nor, the SLA is a part of the Service Contract (but also may be a part of Service Description if service behavior does not depend on consumer selection of service features and execution context). Certainly, SLA has to consider characteristics of the service interface but not only; service body/implementation capabilities play significant role in the SLA. That is, I associate SLA with the service in particular execution context and keep interface a part of it. Might the SLA be part of the difference between a contract and an interface? - based on what I said before, this question is not clear to me; Service Contract definitely includes service interfaces and other things in addition to SLA Does any of the above change when the consumer is a subscriber to events the service publishes? - good question! Conceptually, I do not see changes. However, in details, there are some that depend on the mechanism of publishing and subscription: 1) if publisher and subscriber interact directly with each other (we see this in Object's wait() and thread awakening, for example), the Service Contract stays mostly the same as for synchronous p2p service-consumer case while SLA may have a bit different content, different characteristics; 2) if event is delivered to the point of publishing/subscription provided by an intermediary, it may be a bit different story. If this intermediary is of MOM type, we may adopt the concept of 'unawareness' between publisher and subscriber. I mean, it is a legitimate cases where a subscriber does not know provider at all and does not have any agreements with it. The argument that publisher and subscriber have to agree, at least, on the message semantics (I mean the message that represents event in the distribution) is not mandatory because this agreement may be implicit, based on common knowledge. For example, a message may carry an XML document with a tag <social-security-number> or <national-insurance-number> (in the UK); the value is the actual number and both publisher and subscriber know what this means. The difference here is in that the service consumer (subscriber) now deals with the intermediary. The consumer may not care how the messages are appear in the intermediary, i.e. where from if they are authentically signed. That is, the consumer has to set an agreement with the intermediary instead of publisher. It may be very similar Service Contract with appropriate SAL, i.e. conceptually it is same case but for different participants. If a service/publisher does not want to delegate its relationships with the consumers to the intermediary, the service/publisher has to encapsulate all effects caused by the intermediary (additional delays, repeatable sending, etc.) into the Service Description and make them available in the Service Contract. That is, the intermediary has to become transparent or invisible to the consumer/subscriber. Actually, this is major problem when we talk about ESB and SO environment. - Michael ________________________________ From: Udi Dahan <[email protected]> To: [email protected] Sent: Sunday, March 22, 2009 12:07:11 PM Subject: RE: [service-orientated-architecture] Re: Joe on SOA without service-enabled apps 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:service-orientated- architecture@ yahoogroups. com [mailto:service- orientated- architecture@ yahoogroups. com] On Behalf Of Michael Poulin Sent: Sunday, March 22, 2009 12:37 PM To: service-orientated- architecture@ yahoogroups. com 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 <rea...@cableone. net> To: service-orientated- architecture@ yahoogroups. com 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, 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
