In WebLogic Workshop you create and build an application.
A WebLogic Workshop application is a J2EE Enterprise Application and ultimately produces a J2EE Enterprise Application Archive (EAR) file. An application may contain:
- one or more projects
- libraries and modules
- security roles
This topic introduces applications and their contents.
Applications
An application in WebLogic Workshop is the collection of all resources and components that are deployed as a unit to an instance of WebLogic Server. It is also the top-level unit of work that you manipulate with WebLogic Workshop IDE. In the IDE, you may have at most one application open at a time.
When you create a new application, you specify a name for the application. By default, new applications are created in the BEA_HOME/weblogic81/samples/workshop folder of your installation, but you should create your applications elsewhere so they cannot cause conflicts when upgrading to future versions of WebLogic Platform.
An application in WebLogic Workshop contains one or more projects. Except in specific cases, such as accessing remote EJBs or web services, a WebLogic Workshop application is self-contained. Components in the projects of an application may reference each other, but they may not generally reference components in other WebLogic Workshop applications.
An application — more formally called an enterprise application — is different from a web application. Web application refers to a collection of resources, typically HTML or JSP pages, that allow users to access functionality via the Web. An application may contain zero or more web applications.
When to Create a New Application
An application should represent a related collection of business solutions. For example, if you were building an e-commerce site you might design an application that includes web applications for catalog shopping and customer account management and the components that support them (Java controls, EJBs, etc.). You might also need to deploy a human resources application for use by your employees. The human resources application is not related to the e-commerce application. Therefore, in WebLogic Workshop you would probably create two applications to separate these disparate business functions.
Applications Installed with WebLogic Workshop
WebLogic Workshop is installed with an application named SamplesApp, which contains example projects that you can explore to learn about WebLogic Workshop. The SamplesApp application is located in the file system at BEA_HOME/weblogic81/samples/workshop/SamplesApp.
The following image shows the Application pane for the SamplesApp application:
To learn more about the available samples, see WebLogic Workshop Samples.
WebLogic Workshop is also installed with an application named TutorialsApp that contains components used in the product tutorials. The TutorialsApp is located in the file system at BEA_HOME/weblogic81/samples/platform/TutorialsApp.
To learn more about the available tutorials, see WebLogic Workshop Tutorials.
Projects
A project groups related files that comprise a component of an application.
In WebLogic Workshop Application Developer Edition, there are six default project types:
- Web project
- Web Service project
- Control project
- Control Deliverable project
- EJB project
- Java project
- Schema project
WebLogic Workshop Platform Edition adds the following project types:
- Portal project
- Datasync project
- Process project
WebLogic Workshop project types are defined by project templates. You may create custom project templates to meet the needs of your organization.
Web Project and Web Service Project
Web projects are typically used to expose enterprise application logic via a user interface. The user interface is constructed from Java Server Pages (JSPs), which are web pages that can interact with server resources to produce dynamic content. WebLogic Workshop defines Java Page Flows that define and contain the logic required to connect multiple JSPs. Web services are typically used to expose enterprise application logic to applications (as opposed to users). Individual web service interfaces are published via Web Services Description Language (WSDL) files.
Each Web project or Web Service project ultimately produces a J2EE web application, each of which is included in the complete WebLogic Workshop application's EAR file when the application is built for deployment.
Contents of Web projects and Web Service projects are accessed via URLs. The WebLogic Workshop application is implicit in the URL for resources within that application. For example, the index.jsp sample JSP, which is located in the file system at SamplesApp/WebApp/index.jsp, is accessed from a web browser with the following URL:
http://localhost:7001/WebApp/index.jsp
Note that the name of a project becomes part of the public URL of each resource located within that project. You should choose your project names with that in mind.
You can configure a Web or Web Service project to load by default if you do not want to require users to provide a project name as part of the URL. For example, users can access http://localhost:7001/WebApp/index.jsp by simply requesting http://localhost:7001/.
To configure a project to load by default:
1. From the Application tab, right-click on the Web or Web Service project that you would like Web Logic Server to load by default and select Properties.
2. In the Project Properties dialog, select the Use project name check box..
3. In the text box labeled Context Path, enter / and Click OK.
The SamplesApp sample application contains a sample Web project named WebApp and a sample Web Service project named WebServices.
To learn more about Java page flows and building web applications, see Getting Started with Page Flows.
To learn more about Java Web Services, see Building Web Services with WebLogic Workshop.
Note: Web projects and a Web Service projects are both J2EE web applications. Web services may be created in a web application and page flows and JSPs may be created in a web service project. The only difference between the project types is the set of supporting files the project initially contains. If you add web services to a web project or page flows or JSPs to a web service project, the necessary supporting files are automatically added to the project.
Control Project
Java controls are entities that contain business logic or provide convenient access to enterprise resources. A control project may be used to construct and package controls that are intended for use by components in other projects. For example, a custom control that provides access to a proprietary Human Resources application might be used from JSPs in a web project and also from web services in a web service project.
Each Control project ultimately produces a Java Archive (JAR) file.
The SamplesApp samples application contains a sample Control Project named ControlProject.
To learn more about Java Controls and Control Projects, see Working with Java Controls.
Control Deliverable Project
You use a control deliverable project when you want to build Java controls that will be distributed to multiple users. A control deliverable projects creates directories you can use to store help and sample files relating to the control. When you build a control deliverable project, WebLogic Workshop packages the controls of that project into a Java Archive (JAR) file along with the help and sample files that you provide in the generated help and sample directories. When users install the control, WebLogic Workshop automatically integrates the help and sample files contained in the JAR with the users existing WebLogic Workshop help installation.
To learn more about Control Deliverable Projects, see Control Deliverable Projects.
EJB Project
Enterprise Java Beans (EJBs) are Java software components of enterprise applications. The J2EE Specification defines the types and capabilities of EJBs as well as the environment (or container) in which EJBs are deployed and executed. From a software developer’s point of view, there are two aspects to EJBs: first, the development and deployment of EJBs; and second, the use of existing EJBs from client software. An EJB Project provides support for creating and deploying new EJBs.
Each EJB project ultimately produces a Java Archive (JAR) file and when an EJB project is built the EJBs in the project are automatically deployed to the development server.
The EJB Control that is a built-in control in WebLogic Workshop allows clients such as web services, JSP pages or other controls to access existing EJBs, including EJBs created in an EJB Project.
To learn more about developing EJBs with WebLogic Workshop, see Developing Enterprise Java Beans.
Java Project
A Java project is a place to develop or collect general-purpose Java code that is not directly part of special entities such as web services, controls or EJBs. The product of a Java project is a JAR file that typically holds Java classes you want to access from other parts of your application. For example, a Java Project might hold Java code for a library of string formatting functions that are used in web services and JSPs in other projects in the application.
By default, each Java project ultimately produces a Java Archive (JAR) file.
To learn more about creating a Java project, see How Do I: Create and Debug a Java Class?
Schema Project
A Schema project provides convenient, automatic access to BEA Systems' XMLBeans functionality. XMLBeans is a facility that constructs Java classes from XML Schema and allows very easy, direct and powerful manipulation of XML documents in Java. If you place an XML Schema (XSD) file into a schema project, the XMLBeans schema compiler is automatically run on the schema and the resulting JAR file is automatically placed in the Libraries folder of the application. The Java classes in the JAR file are accessible to all projects in the application. For example, a web service in a web service project in the application can reference a schema as the input type of one or more of its methods and can automatically access incoming XML documents via the XMLBeans Java APIs.
The SamplesApp samples application contains a sample Schema Project named Schemas. It contains XML Schemas used by various samples in the SamplesApp application.
Note: For XML Schemas to be available in a business process, the schemas must be imported into a Schemas project in your integration application. To learn more about using XML Schemas in integration applications, see Guide to Data Transformation.
To learn more about XMLBeans, see Getting Started with XMLBeans.
Portal projects are available in WebLogic Workshop Platform Edition.
Portals are used to provide a single point of access to enterprise applications and information that can be based on user, group and role attributes.
A Portal project is similar to a Web project in that it is used to expose enterprise application logic via a user interface. Portal projects usually contain Java Server Pages (JSPs), and they provide additional capabilities, in addition to those available in Web projects, that allow developers to define portal Web sites.
Note: A Portal project is a J2EE web application and supports the creation of Web services, page flows and JSPs. The difference between a Portal project and a Web or Web Service project is the set of supporting files the project initially contains. Portal projects contain additional files that support creation of portals.
To learn more about portals, see WebLogic Portal Overview.
To learn more about and building portal applications in WebLogic Workshop, see Getting Started with WebLogic Portal.
Datasync Project
Datasync projects are available in WebLogic Workshop Platform Edition.
A Datasync project is used to develop and manage general purpose portal services that are used in the development of personalized applications and portals. These portal services include user profiles, user segments, events, request properties, session properties, content selectors, placeholders, and campaigns. A Datasync project called data is generated when a Portal application is created.
Process Project
Process projects are available in WebLogic Workshop Platform Edition.
A business process orchestrates the execution of business logic and the exchange of business documents among back-end systems, users and trading partners (systems and users) in a loosely coupled fashion. A Process project typically contains business process (JPD) files, control files and transformation files.
To learn more about Business Process Projects, see Guide to Building Business Processes.
When to Create a New Project
As you develop an application, you may need to create new projects within the application for the following reasons:
- To separate unrelated functionality
Each project should contain components that are closely related to each other. If, for example, you wanted to created one or more web services that expose order status to your customers and also one or more web services that expose inventory status to your suppliers it would make sense to organize these two sets of unrelated web services into two projects.
- To control build units
Each project produces a particular type of file when the project is built. For example, a Java project produces a JAR file. If you want to reuse the Java classes contained in the Java project from multiple components, it would make sense to segregate the Java classes into a separate project and reference the resulting JAR file from other projects in your application.
Libraries and Modules
In addition to projects, each WebLogic Workshop application also contains two folders named Libraries and Modules. These folders can contain compiled Java code that you want to be available to the components of the application. The products of the various project types are automatically placed in the Libraries or Modules folder as appropriate. For example, the JAR file containing the XMLBeans Java classes derived form the XML Schemas in a Schema Project is automatically placed in the Libraries folder. However, you may also copy additional JAR files directly into the Libraries or Modules folders to make them available to the rest of your application.
The Libraries and Modules folders both place their contents on the application's Java class path. The main difference between the Libraries and Modules folders is that the contents of the Modules folder are automatically deployed to the appropriate instance of WebLogic Server. For example, when you build an EJB Project, the EJBs in the project are compiled and placed in a JAR file, which is then copied to the Modules folder and thereby automatically deployed to the server.
The Libraries folder is equivalent to the APP-INF/lib directory of a J2EE Enterprise Application.
Security Roles
A WebLogic Workshop application also may define security roles, which are a facet of the J2EE security framework based on security roles, principals and groups.
A human resources application might define the following categories of users: an
administrator may perform any operation, including configuring the application itself; a manager may perform HR operations on employees (add, delete, adjust compensation, etc.); and an employee may access a subset of his or her own HR records. Each of these user categories is called a security role, an abstract grouping of users that is defined by the designers of the application. When the application is deployed, an administrator will map the roles to actual security identities in the production environment.
A security role is an application-specific grouping of users, classified by common traits such as job title. When an application is deployed, roles are mapped to security identities, such as principals (identities assigned to users as a result of authentication) or groups, in the production environment. Based on this, a user has access rights to specific components and/or functions of an application based on the security role(s) to which the user's identify is mapped. The link is the actual name of the security role that is being referenced.
Following this model of role-based security, application components may be configured to allow or restrict access based on security roles. The application components do not (and should not) concern themselves with specific user or group identities. By abstracting security to roles, the actual configuration of an application's security settings can occur at runtime and requires no changes to the application code. In fact, J2EE allows configuration of security to a fine level of detail purely via declarative means by using files called deployment descriptors, so the application code doesn't even have to be aware of the actual security roles that are defined.
WebLogic Workshop allows you to define the security roles that will be used in your application. When your application is deployed, the security roles you have defined are deployed with it. If you have defined users and groups for test purposes in your development environment, those definitions are not deployed with your application. This eases testing of security configurations in the development environment but avoids the risk of leaving security roles in your application when it is deployed.
Cleaning Applications and Projects
Sometimes when you build an application or project, WebLogic Workshop does not update all of the appropriate build files. As a result, stale artifacts can exist between builds. This could happen for any number of reasons like moving or deleting files while WebLogic Workshop is closed. If you believe that any of your projects are exhibiting strange behavior, you can use the Clean utility to ensure that WebLogic Workshop removes all outdated build files and references. After cleaning, you can re-build the application or individual project and be sure that each build file is fresh.
To clean an application:
1. From the Application tab in WebLogic Workshop, right-click the application folder and select Clean Application.
To clean a project:
1. From the Application tab in WebLogic Workshop, right-click on the project folder representing the project you would like to clean and select Clean.
Comments
Post a Comment