Hello Gentlemen,
I apologise for not being able to participate - the problem had appeared at the last moment...
Thanks to Rex, I can partially restore your discussion and have a couple of questions and comments.
Q1 re "we don’t have a suitable metric to measure such granularity": why do we need to know the granularity of the services? What business or technology problem such knowledge is supposed to resolve?
Comment: I'd like to reiterate on the absence of the granularity scale common for the consumer and the service/provider because they have a) different objectives for the same service; b) service provider does not know objectives of the individual consumer; c) consumer can use the service in the way that the provider does not and /or cannot anticipate.
Q2 re "if we need to consider service description as a part of the granularity of the service interface": does this mean considering service description as a part of granularity topic of the service interface?
Comment: my answer is YES because service description enumerates service's interfaces
Comments re "what constitutes coarse or fine grained granularity with regard to the service interface." Before answering this question, IMO, it is necessary to answer a question how we degine a service interface. Particularly, in different time this definition included both end-point informational/behavioural models AND message load while in other times the message load (including its content meta-data/schema) was excluded. This was based on the technology that allowed to modify the meta-data/schema of the message separately and independently from the end-point informational/behavioural models. For example, using a Web Services as an interface, the WSDL schema allows to define the schemas for the message load via importing from some places that might be under different ownership and managment than the Web Service itself. The same relates to REST: its URL can point to the resopurce of data or to the
meta-data/schema (or another URL) defining the resource.
Comment re "if one would maintain an endpoint for each subfunction (separate service)?" In SO Ecosystem, to my knowledge, we do not have sub-functions as a type of a function; a "sub-" or "super-function" is an attribute of the relationships set by the user of these functions, e.g. composing provider. The same relates to the services. Each service may have its personal owner, provider, steward who maintians the service's interfaces including thier end-points. As I said above, a concept of interface has to be finalised to answer the question whether the message's meta-model should be owned by the interfaces/service owner or may be owned.
Comment re "each URL would need to be maintained, but asked if it then became a new separate service if new notations are made to the end of the URL, e.g. adding a new medication to a list of medications". YES to "each URL would need to be maintained". Based on my understanding of SO Ecosystem and the role of service description, URL does not represent a service but only its particular interface and/or end-point. A URL may be appended with whatever new notation with may point to another end-point of the same service or to the same one if this notation is just an alias. In the REST, to my knowledge, there are the rules that define the URL construction and, as I remember (may be mistakenly) a new appended notataion defines a new interface to the same resource (the same as an new end-point).
Comment re ": A URL identifies a resource and HTTP methods may be used to act on that resource. Is each act on each URL a separate service?" My answer is NO. This question deliberately or accidentally mixes interfaces with services. I think this happens because of inaccurate _expression_ "HTTP methods may be used to act on": no HTTP methods can act on - they can only point to or instruct the real Actor (the services) to act on the resource. As we know, a service is defined via its business functionality and the RWE while the services can have as many different interfaces as it needs. URL is an interface pointer and nothing more. As I mentioned earlier, a message exchnaged via an interface may have its meta-model defined separately. This definition may contain a varaety of commands in different combination that the service is instructed (by the consumer) to perform. The same mechanism of Command Pattern may be realised via adjusting the URL.
Comment re "What would it mean in terms of a mandate (or even a willing intent) to develop and maintain a service description for each service?" As I mentioned, we have 1 service -> Multiple interfaces -> Multiple message load schemas. The number of service descriptions = the number of services (not its interfaces). The power of separation between the interface signature and the message load schemas is in that the interface signature must be shared with the consumer and any changes in the signature cause related changes in all exesting consumer's connectors while a changes in the message load schemas impact only interested consumers (all elements of the message load may be made optinoal regardless how granular they are. In other words, the less granulat the the interface signature is, the more 'reliable' the service/provider appears to tis customers (becuase changes in the coarse-granular signature are rare and infrequently impact consumers = high usability of the service). Ideally, the service interfaces have to have only 1 operation/end-point for all actions/commands communicated to the service via this interface; a varaety of interfaces in this case depends not on the granularity but on the communication channel and regional/cultural specifics of the consumer base.
Comment re "Now consider a service that has a functionality that can be applied to many resources. ... . What does this say about the interface to such a service?" A service functionality related to many resouirces is a regular case for services (not for the interfaces). Services shielf consumers from the knowledge about these resources, i.e. service describes only WHAT it does and delivers, not HOW (if we exclude the applied policies from this discusstion). Again, the interfaces of the service are defined no based on utilised resources or capabilties;p the interfaces are designed based on the needs of the service and anticipated needs of the consumers. For example, a Local Weather service working in/for one Zip Code does not need any information from the consumers to pass through its interfaces except the consumer's identity (to link the request to the existing consumer profile and charge this consumer for the service).
Comment re "we need to understand how to parameterize the interface to be effective." I think this is done many years ago. The parameterization the interface must be adequate to the communiation means (channels) used to involke this interface. If an interface is a Web Service, we need 2 things: the WSDL (for the logical and physiscal interface signature and binding to the communication prorocol for the end-point) and the schema(s) for the message load; if the interface is a Telephone of VoiceIP, we need a celephone line (wired or wireless) and the number of the destimation.
I feel that we are trying to unlock an open door in this discussion.
Cheers,
- Michael Poulin