Let me try to respond to your thoughts. (My apologies for not getting back to this sooner, but my hard drive needed to be replaced and that took longer than expected.)
See inline [kjl].
Ken
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?
[kjl] An excellent question. The idea of service granularity has been with us for years but never really defined. I see the problem as it still takes up bandwidth that can be more productively used. I believe our conclusion is that the tagline doesn’t really add anything and we have seen no examples of metrics that convince us otherwise.
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.
[kjl] Again, agree completely.
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
[kjl] This was brought up because the more detail that is necessary in the service description, the more difficult it is likely to maintain. Here it is meant as a consideration to keep in mind.
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.
[kjl] The RAF goes into a lot of detail on description. Figure 16 identifies the major parts of the service description as dealing with
(1) service functionality (i.e. what outcomes (RWEs) result from using the service),
(2) service policies (i.e. the human decisions on the conditions of use),
(3) metrics available for the service (operational characteristics of deployed service),
(4) service interface (including information (exchanged in communicating with the service) and behavior models),
(5) service reachability (i.e. endpoint and protocol corresponding to endpoint).
These constitute information that can be supplied and maintained by the service provider, and the list above is ordered here as the things for a service consumer to decide if they want to use the service (first 3), how to communicate with the service (4th item), and where to communicate (5th item).
Figure 14 gets into other elements of general description that can be considered metadata and may be contributed and/or maintained by a participant other than the service provider.
Agreed that the service developer can use a schema that is maintained by a third party, but that is the developer’s choice that the provider needs to live with, where this says nothing about whether the developer and the provider are the same or different entities. The service description needs to clearly identify which schema is being used.
With respect to metadata, Figure 14 identifies additional information that may affect the consumer choice of whether to use the service but doesn’t fundamentally affect the provided service or its Figure 16 description.
Can we answer your question on what is a service interface by pointing to either item 4 or a combination of items 4 and 5?
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.
[kjl] “Sub-function” is used here in a very imprecise way, so apologies for any confusion. What was being referred to was a URL representing a resource and then applying the various HTTP methods to that URL. Are CRUD times each URL a set of separate services to be described? More fundamental (maybe) than what is a service interface is what constitutes a service and then how is that described.
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).
[kjl] Beyond some basic structure, the URL path is completely up to those defining a set of resources.
http://a/b is a separate resource from
http://a/b/c1 or
http://a/b/c2. If I apply HTTP GET to each of these URLs, I retrieve a representation of the resource identified by each URL. This does not say the underlying retrieve logic for c1 is the same as for c2, but the overall effect — the retrieve — can be considered the same. To what extent can I consider defining a single service with a URL template of
http://a/b/{c} where {c} can be any differentiator at that level? Again, that decision affects what needs to be included in a service description and how many separate ones we need.
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.
[kjl] Again the wording is imprecise. Yes, a URL is an interface through which we access an underlying capability to realize RWEs. In a REST interpretation, the URL identifies a resource and the HTTP method indicates an action on that resource. Is a GET on
http://a/b/c1a separate service from a DELETE on
http://a/b/c1? I would say YES. But should we be concerned with the idea that GET
http://a/b/c1 and GET
http://a/b/c2 and … can be considered separate services? I’d say YES here, too. We’d generate an unending number of services whose descriptions would be overwhelming to maintain.
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.
[kjl] We’re starting to get to the meat here. How about one service, say a retrieve, defined with an interface template that can manifest itself through an unlimited number of interfaces, where a particular interface, e.g. URL to REST resource, can be thought of as conveying configuration information to the service, e.g. the access to retrieving the particular resource?
In addition, I think the latter part discussing “the less granular the interface signature is, the more reliable …” is particularly with where I have been heading. For example, I could define a new service for every possible query language supported by a particular search service or I can have a payload holding a query and an attribute identifying the query language being used. I think this fits in with your ideas on a less granular interface, e.g someone can support a new query language without the basic structure of the search interface having to change.
I believe this can be described in terms of minimizing semantic engagement.
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).
[kjl] Agree.
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.
[kjl] No, a WSDL can have any level of granularity of information, and developers who make it too granular are the ones who frequently complain about their WSDLs breaking. I think our discussion should look towards what constitutes the interface of a robust service with well defined functionality and outcomes, while maximizing service opacity.
I feel that we are trying to unlock an open door in this discussion.
[kjl] We shall see ;-)