![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
In this article, we examine the basics of the packaging model that is used to create and execute applications you develop and execute with IBM® WebSphere® Integration Developer and IBM WebSphere Process Server. Although our simple example focuses on POJOs, you learn how to leverage this basic format across all of the component types that you author using WebSphere Integration Developer and execute on WebSphere Process Server.
A simple HelloWorld example illustrates the V6.0.0 packaging story. This packaging model is compared and contrasted to the pure J2EE model, where key variations are described and possible choices that assemblers of solutions might have are outlined.
This article assumes that you are familiar with the basics of the Service Component Architecture (SCA), including concepts such as Service Component Definition Language (SCDL), modules, imports, exports, and bindings. Each of these concepts and some others relate to the artifacts that are presented in the physical packaging model.
To illustrate the concepts that we will introduce in this article, we start off by describing a simple Hello World example.
In this example we have a single SCA module containing a single component that is implemented in Java™, named HWComponent. This component has one export that has a Web services binding, named HWComponentExport. See the Assembly Diagram view for this module in Figure 1.
Figure 1. Assembly diagram view
Additionally, the single SCA module is dependent on a library project, named HWLibrary that contains the shared artifacts for this simple Hello World example.
The HWComponent exposes an interface that is typed by the Web Service Definition Language (WSDL) and passes data described by the XML Schema Definition Language (XSD). See the Interface editor view of this WSDL, named HelloWorld in Figure 2.
Figure 2. Interface editor view
The Business Object (BO) editor for the XSD, named HWMessage is displayed below:
Figure 3. Business Object editor for the XSD
Both the interface (WSDL) and the Business Object (XSD) are located in the HWLibrary project. The HWModule project is dependent on the HWLibrary project. If this example had more than one module project, such as a HWModule2, then the additional module projects could also leverage the library project (HWLibrary) and the contents within.
This article provides further details of this example where appropriate within the following sections.
Authored WebSphere Integration Developer projects
There are two types of authored projects: library and module. The default perspective of WebSphere Integration Developer shows you these projects using the Business Integration view:
Figure 4. Business Integration view for the Hello World example
A library project houses common artifacts that are used by components and artifacts in other module and library projects.
The types of artifacts that you can house in library projects are restricted to the following: BO Maps1, Relationships, Roles, Interfaces, and BOs.
In our example, we have one library project (HWLibrary) -- containing one BO (HWMessage) and one interface (HelloWorld):
Figure 5. The artifacts that can be contained within a library project
A module project houses components and the artifacts used by those components. Module projects cannot be dependent upon other module projects, only library projects.
The types of artifacts you can house in module projects are the following: Business Object Maps, Relationships, Roles, Interfaces, Business Objects, and Interface Maps, Processes, State Machines, Rule Groups, Rules, Human Tasks, Selectors, Java (POJO), and Exports/Imports.
In our example, we have one module project (HWModule) -- containing one POJO component (HWComponent) and one export with Web services binding (HWComponentExport):
Figure 6. Business Integration view showing the HWModule project
Declaring project dependencies
Projects that are authored can declare dependencies on other projects using the Dependency editor. Dependencies can be of the following types: projects, Java projects, and J2EE projects.
The following is a screen capture of the Dependency editor for our HelloWorld example:
Figure 7. Dependency editor for HWModule project
Authored projects house source artifacts including components. These artifacts are portable across SCA implementations, but are not executable without an additional generation step. This generation creates the platform specific artifacts that are required in order to operate on a given platform. For WebSphere Process Server, the runtime platform is WebSphere and J2EE, and thus, WebSphere J2EE artifacts and resources are generated.
For any given module project, there will be up to four J2EE staging projects generated with naming conventions that are based off of the module project's name:
- an Enterprise Application project
- an EJB project
- an EJB Client Project
- a Dynamic Web project
You will not be able to see these projects in the Business Integration view. To view these projects, you need to change perspectives, for example, the Java perspective.
If you open up the Java perspective and use the Package Explorer view, you will see the generated J2EE projects as shown in Figure 8.
Figure 8. Change perspectives to the Package Explorer view to see J2EE generated projects
Enterprise application projects house artifacts and metadata for the entire enterprise application, for example, EAR. Some of the types of information they hold are:
- Which EJB projects are contained within the EAR?
- What is the context root for the Web modules?
In our example, the generated enterprise application project is named HWModuleApp, which is based on the convention: Module Name + "App".
Figure 9. HWModuleApp staging project
EJB projects house artifacts and metadata for Enterprise Java Beans. This project houses the generated EJBs that represent the runtime artifacts that make components into reality. For example, an SCA export results in a generated Stateless Session EJB.
In our example, the generated EJB project is named HWModuleEJB, which is based on the convention: Module Name + "EJB".
Figure 10. HWModuleEJB staging project
The EJB Client staging project
EJB Client projects house artifacts that represent the client-side artifacts for the EJBs in the EJB projects, for example, stubs for remote and home interfaces so that clients of EJBs can interact with the EJBs.
In our example, the generated EJB client project is named HWModuleEJBClient, which is based on the convention: Module Name +'EJBClient'.
Figure 11. HWModuleEJBClient staging project
The dynamic Web staging project
Dynamic Web projects house artifacts that represent Web components, for example, servlets and JSPs. In our example, we have a Web services export -- this results in a servlet that represents the http router for inbound http traffic. The dynamic Web project will be generated when required.
In our example, the generated dynamic Web project is named HWModuleWeb that is based on the convention: Module Name + "Web".
Figure 12. HWModuleWeb staging project
Staging projects hold J2EE runtime artifacts for module projects. These staging projects depend upon the module project themselves which may depend upon library projects.
Packaging all these projects together creates an executable J2EE enterprise archive that can be deployed on a WebSphere Process Server. Here's a screen shot of the projects representing our HelloWorld J2EE EAR:
Figure 13. Projects comprising our Hello World example
As you can see from the screen shot above, not only does the EAR file contain all the J2EE projects just described, but it also contains the original module project, HWModule in our case, and a copy of the library, named HWLibrary, to make up a complete package. From a J2EE perspective, HWLibrary and HWModule are utility jars and not special archive types.
Working with artifacts outside of WebSphere Integration Developer
Source projects including artifacts can be created without the help from WebSphere Integration Developer, but that's out of the scope of this document. What will be addressed here is after creating the projects using WebSphere Integration Developer, how can they be shared between other developers that are working on the same solution (introducing the concept of Project Interchange archive) and how this archive gets deployed in the command-line to executable, platform specific artifacts, for example, J2EE EAR.
A project interchange archive is a compressed archive that contains your source projects and potentially, staging projects as well (if you choose to include them, but it’s recommended not to include these). You can create this archive by selecting Export => Project Interchange function in WebSphere Integration Developer:
Figure 14. Exporting a Project Interchange file
Figure 15. Choosing which projects to include in the Project Interchange
You can import these into a new workspace or you can use Import => Project Interchange.
ServiceDeploy: the command-line deployer
ServiceDeploy is a command-line utility shipped with WebSphere Process Server V6.0. It consumes .jars (representing compressed modules), .zips (representing project interchange archives), and .ears (representing EARs that need to be regenerated), and produces .ear files that can be installed onto WebSphere Process Server.
This short article has laid out the basics of the packaging model that is used to create and execute applications developed by WebSphere Integration Developer and targeted for WebSphere Process Server. While our example has focused on POJOs and has been very simple, you can consistently leverage this basic format across all of the component types that you can author using WebSphere Integration Developer and execute on WebSphere Process Server.
Appendix: ServiceDeploy Syntax
serviceDeploy inputarchive [<-workingDirectory temppath> <-outputAppliation outputpathname.ear> <-noJ2eeDeploy true|false> <-freeform true|false > <-cleanStagingModules true|false> <-keep true|false> <-ignoreErrors true|false> <-classpath jarpathname;rarpathname;warpathname;... -help]
- -inputarchive
- A required, positional parameter that specifies the .jar, .zip or .ear file that contains the application to be deployed. If the command is not issued from the path in which the file resides, this must be the full path for the file. The .zip file can be either a nested archive or an Eclipse ProjectInterchange format file.
- -classpath
- An optional parameter that specifies the locations of required resource files (.ear .jar, .rar and .war) files. The path to each file should be a fully-qualified path separated by semicolons (;) with no spaces. Omitting this parameter results in serviceDeploy searching only the path from which the command is entered.
- -freeform
- An optional parameter that specifies that the J2EE subdirectory in the service.jar should be treated as a free-form project. The default value is false.
- -help
- An optional parameter used to display the parameters for this command.
- -ignoreErrors
- An optional parameter that specifies that serviceDeploy builds an .ear file regardless of errors while building or validating the application. The default for this parameter is false.
- -cleanStagingModules
- An optional parameter that specifies whether to delete staging modules within an input .ear file before deployment. The default for this parameter is false.
- -keep
- An optional parameter that specifies whether to save any temporary files generated after deployment. The default for this parameter is false.
- -noJ2eeDeploy
- An optional parameter that specifies whether the application requires EJB deployment after generating the .ear file. The default for this parameter is false.
- -outputApplication
- An optional parameter that specifies the name of the .ear file serviceDeploy creates. The default is inputjarfile.ear, where inputjarfile is the filename minus the extension specified for the input .jar file.
- -workingDirectory
- An optional parameter that specifies a directory serviceDeploy uses to write temporary files.
When serviceDeploy completes processing, it creates an .ear file in the directory from which the command is run unless the -outputApplication parameter is specified.
This is not not applicable.
Example of serviceDeploy command
The following command example:
- Creates an application file called MyValueModule.ear from the MyValueModule.jar file.
- Specifies that the resources reside in the directories c:\java\myvaluemoduleres.rar, c:\java\commonres.ear and c:\java\myvaluemodweb.war.
- Enables the J2EE subdirectory within the .jar file as free-form.
- Keeps the temporary files generated during deployment.
Listing 1. Example of serviceDeploy command
servicedeploy MyValueModule.jar -classpath c:\java\myvaluemoduleres.rar;c:\java\commonres.ear;c:\java\myvaluemodweb.war -noj2eedeploy true -freeform true -keep |
| Description | Name | Size | Download method |
|---|---|---|---|
| code sample | 0512PI.zip | 8 KB | FTP |HTTP |
Information about download methods
-
Java 2 Platform, Enterprise Edition (J2EE)
-
WebSphere Business Integration zone
-
WebSphere Process Server site
-
WebSphere Process Server Information Center
Eric Herness is currently the Chief Architect for Websphere Business Integration and is from the Rochester, Minnesota development lab. He is senior member of the WebSphere Foundation Architecture Board and a core member of the Software Group Architecture Board. Eric has been involved in product architecture and product development in object technology and distributed computing for over 15 years.
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
