• addProperties(ConfigurationPanel) : The configuration panel has an id that can be used by the configcontroller to determinate how to convert the panels input fields into configuration properties.
• Configuration getProperties(): When the configuration of a business model is done, the configcrontroller must be able to return the collected properties, to use when deploying the proxy servlet.
The configuration of a business model must primarily be used in the proxy servlet, but the structure of the WSDL file that described how to interface to the proxy servlet, may also depend on the configuration of the servlet. Therefore the WSDL generator class of a business model must have access to the configuration of the business model. The easiest way to obtain this is by giving it as argument when generating the WSDL. The WSDL generator is only responsibly for the changes that the business model will do to the WSDL file, therefore the WSDL for the application without the business model applied must also be available when generating the WSDL.
The interface of the WSDLGenerator must have one method:
• WSDL generateWSDL(ApplWSDL, configuration) : An implementation of the WSDLGenerator interface, can generate the WSDL document for one proxy servlet. If a business model consist of more servlets (as discussed in the proxy design section), the business model must have more implementations of the interface.
DeployStatePanel
(from m ike.ws.seci ntegrator.gui)
ButtonPanel
(from m ike.ws.seci ntegrator.gui)
WizPanel
(from mike.ws.seci ntegrator.gui)
MainWindow
(from m ike.ws.seci ntegrator.gui)
StartPanel
(from m ike.ws.seci ntegrator.gui)
BusinessSelector
(from m ike.ws.seci ntegrator.gui)
Panel
(from awt)
Frame
(from awt)
Figure 30
Notice that the MainWindow only uses two panels: The static button panel, and a WizPanel that is super class for all panels used in the target area of the main window.
The three panels that are used in the static flow of the tool therefore extend the abstract class.
Functionality classes
The functionality classes are all related to the MainWindow class, either directly or through other functionality classes. The reason for this is that the MainWindow is the class where the state machine that controls the overall flow of the system is
implemented.
WSDeployerFactory
(from m ike.ws.seci ntegrator)
ProxyDeployer
(from m ike.ws.seci ntegrator) DeployWriter
(from m ike.ws.seci ntegrator)
ByteClassLoader
(from m ike.ws.seci ntegrator)
ProxyServletGenerator
(from m ike.ws.seci ntegrator)
Util
(from m ike.ws.seci ntegrator)
BusinessModelReader
(from m ike.ws.busi nessconfig)
MainWindow
(from m ike.ws.seci ntegrator.gui)
IntegProp
(from m ike.ws.seci ntegrator)
WSDeployer
(from m ike.ws.seci ntegrator)
WSDeployerImpl
(from m ike.ws.seci ntegrator)
Figure 31
The WSDeployerFactory is a factory class that can build web services deployers. The factory design pattern is chosen because it must be possible to easily develop new deploy-classes if the system should be used with different web service platforms. The Factory builds instances of the interface WSDeployer that describes the functionalities a web service deployer must have. The WSDeployerImpl is an example of an
implementation of the interface, it uses a DeployWriter to write files used to use when deploying.
The deployment tool must be able to analyze classes that are not part of the system, to display the methods available for web service deployment. The ByteClassLoader must be able to convert a byte stream into an instance of a class, so the class can be analyzed.
To make proxies for the application deployed by the WSDeployer, the ProxyDeployer class can be used. The class will use the ProxyServletGenerator to generate and compile a proxy servlet with the correct name and configuration, and then copy it to the servlet container of an application server. Because the ProxyServletGenerator must be able to compile the servlet, it must call an external compiler.
The Util class makes it possible to call external applications, the class make the deployment tool wait for the external application to end, before it continues its
execution. This is useful e.g. when the compiled servlet must be copied; this can not be done before the compiler has compiled the source code.
The BusinessModelReader class is the class that can read an XML description of a business model, and make an instance of the model, if the correct classes are available.
The IntegConfig is a class that can read XML documents and make the content available in a standard Property manner to the application. The class is constructed
using Singleton design pattern, which makes the same instance of the class available to the entire application. The class diagram only shows relations with the MainWindow and BusinessModelReader, other classes also have relations, but they are not shown in the diagram due to the complexity
GUI Classes available to the business models
The class diagram of GUI classes available for business models is rather large due to the number of panel types (described in the design of business model configuration panels). The diagram showed here only contains one type of configuration panel (Text field panel), but the structure is the same for all panels. Refer to the CD-Rom for the complete class diagram.
ConfigPanel
(from m ike.ws.busi nessconfig.gui)
ConfigPanelImpl
(from mike.ws.busi nessconfig.gui)
BusinessModelReader
(from m ike.ws.busi nessconfig)
ConfigPanelFactory
(from m ike.ws.busi nessconfig.gui)
WizPanel
(from mike.ws.seci ntegrator.gui)
PanelTextInput
(from m ike.ws.busi nessconfig.gui)
PanelTextInputImpl
(from m ike.ws.busi nessconfig.gui)
Figure 32
The ConfigPanel interface defines the behavior that all business model configuration panels must implement. As described in the design of the ConfigClass, all
configuration panels must have a unique ID and other attributes, this interface can be used to get these attributes.
The ConfigPanelImpl is an abstract implementation of a ConfigPanel. The Class also contains some general methods that can be used to compose GUI components with behavior like describe in the GUI design section. The class extends the WizPanel described in the static GUI class diagram, this makes it possible to use sub-classes in the deployment tool.
The PanelTextInput interface extends the ConfigPanel, to specify the behavior of a Text field panel. The interface can be used by the ConfigClass, to access the attributes of a Text field panel, without having knowledge of the entire implementation.
The implementation of the PanelTextInput, PanelTextInputImpl, extends
ConfigPanelImpl, because it makes the usable in the deployment tool. It also contains the implementation of the ConfigPanel, which makes the coding a little easier. Beside
the implementation of the methods described in PanelTextInput, PanelTextInputImpl contains some construction methods that are not visible through the interface.
The ConfigPanelFactory is a factory class for all configuration panels. It can build panels from XML elements that describe the content of the panels. The class makes an instance of an implantation, and configures this instance after the roules described in the XML element. The BusinessModelReader, also described in the functionality class diagram, makes use of the ConfigPanelFactory to generate the list of static panels available in a business model.