OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[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. 

While this discussion refers to a standard referenceable syntax for service descriptions, it is not specified how the consumer accesses the interface definition nor how the service itself is accessed.  However, it is assumed that for a service to be usable, its interface MUST be represented in a format that allows interpretation of the interface information by its consumers.

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:

Folks,

I'm in the process of crafting a UML component diagram for the Service Description artifact, but we need to nail down the notion of Service Interface before I proceed.  I don't want to indulge into endless debate here, I just want to know what is the minimum set of service implementation-independent things needed in order for a consumer agent to communicate with a provider agent (i.e., service).

I happen to like Wikipedia's general definition of interface which states that "An interface defines the communication boundary between two entities, such as a piece of software, a hardware device, or a user."  Of course for the RA, we're talking about software interfaces that exist between separate software components that provide a mechanism by which the components communicate (consumer agents and provider agents/services) and not user interfaces per se.  We should perhaps extend that notion to physical interfaces as well, i.e., interfaces between hardware components because there is an evolving world of things like XML gateways out there.

The WSA defines a service interface as follows:  "A service interface is the abstract boundary that a service exposes. It defines the types of messages and the message exchange patterns that are involved in interacting with the service, together with any conditions implied by those messages."  In terms of relationships to other elements, it goes on to say a service interface defines "the messages relevant to the service."  The explanation states "A service interface defines the different types of messages that a service sends and receives, along with the message exchange patterns that may be used."

So is only a subset of the Information Model and Behavior Model enough, i.e., messages and MEPs?  What about service bindings (), endpoints, operations, faults, etc.  Do they have a role in the service interface.  In other words, are these examples of service implementation-independent things that are necessary the consumer agent to communicate with the provider agent/service?  In terms of the RM and RA, are there elements of Service Reachability at play?

Whatever we agree on, we should be able to map to concrete examples (just to check our own sanity of course and not to include in the actual RA spec.) say one from the Web services world using WSDL 1.x and 2.0, and perhaps one from the CORBA IDL world.  Note that in the WSDL 2.0 world, the service interface defines what abstract "functionality" a Web service provides and the binding describes how to access the service.   In the RM and RA, we currently model Service Functionality separate from Service Interface.

Interested in your thoughts.  Pragmatic ones, please!

Cheers...

- Jeff E., JPL




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:

-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305      phone: 703-983-7934
7151 Colshire Drive                         fax:       703-983-1379
McLean VA 22102-7508




smime.p7s



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]