[
https://issues.apache.org/jira/browse/SYNAPSE-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Saliya Ekanayake updated SYNAPSE-532:
-------------------------------------
Attachment: diag2.jpeg
diag1.jpeg
Proposed Design for Synapse Dependency Management
-----------------------------------------------------------------------------------------
Note: The following discussion will not consider about entries referring to
registry resources.
The elements in the Synapse configuration can refer to other elements as
dependencies. Denote such elements which can be defined and be referred later
by other elements as "dependable" elements. The Synapse configuration language
identifies three dependable elements as follows.
1. Sequence
2. Local Entry
3. Endpoint
The possible dependents are obviously proxy services, endpoints, and sequences.
Additionally, the following mediators too may be dependents.
1. send
2. validate
3. callout
4. xslt
5. xquery
6. router
7. throttle
8. cache
9. clone
10. iterate
11. script
12. spring
The proposed design in diagram 1 suggests that each of the dependable elements
should implement the Dependable interface. Each dependable will have a list of
dependents as well. The interface includes three methods as follows.
1. isUsed()
This will return a boolean value based on whether the element has any
dependents or not.
2. addDependent(dependent)
This will add the given dependent to the list of dependents in the
dependable element.
3. getDependents()
This will return the list of dependents.
The next step of the design (diagram 2) is to let the possible dependents
(note: not all the possible dependents are shown in the diagram for the sake of
clarity) implement the "SynapseResolver" interface. The interface declares a
single method, i.e. resolve(parent). The objective of the method is to find the
dependable elements for the particular dependent. It will add a reference to
itself as the dependent in each dependable it finds. If the parameter "parent"
is specified then this will add a reference to the parent as the dependent
instead of itself. Thus, after the completion of resolve method, each
dependable element will contain a list of dependents.
This approach enables a user to safely delete dependable elements through
Synapse API. It will also provide the ability to take the deletion decision
either as not to delete or to perform cascade delete based on the list of
dependents for the particular dependable element.
Your ideas on this approach are welcome.
Thanks,
Saliya
> Dependency Management in Synapse
> --------------------------------
>
> Key: SYNAPSE-532
> URL: https://issues.apache.org/jira/browse/SYNAPSE-532
> Project: Synapse
> Issue Type: New Feature
> Components: Core
> Reporter: Saliya Ekanayake
> Attachments: diag1.jpeg, diag2.jpeg
>
>
> At present Synapse may fail due to dangling references. As an example
> consider a proxy service which refers to a sequence. If the sequence
> definition is not there it will be a dangling reference and Synapse will fail
> to mediate properly.
> The following items are the possible items on which others may depend.
> 1. sequences
> 2. endpoints
> 3. local entries
> 4. resources in the registry (remote)
> A way to overcome the issue is to resolve dependencies at start up. This,
> however, has an issue since we cannot distinguish between references for
> local entries and for registry. If we force the user to have all the
> referring items either in local entries or in registry prior to start
> Synapse, then we can clearly identify missing resources. Anyway if the user
> removes a used resource from registry then again Synapse will not be able to
> handle it. Therefore, IMHO it will be good to omit the dependency management
> on registry resources and focus only on whatever the information available in
> synapse.xml.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
