This topic discusses a number of issues that are particularly of interests to experienced EJB developers who have recently switched to using the WebLogic platform. It includes the following sections:
If you have existing EJBs that you want to use in WebLogic Workshop, you can import EJBs or add EJBs as modules to your WebLogic Workshop applications. If you are switching from a WebLogic Server environment, you could also WebLogic Workshop-enable the Server domain.
If you want to have existing EJBs available in the WebLogic Workshop for further development, you can import EJBs into EJB project. To import EJBs, you need the EJBs' source code and the corresponding EJB JAR(s). An Import Wizard guides you through this process and, for each EJB, translates the EJB's source file into one bean file with an ejb extension, inserting the necessary ejbgen tags to define interfaces, deployment descriptor files, CMP and entity relation accessor methods, and so forth.
For more information on ejbgen tags, see Getting Started with EJB Project. For step-by-step instructions on importing EJBs, see How Do I: Import an Enterprise JavaBean?
If you have existing EJBs that you want to use within the application, but you don't need to do further development on these EJBs, you can add the EJB JAR as a module. When you add the EJB JAR as a module, the EJBs become application-scoped, that is, they are deployed as part of the application. New EJBs that you develop in EJB project can reference these EJBs using the local or remote interfaces, and you can create EJB controls to extend either interfaces (see below). Unlike importing EJBs, when you add the EJB JAR as a module, the JAR is added as is.
For step-by-step instructions on adding EJBs as a module, see How Do I: Add an Existing Enterprise JavaBean to an Application?
If you previously worked with WebLogic Server, you can WebLogic Workshop-Enable this domain, which allows you to continue using this domain in WebLogic Workshop. EJBs that are deployed on the server can be used in a WebLogic Workshop applications through these EJBs' remote interfaces.
For step-by-step instructions on enabling the server domain, see How Do I: WebLogic Workshop-Enable an Existing WebLogic Server Domain? If you want to create EJB controls for globally-scoped (or server scoped) EJBs in your application, you will need to add the corresponding EJB JAR as a library. For step-by-step instructions on adding EJBs as a library, see How Do I: Add an Existing Enterprise JavaBean to an Application?
When you are ready to build, you can build each EJB project in your application separately, or you can build the entire application. When you run a build:
In WebLogic Workshop, EJB JARs are deployed on the server as part of the application. You can verify that the EJBs are correctly deployed using the WebLogic Console, which you can access by choosing WebLogic Server-->WebLogic Console from the Tools menu. When an EJBs has its remote interfaces defined, it is also globally-scoped and can be referenced from other applications. Finally, it is also possible to deploy a stand-alone EJB JAR on the WebLogic Server instead using the WebLogic Console.
For step-by-step instructions on checking deployed EJBs through the WebLogic Server Console, see How Do I: Test an Enterprise JavaBean? For step-by-step instructions on deploying a stand-alone, EJB JAR on the WebLogic Server Console, see How Do I: Deploy a Stand-Alone Enterprise JavaBean on WebLogic Server?
After building and deploying an EJB, WebLogic Workshop offers various alternatives to test the EJB. One approach is to create a web application to test the EJB. This requires that you develop the web applications in parallel to take into account changes to the EJB. An alternative is to use a test web service, with which you can directly invoke the EJB methods. The test web service is generated by WebLogic Workshop on the basis of an EJB Control. An EJB control is a WebLogic Workshop component used to locate and reference an EJB on the basis of its home or remote interfaces, and JNDI name or an application relative path. When you change the definition of the interfaces that the EJB control extends, you can simply rebuilds the EJBs, which triggers EJB redeployment, and regenerate the web service to incorporate the changes to the interface definitions.
For step-by-step instructions on using EJB controls and Test Web Services, see How Do I: Test an Enterprise JavaBean? The EJB Tutorial, in particular Step 9: Build and Run a Web Service Application, gives a specific example of creating and using an EJB control and a test web service. For more information on the debugger, see Debugging Your Application. For more information one EJB controls and Java Control projects, see Creating a New EJB Control and How Do I: Use an Enterprise JavaBean in a Web Application? The latter topic and the EJB Tutorial, in particular Step 4: Run a Web Application, also show how to use EJB controls or JNDI API to call an EJB from a web application.