In WebLogic Workshop you create and build an application.
A D V E R T I S E M E N T
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:
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.
In the Project Properties dialog, select the Use project name
check box..
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 Project
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:
From the Application tab in WebLogic Workshop, right-click the
application folder and select Clean Application.
To clean a project:
From the Application tab in WebLogic Workshop, right-click on the
project folder representing the project you would like to clean and select
Clean.
Share And Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.
Keywords:
Applications and Projects, WEBLOGIC, WebLogic, WebLogic tutorials, WebLogic tutorial pdf, history of WebLogic, How To Deploy An Application Using WebLogic , learn WebLogic
