Currently artifacts are 'typed' based on information directly added to the artifacts. This is necessary because the different artifact types do not have a common notion of 'behavioural type', and in some cases it may be necessary to indicate that an artifact behaviours like a particular type (similar to the relationship between a class and interface). For example, a choreography may be of type X, with participants P1 and P2. We may then want to say that a BPEL process, of type Z 'implements' the behaviour X@P2 - so we need to store that metadata somewhere.
Eclipse plugins currently maintain dependency information between the artifacts based on this 'type' information - using the project as an initial scope, with related projects (established in the project descriptors) also being included where defined. So this means that if two artifacts, with complementary type information, are contained within the same project (or projects that are related), then conformance checking (etc) can be performed between them.
I wanted to explore this mechanism to highlight some potential future issues.
Currently (as mentioned) the type information used to compare different artifacts is obtained from within the artifact, whether it is a CDL, ESB or BPEL description. The problem with this approach is that it assumes any tool editing the artifact will preserve this additional information, which is currently the case with the tools being used, but cannot be guaranteed with future artifacts, or if different tools are used on these existing artifacts.
The options are:
a) continue with the current approach, and deal with any problematic situations as they arise on an artifact by artifact basis (not ideal)
b) provide some form of 'descriptor' file that holds the additional information associated with the artifact
c) use annotations associated with the artifact's resource
Obviously (a) is not ideal, so for now we should presume this is not an option.
Option (b) is ok as it externalises the additional artifact information. One problem I see with this approach is how it may be stored, along with the associated artifact, in a repository (e.g. SOA repository).
Option (c) may also be fine, although care would need to be taken when storing the project in a source code control system (svn, cvs, etc), to ensure that the relevant metadata is also committed. However this approach also would have a problem when the artifacts are stored in an SOA repository.
SOA repositories generally have a mechanism for defining explicit dependencies between artifacts. The issue is that they are not standard, and we need the ability to annotate these dependencies.
Unlike with the Eclipse environment, where dependency between artifacts could be inferred based on the 'type' information associated with each artifact, this may not be appropriate in an SOA repository where the scope is not controlled. Therefore having explicit dependencies between the artifacts would be preferrable. However, we also need to make sure that this dependency information is transferred into the Eclipse environment, in a manner that can be used regardless of the structure of the project into which those artifacts have been placed.
So the question is, is there a common mechanism that can manage the required metadata and dependencies, that can work both in Eclipse and across a SOA Repository?