Developing Applications with WebLogic Workshop
The topics in this section address the basic concepts you need to
understand to build entrprise-class applications with WebLogic Workshop.
A D V E R T I S E M E N T
What Can I Build with WebLogic Workshop?
The WebLogic Workshop IDE builds enterprise-class applications that run in
the WebLogic Workshop runtime. The applications you build in WebLogic
Workshop typically expose systems and data within or between enterprises,
typically via web applications and/or web services.
As an example,
considering an express shipping company. Such a company might want to expose
shipment scheduling, tracking and billing data to its business partners via
web services so that partners' applications can access the data directly.
The company also might want to expose tracking information via one or more
web applications so that shipment originators and recipients can check the
status of shipments from a web browser. WebLogic Workshop makes it easy to
construct common functionality for both applications and then expose that
functionality with appropriate interfaces.
In WebLogic Workshop Application Developer Edition, the core components
Enterprise Java Beans (EJBs)
In WebLogic Workshop Platform Edition you can also build:
WebLogic Integration components: business processes, data
transformations, integration-specific controls
What is an "Enterprise-class" Application?
"Enterprise-class" applications exhibit specific attributes. The J2EE
foundation on which the WebLogic Platform and WebLogic Workshop is built
provides reliability, availability and scalability as well as caching,
security and transaction support. "Enterprise-class" also refers to
additional specific attributes with regard to web services and web
Enterprise-class web services are loosely-coupled and coarse-grained and
optionally asynchronous. To learn more about how WebLogic Workshop enables
these attributes, see
Why Build Web
Services with WebLogic Workshop?.
An enterprise-class web application exhibits a separation between its
application logic and its presentation logic. WebLogic Workshop enables this
separation with Java page flows, which are based on the well-established
Model-View-Controller pattern. To learn more about Java page flows, see
Developing Web Applications.
How WebLogic Workshop Simplifies Development
As you read about the various components of a WebLogic Workshop
application in the sections that follow, there are two common threads you
will notice: the use of Java classes with powerful custom Javadoc
annotations and the presence of custom design and development tools for each
Each of the major components of a WebLogic Workshop application is
expressed as a single Java class that is annotated with special Javadoc
annotations (also called Javadoc annotations). The Javadoc annotations
indicate to the WebLogic Workshop runtime that the component developer wants
to utilize or configure particular features of the runtime.
For example, the @common:operation
Javadoc annotation on a method in the Java class defining a web service
indicates that that method should be exposed as an operation in the web
service's WSDL file. As another example, the @jpf:forward
Javadoc annotation on a method in the Java class defining a Java page flow
indicates the page to which the user should be directed when that action is
invoked. Via these annotations, WebLogic Workshop hides the vast majority of
the complexity of implementing sophisticated applications. The Javadoc
annotations are typically managed for you; they are represented as
"properties" in the IDE.
The fact that each component type is expressed in a single Java file is
also significant. In WebLogic Workshop, you never have to manage generated
stub files or deployment descriptors. The WebLogic Workshop runtime analyzes
the annotations and performs all of the required infrastructure plumbing
automatically. As a developer, you can focus completely on the business
logic of your application.
While each of the core components of a WebLogic Application is expressed
as a 100% pure Java class, WebLogic Workshop uses different filename
extensions to denote the component types. For example, a web service is
stored in a file with the .jws extension
indicating Java Web Service.
To learn more about the filename extensions you will encounter while
working with WebLogic Workshop, see
Component-Specific Development Tools
WebLogic Workshop provides customized editors for all of the component
types. Most component types have a dedicated Design View, which provides an
intuitive graphical view of the component under development and the other
components with which it interacts. WebLogic Workshop also provides
customized Source Editors with all of the features developers expect in an
IDE including source code completion, syntax coloring and error and warning
indications in real-time. In the cases where multiple languages appear in
the same source file (for example, when fragments of XML are used in a web
service source file to specify XML <-> Java mapping), the Source Editor
automatically adjusts its behavior to the language of the file segment in
which the cursor is currently located.
Finally, WebLogic Workshop provides full two-way editing: any changes you
make in the source view of a component are immediately reflected in the
graphical view and vice versa.
All of the entities in the diagram that include the word "control" are
Java controls. A Java control encapsulates business logic or facilitates
access to an enterprise resource. Once a Java control has been created, that
control can be used easily and consistently from a web service, a page flow, a
portal, a business process or another Java control.
A Java control is a Java class that is annotated with special Javadoc
annotations that enable features in the control when it is executed in the
WebLogic Workshop runtime. A Java control may define methods and events. From
the application developer's point of view, the consistent architecture of Java
controls serves to greatly reduce the complexity of using the enterprise
resources or business logic they encapsulate. Since all Java controls are Java
classes, productivity aids such as source code-completion are available
throughout the WebLogic Workshop IDE to streamline the development process.
When designing a Java control, you can see the relationship between the
control, its client, and any other controls in the IDE's Design View. All of the
important development activities can be accomplished by drag-and-drop or
WebLogic Workshop includes several built-in controls that facilitate access
to commonly used enterprise resources including databases, Enterprise Java Beans
(EJBs), external web services and Java Message Service (JMS) queues and topics.
You can create custom Java controls to encapsulate any business logic that is
required by your application.
Business or application logic might be contained in a variety of components,
including EJBs or other applications. If you have the choice, however,
encapsulating business or application logic in a Java control leverages the full
power of the WebLogic Workshop architecture, including asynchronous execution
and conversations ("conversation" is the WebLogic Workshop model for a
To learn more about Java controls, see
Working with Java Controls.
A Web Service is a piece of application logic that is exposed via standards
such as Simple Object Access Protocol (SOAP; a specific dialect of XML)) and Web
Services Description Language (WSDL). To use a web services, an application
sends an XML message that requests an operation be performed. The application
typically receives an XML response indicating or containing the results of the
WebLogic Workshop makes it very easy to create and deploy web services that
adhere to web service standards, to access and process the XML messages received
by web services and to format XML responses. Specifically, WebLogic Workshop
provides two powerful technologies for manipulating XML in web services: XML
Maps using XQuery for simple inline Java <-> XML mapping specifications and
XMLBeans for comprehensive Java <-> XML binding.
In WebLogic Workshop, a web service is a Java class that is annotated with
special Javadoc annotations that provide simplified access to advanced web
service features such as asynchrony, conversations, security and reliable
messaging. Like all WebLogic Workshop components, Java web services can use Java
controls to access business logic or enterprise resources. Everything you need
to completely define a web service's operations, protocols, message formats and
runtime behavior is contained in the web service's JWS file. There are no
deployment descriptors to decipher and no external file generation to manage.
WSDL generation for web services is completely automatic.
When designing a web service, the IDE's Design View shows you the
relationship between the web service, its client, and any controls used by the
web service. All of the important development activities can be accomplished by
drag-and-drop or context-menu actions.
To learn more about Java web services and the advanced features available to
web services in WebLogic Workshop, see
While this topic is concerned mostly with components you build with WebLogic
Workshop, it is important to note that WebLogic Workshop can easily
inter-operate with web services built with other tools. One of the built-in Java
controls WebLogic Workshop provides is the Web Service control. WebLogic
Workshop can automatically generate a Web Service control from any valid WSDL
file. Subsequently, the generated Web Service control can be used from any
WebLogic Workshop component to access the remote web service as though it were a
simple Java class.
To enable construction of dynamic, sophisticated web applications, WebLogic
Workshop provides Java page flows. A page flow links together multiple
web pages in a web application and provides a central control mechanism that
coordinates the user's path through the pages and the associated flow of data.
A page flow is a Java class that is annotated with special Javadoc
annotations that controls the behavior of the web application Page flows use
methods, and in most cases, forms and form beans (Java classes containing the
data associated with a form) to manage navigation and state. A directory that
contains a page flow class typically also includes one or more Java Server Pages
(JSPs). The JSP files can reference custom WebLogic Workshop JSP annotations to
raise actions, bind user interface components to data and access other
application facilities. The actions referenced in a JSP correspond to action
methods that are defined in the page flow class. These action methods implement
code that can result in site navigation, data management, or invocation of
business logic via Java controls. Significantly, the business logic in the page
flow class is separate from the presentation code defined in the JSP files.
When designing a page flow, the IDE's Flow View shows the relationship
between the pages in the web application and the actions that link the pages.
All of the important development activities can be accomplished by drag-and-drop
or context-menu actions. WebLogic Workshop also provides wizards to create
specific types of page flows, generating the Java and JSP files that serve as a
starting point for sophisticated applications.
Page flows are based on the Struts architecture, which is itself based in the
popular Model-View-Controller user interface design pattern. Page flows add
powerful, scalable support for state management and page flows and the JSPs they
manage also have complete access to Java controls to access business logic or
To learn more about Java page flows, see
Developing Web Applications.
Enterprise Java Beans
Enterprise Java Beans (EJBs) are server-side 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.
WebLogic Workshop enables you to create new session, entity and message
driven EJBs using a custom Design View. To learn how to create EJBs in WebLogic
Developing Enterprise Java Beans.
WebLogic Workshop also provides a built-in control, called the EJB control,
that makes it easy to use an existing, deployed EJB from your application. To
learn more about the EJB control, see
WebLogic Workshop Platform Edition adds the WebLogic Workshop Portal
Extensions™ which allow you to build portals and portal resources using the
WebLogic Workshop IDE. The portals you build are deployed using WebLogic Portal.
A portal represents a Web site that provides a single point of access to
applications and information and may be one of many hosted within a single
WebLogic Portal server.
Portals are becoming more and more important to companies who need to provide
employees, partners, and customers with an integrated view of applications,
information, and business processes. WebLogic Portal meets these needs, allowing
companies to build portals that combine functionality and resources into a
single interface while enforcing business policies, processes, and security
requirements, and providing personalized views of information to end users.
From an end user perspective, a portal is a Web site with pages that are
organized by tabs or some other form of navigation. Each page contains a nesting
of sub-pages, or portlets—individual windows that display anything from static
HTML content, dynamic JSP content or complex Web services. A page can contain
multiple portlets, giving users access to different information and tools in a
single place. Users can also customize their view of a portal by adding their
own pages, adding the portlets they want to it, and changing the look and feel
of the interface.
The business problem that portals solve is illustrated in the following
example. A company has the need for several types of Web presence: an Intranet
for its employees, a secure site for interactions with partners, and a public
Web site. WebLogic Portal’s flexible portal network architecture supports
multiple implementation choices which allow re-use of resources across portals.
To learn more about building portals in WebLogic Workshop, see
WebLogic Portal Overview.
WebLogic Integration Components
WebLogic Workshop Platform Edition adds the capability to build WebLogic
Integration components using the WebLogic Workshop IDE.
WebLogic Integration enables you to design business processes that span
applications, users, enterprise networks, and trading partners.
WebLogic Integration's business process management (BPM) functionality
enables the integration of diverse applications and human participants, as well
as the coordinated exchange of information between trading partners outside of
the enterprise. A business process is a graphical representation of a
business process. Business processes allow you to orchestrate 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.
WebLogic Workshop Platform Edition enables you to create business processes
graphically, allowing you to focus on the application logic rather than on
implementation details as you develop.
A business process can utilize data transformations using either a
query or an eXtensible Stylesheet Language Transformation (XSLT). WebLogic
Workshop Platform Edition includes a data mapper to create data transformations
graphically. From the graphical representation of a data transformation,
WebLogic Workshop generates a query. The generated query is invoked at runtime
by the business process to transform data. A query is expressed in the XQuery
language—a language defined by the World Wide Web Consortium (W3C) that provides
a vendor independent language for the query and retrieval of XML data.
WebLogic Integration also provides a standards-based integration solution for
connecting applications both within and between enterprises. WebLogic
Integration provides the following tools for integrating applications:
application views, the Adapter Development Kit (ADK), EIS adapters
and Application View Controls. By using these tools, you can integrate
all your enterprise information systems (EIS). Typical IT organizations use
several highly specialized applications. Without a common integration platform,
integration of such applications requires extensive, highly specialized