Jeff, Frank, Everyone,
My $.02:
I also like the wiki definition of "one" the specific kinds of
interface I think we need to specify in the RA.
I think we do need the "constraints" Frank is willing to accept, and
those should include the two examples plus a verbal description of
what implementation-independent components are required, e.g. the
ability to provide bindings, not the particular binding mechanisms. I
think the examples should be included in the RA. I also think that
the ability to provide bindings for the appropriate MEPs should be
highlighted in the examples.
Cheers,
Rex
At 4:27 PM -0700 10/26/07, Francis McCabe wrote:
>Jeff
> That wiki defn is quite good!
>
> The WSA defn includes 'all that you need' in order to 'make the
>service work'. I think that that sentiment should be in our
>definition also. That would mean that it would include the format of
>messages.
>
> You are also right about the interface being a subset of the
>information and process model. I can see that there may be aspects
>of both that are not needed to interact with the service; however, I
>would also be quite OK with the idea of *constraining* information
>and process models so that it *only* had information that was
>relevant to the potential users of the service. This is especially
>so if you include in users the people who may have to manage and
>deploy the service.
>
>Frank
>
>
>
>
>On Oct 26, 2007, at 4: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:
>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>---------------------------------------------------------------------
>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:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670
