Discussion on composite service expressions and genre granularity, started 2008-05-01. Preliminary status, though contributions welcome.
Global questions
- Granularity of genres
- Compositionality of service expressions
- Updating of "related SUMs/service expressions" in registry
- Granularity of genres: business driven or tech driven (service expressions)
- CRUD: a single genre? multiple genres? a catchall genre that all genres and expressions must be based on?
- Minimalist or maximalist: is all the world CRUD? (Tech driven, minimalist, easy comparison). Does each business have its own unique requirements? (Maximalist, idiosyncratic, business-driven --- straightforward match to business requirements)
- The requirements of e-framework seem to drive towards minimalist. BUT this may violate the one genre-per-expression rule, and forces expressions away from business requirements
- Kerry suggests is that Genres have sublasses in a OO sense: eg Create has a Create Id subclass, Create {Identifier}
[KB I am not sure that is at all what I am saying???? Create {Identifier] isn't a different genre but create operating on a different set of data? What would need to make it different
- If all the world is CRUD, then we would say that Read {Identifier} is often called Resolve in ID systems --- and is NOT a distinct genre
- Multiple behaviours per expression: ok? does it lead to multiple genres per expression?
- "Invoicing Service": Multiple behaviours, single interface. Is this a single expression? Is this a single genre? Can this be a single expression with behaviours from multiple genres?
- If we preserve single-genre-per-expression, and expressions can have multiple behaviours, then the genres they realise must have the same or greater range of behaviours. CRUD as a single genre will do this: Invoice Service Expression < CRUD {Invoice}. But not clear whether this will generalise.
- If we want the Invoice Service to do the behaviours of CRUD Genre plus Notify Genre, is it still a single service?
- Appropriate Copy looks to the user like an Obtain (interface), but technically the Select behaviour is what makes it distinctive. Which of the two genres should it belong to? [Probably Appropriate Copy, but that goes back to business-driven view of genres]
[KB question: In FRED and PILIN you haven't factored CRUD as a single GENRE but as separate GENRES. Which is the right (?) way to do it?]
[NN answer: that's because I didn't know at the time I was expected to treat CRUD as a single Genre. In fact, I'm not sure we're telling people they should even now; and if we decide we should, people need to be informed. My own take: I don't like multiple behaviours per genre, I think they introduce more confusion than not.]
- An expression, specifying a user interaction with a system, can be implemented through composition of services --- the user interacts with the system through the same expression, the remaining services (which are not exposed in this app but may be exposed elsewhere) do the actual work of realising the functionality. e.g. OpenURL as service expression and as SUM.
- genre > expression > implementation > sum capturing implementation, composed of multiple genres/expressions: how do those expressions relate to the original?
- Are there Higher Level service expressions vs. Lower Level service expressions? If so, where does the granularity of service expressions bottom out?
- Only a cogent minimalist (so tech-driven) genre ontology can address that requirement
- how should genres/expressions used in implementaion SUMs be discoverable from the original genre/expression they are implementing?
- Longterm, registry will need to make these connections, not the author
- if a service expression CAN be composed (in implementation) of multiple expressions/genres, is it a requirement for submitter to present that?
- due diligence, but presupposes a cogent repertoire of fine-grained genres that the submitter can draw on; AND composition must be restricted to functionality, and kept away from implementation architecture. Even then, this is a hard ask.
OK, Adding my thoughts and structuring of the above. There are 5 "issues" as I see it...
1. How do we document a system/application that uses another system/application?
- Answer: We already allow for SUMs to include the use of other SUMs and CORE SUMs.
- No contention.
2. How do we document a SE that is built choreographing reusable services? (or) How do we document SUMs that are deployed using a service interface (SE)?
- Scenario: Someone has a real SE level SUM they have exposed as a real SE interface.
- Answer: We need to be able to reference the SUM from the documented SE. In a sense it is an implementation.
- Answer: This does not mean that SUMs can be a type of SG or have to be classified as such. The SUM may implement functionality and choreography that is not exposed as behaviours at the SE/SG level (eg. logging).
- Answer: This is similar to using a SUM in a SUM. ???
- Recommendation: We need somewhere in the e-Framework model to record this (new SE element). This should be similar to recording known uses, as the community/eF can update this later without having to modify the original SE.
- Apart from that, no contention.
- If a service expression CAN be composed (in implementation) of multiple expressions/genres, is it a requirement for submitter to present that?
- I think not a requirement. If it's truly one SE then no need to go guessing what it might be made of. If they've truly implemented the SE in this way then we want the SUM and the link from the SE. LyleWinton
3. How do we document composite services?
- Scenario: Someone has a real implementation of a service expression that implements many genres.
- At the moment SE can only implement one SG. Composite SEs need to be split into separate submissions.
- We need to be able to compare these with the fine grained implementations.
- I'd like to make this as easy as possible on the submitter, and easy to explain why the need to submit it a certain way. LyleWinton
- Answer: People submit these are multiple SEs, one for each genre. If choreography is expected then this should also have a SUM over it.
- Proposal: Why not have SEs that implement more than one SG. LyleWinton
- One problem might be that SEs are then not comparible. But were they ever comparable at anything but the genre level. LyleWinton (debating with himself)
4. How do we document very fine grained services?
- Scenario: Someone has implemented a service end-point (and therefore interface) for each function eg. Create, Update, Delete
- Are these too fine grained, considering they will probably always be implemented together and have no business value apart from one another?
- However, we might need fine grained services for comparison (lowest common denominator)
5. How do we document generic services versus specific services?
- Scenario: One implementer has developed an Invoicing Service, while another implementer considers this to be just a CRUD service.
- The issue is that the "CRUD Service Genre" is of value to developers, whereas the "Invoicing Service Genre" is of SOA business value.
- Answer: (partial answer) In the SUM a "CRUD Service" must indicate what data source it is operating on.
- Is all the world is CRUD?
- No. There are two types of services of value in a SOA, those that expose data and those that provide process (and of course the hybrid). I think there is value in exposing CRUD services as just that. This means that the real value will be in the management of the underlying data. LyleWinton
