F) Addressable - A service should be able to be uniquely identified
in a network
I think JP's point is that each service *instance* must be uniquely identified, and the logical identifier for a service instance would be the URL of it's access point.The problem with this identity mechanism is that it really identifies the service endpoint rather than the service, and a service might expose multiple endpoints, so how do you identify the collective service and distinguish it from its various endpoints?
I raised an issue to the W3C WSDL 2.0 committee that I thought it was necessary to define a URI to represent a service. They replied that the WSDL document containing the <service> definition identified the service. I don't like that solution, either, because that URL of the WSDL document identifies the service description, not the service. And to make matters worse, in WSDL 2.0, a WSDL document constrains a service to a single interface, and from my perspective, a service is likely to have at least three interfaces: functional, management, and metadata. I'm still unsatisfied with the response I'm getting from the W3C WSDL team.
In any case, based on our current standards, we don't have a mechanism to uniquely name a service. And as far as I am aware, no one in the standards community is considering this as an issue that needs resolution. Perhaps we can draw up some use cases that clearly present the need to have a way to represent and discover service identity.
I can be much more effective working with W3C if I can present them with use cases.
Note that there's a difference between identity and type. There's also a difference between identity and identical. My interpretation of "identical" means that idenitical services must produce identical results and therefore are completely interchangeable. But the two services each should have a unique identity (unless they are in fact different endpoints of the same service).
Anne
On 11/6/05, Jan Algermissen <[EMAIL PROTECTED]> wrote:
Question:
what constitutes identity in SOA? When can a client consider two
services to be identical?
- when they have the same address?
- when they have the same type (as in myService ---isInstanceOf--->
ShoeOrderProcessor)?
- when they have the same description?
- unspecified; every SOA style software system must define identity
for itself
Jan
On Nov 6, 2005, at 2:21 AM, JP Morgenthal wrote:
>
> Here's what I propose:
>
> A) Loose-coupling - every service is atomic, self-describing,
> accessible, declarative, stateless and composite
> B) Contracted - All services in an SOA are represented by a contract
> that describes its inputs, outputs, access policies, QoS
> requirements and
> error handling procedures
> C) Manageable - all services can be individually managed or managed
> as a group
> D) Versioned - multiple versions of the same service should be able
> to co-exist to maintain backward compatibility in a changing
> environment
> E) Discoverable - services should be able to be discoverable at time
> of execution.
> F) Addressable - A service should be able to be uniquely identified
> in a network
> G) Distributed - Services in an SOA are separated by geographic and
> machine boundaries and, therefore, must be good netizen
> applications. That
> is, they must be developed with the ability to recover from loss of
> communications.
> H) Point-to-Point - At any point in time one consumer uses one and
> only one producer
>
> ------------------------------------
> Avorcor, Inc.
> JP Morgenthal
> Managing Partner
> [EMAIL PROTECTED]
> 12110 Sunset Hills Road, Suite 450
> Reston, VA 20190
> tel: (703) 648-1520
> fax: (703) 648-1523
> mobile: (703) 554-5301
> ------------------------------------
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf
> Of Jan
> Algermissen
> Sent: Saturday, November 05, 2005 9:03 AM
> To: [email protected]
> Subject: Re: [service-orientated-architecture] Re: request for
> pointers to
> relevant information/documentation about SOA/SOC
>
>
>>>
>>> documents/publications related to SOA, starting from the basic
>>> principles to more complicated stuff.
>
> I know this has propably been stressed too much, but simply cannot
> resist :o)
>
>
>
> What are the basic principles of SOA?
>
> <duck/>
>
> Jan
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor --------------------
> ~-->
> Get Bzzzy! (real tools to help you find a job). Welcome to the
> Sweet Life.
> http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/NhFolB/TM
> --------------------------------------------------------------------
> ~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
________________________________________________________________________
_______________
Jan Algermissen, Consultant & Programmer
http://jalgermissen.com
Tugboat Consulting, 'Applying Web technology to enterprise IT'
http://www.tugboat.de
------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
SPONSORED LINKS
| Service-oriented architecture | Computer monitoring software | Computer and internet software |
| Free computer monitoring software |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
