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


Title: RE: [soa-rm-ra] The Service Interface

This means we better define relationships between EDA and SOA for the sake of RA.

I do not see how an interface can deal with an orchestration but service description certainly can (it the orchestration provides any business value a service consumer might need to be aware of).

- Michael


Important: Fidelity Investments International (Reg. No.1448245), Fidelity Investment Services Limited (Reg. No. 2016555), Fidelity Pensions Management (Reg. No. 2015142) and Financial Administration Services Limited (Reg. No. 1629709, a Fidelity Group company) are all registered in England and Wales, are authorised and regulated in the UK by the Financial Services Authority and have their registered offices at Oakhill House, 130 Tonbridge Road, Hildenborough, Tonbridge, Kent TN11 9DZ. Tel 01732 361144. Fidelity only gives information on products and does not give investment advice to private clients based on individual circumstances. Any comments or statements made are not necessarily those of Fidelity. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer. All e-mails sent from or to Fidelity may be subject to our monitoring procedures. Direct link to Fidelity's website - http://www.fidelity-international.com/world/index.html

-----Original Message-----
From: Danny Thornton [mailto:danny_thornton2@yahoo.com]
Sent: 27 October 2007 03:43
To: Rex Brooks; Francis McCabe; Jeffrey A. Estefan
Cc: soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] The Service Interface

I like the previous comments about service interface.
However, if we drop choreography and orchestration
from the service interface, are we going to imply or
specifically state that choreography and orchestration
artifacts are unrelated to service description?  We
could state something like choreography and
orchestration artifacts are the result of processes
that do not relate to the creation and use of service
description.

If we do tie choreography and orchestration to service
description, they are most closely related to the
process model of the service interface.

Danny

--- Rex Brooks <rexb@starbourne.com> wrote:

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


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

---------------------------------------------------------------------
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]