You are a developer in WID, you play around in your candy UI all day creating integrations. One day, you switch into the Resource Perspective and you are exposed to files and extensions that you’ve never seen before. What are they? How does it all hang together? Read on!

In the root of your module project, you are likely going to see:

1. 1 sca.module
2. 1 sca.modulex
3. N *.component files representing the components in the assembly diagram
4. N *.import files representing the import components in the assembly diagram
5. N *.export files representing the export components in the assembly diagram
6. 1 .classpath
7. 1 .project
8. 1 .runtime
9. a ‘gen’ directory
10. a ‘settings’ directory containing N*.prefs files.

In the following sections, I’ll attempt to describe what these files do.

sca.module

This file identifies the module to theWPS runtime as being a SCDL v6.0.0 defined module. This is a hardcoded filename that the process server SCA runtime looks for.

sca.modulex

Is an IBM extension on the ‘SCA standard’ sca.module file that provides information such as where the component resides on the assemblu diagram and the type of the component.

N *.component files

These files physically back the component abstraction from the assembly diagram. They contain the information such as: Interface type, Interface portType, reference type, reference portType, the target of any wire from a reference, the implementation type and the implementation backing file. In addition, any transaction qualifiers set in the UI reside in this file. You can open component files with a text editor (everything is XML) and see for yourself.

Jeff Brent and Roland Barcia provide a good explanation of a component file in their article: Building SOA solutions with the Service Component Architecture — Part 1.

N *.import files

Imports are cousins to component files except they represent the import components. They too define the interface and port type, but they also define the binding that should be used for communication (JMS, SCA, MQ etc).

N *.export files

Exports like imports define an interface. They also define the binding used including any information required by the runtime to use the export.

.classpath

Used by WebSphere Integration Developer builders to resolve dependencies. Please note that updating the .classpath will allow WID to resolve projects/libraries but it has no effect on resolutions from Process Server. You need to use the module dependency editor in order to have process server resolve dependent projects.

.project

This file contains the information related to the project from an eclipse point of view. Project dependencies, internal builders (things that run when you save a file or editor) and project natures (how does eclipse know that a project is a Module project? Natures).

‘gen’ directory

Depending on the component implementations in your module, you may find a gen directory containing java classes. These are usually generated by the mapping runtime.

.settings directory

This is another eclipse construct that can be used by plugins to set project specific information. This gets used internally be eclipse. The Integration Test Client uses the .settings directory to store the server that a test should be run against if the dialog box is set to not prompt.

Like any good abstraction, theres no real need for you to ever be digging around the physical representations of your modules, but it’s good to know whats being created behind the scenes if anything ever goes wrong.