What is a part? Part is a software component, which consumes, produces or transforms data. Part handles inputs and outputs via pins. VCB builds applications by connecting Parts. To handle complexity issues parts can be grouped and we call these group devices using electronic design analogies.

Part implementation contains a code and its Meta description. Description is an XML file, which defines part input and output pins. Every pin has a name, which is shown on the schematic diagram:

Inpins accept data, outpins produce data. We call produced and consumed data a signal. Signal can contain no parameters, one or many parameters. Parameters (for now!) are primitive data, serialized objects, arrays or XML events.

When defining inpins we need to define a method in the implementation code which will handle a signal received by inpin. Method parameters define signal parameters. Although using methods is not the only way to handle inputs. In future design we are considering other possibilities like streams, files, JMS etc.

In order to define an inpin XML file should contain method signature information to the related pin:

    <inpin id="2" name="query">
        <parameter type="String" name="sqlstring"/>
    </inpin>

When defining outpins we need to define which kind of signals the code should produce. In order to handle the signals produced by the code VCB framework provide an interface to be called by the parts. We have identified 3 cases with VCB part implementation:

• Specially developed VCB part
• Java Beans
• Any Java code

For each of these special cases the framework have a specific runtime instantiation procedure. Lets consider them on per case basis.

Specially developed VCB Part

The VCB part is a part when code developer ‘knows’ about VCB framework and develops a part specifically to work under this environment. It doesn’t require that VCB part developer should implement certain interface. The part just need to register itself and should ‘know’ about the framework. Firing outpins for these part means a method call to the framework. The advantage is that this approach is optimized for high performance.

So in contrast to inpins, outpins cannot be automatically generated and understanding of the class functionality required.

Converting JavaBeans into VCB Parts

JavaBeans is a Java component standard that defines certain design pattern and naming conventions like set/get methods and event listeners. We are considering the case when we take a ready JavaBean and try to convert it into VCB part.

In order to do this conversion, VCB part developer need to develop an XML Meta file to describe this transformation. JavaBean has its own way of producing events. It fires events and other components, which are intereted in such event, register themselves via listener interface. Because we want that all signals goes via our framework, the framework becomes a single listener to the JavaBean and converts the events into VCB signals. No other listener allowed because all events should go via the framework (we will discuss why is that important later).

Events are standard like PropertyChange event while we may need to differentiate events and assign outpins to different events (although they will be fired to the same listener).

For example we want when ‘label’ property of Button java beans is changed it fires ‘labelChanged’ event. Button class is JavaBean with “Label” as a bound property. Whenever a bound property changes, notification of the change is sent to interested listeners:

public void setLabel(String newLabel) {
    String oldLabel = label;
    label = newLabel;
    sizeToFit();
    changes.firePropertyChange("label", oldLabel, newLabel);
}

In order to convert it to VCB part we need to supply XML with the following:

<outpin id="14" name="labelchanged" type=”BeanEvent’
              eventSetName=”label”
              adapterClass= “PropertyChangeListener”>
              listenerMethodNames=” firePropertyChange”
              addListenerMethodName =” addPropertyChangeListener”>
        <parameter type="propertyName" name="label"/>
</outpin>

The framework uses PropertyChangeListener adapter which implements firePropertyChange(String propertyName, Object oldValue, Object newValue) method and adds it to the JavaBean as listener (addPropertyChangeListener method) . When it is called, the adapter will check for example propertyName and will fires “labelchanged event” by calling a method in the framework interface as it was VCB part we consider in our first case.

Converting any Class into VCB Part

We have a standard classes like JDK’s java.lang.Math class. Because we don’t have any specific interface and it doesn’t fire any event then the way to have output from this classes is using return parameters of method calls. Lets consider how will covert a Math class into a VCB part. Say we want a VCB part, which will do ‘Sin’ calculation. Math class has sin(double a) method. We want to have part like this:

So we define one method both as inpin and outpin (we call it inout pin):

<inoutpin id="1" name="input" out_id="51" out_name="result"> 
   <parameter name="angle" type="double" />
</inoutpin>

On a visual diagram it will be shown as 2 pins.

Similarly other Match functions can be implemented. They can implemented either as on big VCB part with single Meta file or as a number of small parts for each specific function using the same Java code but multiple XML Meta files.

In future we can consider cases when we need to convert EJBs, COMs and other components into VCB parts, thus having high reuse of formerly developed components.