Managing ActiveVOS Resources

Challenge

ActiveVOS resources such as bpel, wsdl and schema files are uniquely defined by targetnamespaces. Although it is a bad idea to have two objects with the same targetnamespace in a workspace or on a server, there are times when the same resources are used by different projects and need to be available to both. This is one reason why it is best to separate out common resources into common projects. This will also help to avoid redundancies and inconsistencies between two versions of the same resource.

Description

This best practice document explains why common resources should be separated from project resources.

Identifying a Common Resource

Some common resources are easy to identify (e.g., CommonHeader.xsd, CompanyHolidays.xml, etc.) while identifying others may not be as obvious. A simple rule to follow is, if a resource is used by more than one project it is generally a common resource. As with any rule there may be exceptions. If two projects are closely related and one references the other, and these are the only two projects that use the resource, then the resource should probably be in the parent of the two projects.

As with all best practice cases, the rule (and any exceptions to the rule) should be documented.

Example Rule:

Common Resources Rule.

All wsdls, schemas, and XQuery modules that are used by more than one project will be defined as common resources and will exist in a common project.

Exceptions.

Resources used only in the CustomerSurvey Project and the CustomerSurveyExtras Project will be defined as common CustomerSurvey resources and will be stored in the CustomerSurvey Project.

As illustrated above, be specific about exceptions.

Placement of Common Resources

Although as a best practice common resources should be in a common project, there is no real requirement as to what that/those project(s) should be called. Common Resources can be in many different common projects. The projects can be called Common, or CommonResources or any name (e.g., MyProject), but the project name should be indicative of what the project contains. For example:

• CustomerResources
• ABCInsurance
• SurveyWsdls

Another case for using Common projects for resources that may be used only once, is for external resources. If external resources are provided (i.e., wsdls and schema pointing to external services) they should be separated from the application Project. In this way, when the external system makes changes they can be addressed in a project specifically for that system.

For example, if projects use a selection of WSDL and XML schema resources to interact with web services offered by Yahoo Shopping, and those resources have been obtained from Yahoo, then it is appropriate to dedicate a common resource project to hold those files, called “YahooShoppingResources” or something similar.

Splitting Common Resources

In a case where there are a lot of common resources, it is best not to put them all in one basket.

Determine which resources should be separated and group them to match the way they are used.

If a developer has to import a project that has too many resources (every time they work on any project) the overhead may become too much. It is better if the developer only has to import resources that are required in the common projects they are using.

To implement this, just group the resources into separate projects. The grouping should be determined by the use of the resources.

Document all decisions on Splitting resources as well.

Example:

• Resources relating to company standards are in a project called Common
• Customer Services Common resources are stored in CustomerServiceResources
• Product Application resources are stored in ProjectResources
• External Services resources are stored in ExternalServices
• Other common resources are stored in CommonResources