[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] The Service Interface
I'm late to this thread but other elements of life had precedent. Interface = communication boundary is fine but then the question becomes what needs to be defined to "effectively" communicate. For an electrical outlet, we usually think of the shape of the plug but you also have to know something about the voltage because merely providing a physical adapter could lead to fried electronics. When I go to a hotel and use their network, what is the interface? There is the physical interface again, either wire or wireless, but there is also the click-through agreement. As a knowledgeable consumer, are those conditions part of the interface? We separated functionality from the interface in the RM because the assumption was functionality would tell you what would happen and the interface would tell you how. The WSDL 2.0 serialization combining of those does not preclude separation in the more abstract RA. It might, however, give pause to whether combining them is a good idea. As for WSA talking to "different types of messages", that opens up a whole array of questions about whether one creates a taxonomy of messages to reference or whether one provides a list of message attributes without formally constraining which set of attributes/attribute values correspond to which types. As I write this, I wonder again what is interface vs. what is a description of the interface? Is there a bare minimum to be specified that we would call the interface and everything else is commentary? (For religious/philosophical reference, see the Hillel and Shammai section of http://www.jewfaq.org/sages.htm.) I believe that is the question Jeff is asking. A couple selections from the RM may be worth considering (or disagreeing with) 1. However, SOA does not itself address all the concepts associated with ownership, ownership domains and actions communicated between legal peers. To fully account for concepts such as trust, business transactions, authority, delegation and so on – additional conceptual frameworks and architectural elements are required. Within the context of SOA, these are likely to be represented and referenced within service descriptions and service interfaces. The presence of service descriptions and service interfaces provides a ready location for including such references and thus facilitates reuse of externally developed frameworks and interoperability among systems availing themselves of this reuse. 2. A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. 3. A service is accessed by means of a service interface (see Section 3.3.1.4), where the interface comprises the specifics of how to access the underlying capabilities. 4. A service is opaque in that its implementation is typically hidden from the service consumer except for (1) the information and behavior models exposed through the service interface and (2) the information required by service consumers to determine whether a given service is appropriate for their needs. 5. Specific domain semantics are beyond the scope of this reference model; but there is a requirement that the service interface enable providers and consumers to identify unambiguously those definitions that are relevant to their respective domains. 6. The financial institution, as the underlying capability, does not have these limits but the service interface as exposed to its customers does, consistent with its assumption of the needs of the intended user. 7. The service interface is the means for interacting with a service. It includes the specific protocols, commands, and information exchange by which actions are initiated that result in the real world effects as specified through the service functionality portion of the service description. The specifics of the interface SHOULD be syntactically represented in a standard referenceable format. These prescribe what information needs to be provided to the service in order to access its capabilities and interpret responses. This is often referred to as the service’s information model, see Section 3.2.2.1. It should be noted that the particulars of the interface format are beyond the scope of the reference model. However, the existence of interfaces and accessible descriptions of those interfaces are fundamental to the SOA concept. So, I would say the description of the service interface MUST include all information necessary for the consumer to interact with the service. It does not include functionality, policies, SLAs, or any such because while these are vital to decide whether to use the service, these are not needed once the decision is made. Semantics are, however, required because I do not include sending gibberish in the message as adequate for interaction. I think this interpretation also requires all of the information and behavior models because I think you need those to carry out the interaction. Just a first pass at this. I'm sure I'll hear other opinions. I look forward to it :-) Ken On Oct 26, 2007, at 7:02 PM, Jeffrey A. Estefan wrote:
----------------------------------------------------------------------------- Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7151 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]