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


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



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