I can see the value of a Composite Application Service in many circumstances as a time saver when entering details of a model - for example I might create a Composite Application Service of "Financial Suite" to represent Payables, Receivables, Asset Accounting, General Ledger and so forth.
While I can define the granular services of which the composite is composed, that containment is not reflected in the reporting done against the contained services. An application that provides "Financial Suite", which contains "Accounts Payable" as a component, is not shown as an implementer of "Accounts Payable" service for example.
Am I missing the correct use case for this functionality? What I would prefer is for the containment to be flattened during reporting so the composition is functionally invisible to the user, if that makes sense.
Kevin
Composite Service vs. Service
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Hi Kevin,
Thanks for your post.
First, let me make sure that I accurately understand your scenario.
You've defined a Composite Service (Financial Suite) with sub-services, including Payables.
You then define an Application (Accounts Payable) that provides the Payables Service.
When you go to the Application Service summary view for Financial Suite, the set of sub-services are displayed but Accounts Payable does not appear in the list of implementing applications, as you were expecting.
As some more background, Application Services and their implementing Providers were designed to accurately capture service-oriented application architectures (SOA) but several years ago, we relaxed the semantics of "implementing application" such that Application Providers can implement a service, even though they do not necessarily implement all of the functions defined for the Service - and we did this so that we can use the Services to manage types of applications without requiring a purist SOA application architecture.
With the Composite Service there is likely to be a Composite Application Provider that implements it. In the Application Service summary view, the semantics of the implementing applications is slightly different from what you are asking for. That's not to say that what you are looking for is not possible or not correct, rather that it has different semantics.
If we consider a Composite Service, "ERP System", that is made up of "Finance Management System", "Sales Order Management System", etc. we might have a Composite Application Provider that implements the ERP System, "My SAP", which is made up of the configurations of the SAP components like "FI/CO", "SD" and so on.
Here, we can say that "My SAP" implements "ERP System" and that "SD" implements the "Sales Order Management System" but it would not be valid to say that "SD" implements "ERP System".
As I understand your requirement, you're looking for a view (or part of a view) that shows the Applications that implement Services that are contained in a Composite Service, which is different enough, I think, that it warrants a different view to what's in the Application Service summary. Modifying the existing "Implementing Applications" would stretch the semantics of that field, really.
However, this is a pretty straight-forward query to put together - combining the query that lists the set of contained Services (top right of the summary view) and the set of implementing applications.
Jonathan
Thanks for your post.
First, let me make sure that I accurately understand your scenario.
You've defined a Composite Service (Financial Suite) with sub-services, including Payables.
You then define an Application (Accounts Payable) that provides the Payables Service.
When you go to the Application Service summary view for Financial Suite, the set of sub-services are displayed but Accounts Payable does not appear in the list of implementing applications, as you were expecting.
As some more background, Application Services and their implementing Providers were designed to accurately capture service-oriented application architectures (SOA) but several years ago, we relaxed the semantics of "implementing application" such that Application Providers can implement a service, even though they do not necessarily implement all of the functions defined for the Service - and we did this so that we can use the Services to manage types of applications without requiring a purist SOA application architecture.
With the Composite Service there is likely to be a Composite Application Provider that implements it. In the Application Service summary view, the semantics of the implementing applications is slightly different from what you are asking for. That's not to say that what you are looking for is not possible or not correct, rather that it has different semantics.
If we consider a Composite Service, "ERP System", that is made up of "Finance Management System", "Sales Order Management System", etc. we might have a Composite Application Provider that implements the ERP System, "My SAP", which is made up of the configurations of the SAP components like "FI/CO", "SD" and so on.
Here, we can say that "My SAP" implements "ERP System" and that "SD" implements the "Sales Order Management System" but it would not be valid to say that "SD" implements "ERP System".
As I understand your requirement, you're looking for a view (or part of a view) that shows the Applications that implement Services that are contained in a Composite Service, which is different enough, I think, that it warrants a different view to what's in the Application Service summary. Modifying the existing "Implementing Applications" would stretch the semantics of that field, really.
However, this is a pretty straight-forward query to put together - combining the query that lists the set of contained Services (top right of the summary view) and the set of implementing applications.
Jonathan
Essential Project Team
-
Kevin Campbell
- Posts: 40
- Joined: 13 Sep 2010, 20:26
Thanks Jonathan, and I think that sounds reasonable. We'll poke around with the reporting a bit ourselves.
Kevin
Kevin
