Skip to main content

Developing Applications 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 are:
  • Java controls
  • Web services
  • Web applications
  • Enterprise Java Beans (EJBs)
In WebLogic Workshop Platform Edition you can also build:
  • Portal Applications
  • 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 applications:

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 component type.

Javadoc Annotations

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 WebLogic Workshop File Types.

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.

Java Controls

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 context-menu actions.

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 long-running transaction).

To learn more about Java controls, see Working with Java Controls.

Web Services

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 operation.


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 Building Web Services.


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.

Web Applications

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 enterprise resources.


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 Workshop, see 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 EJB Control.

Portal Applications

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 development efforts.

Comments

Popular posts from this blog

Asynchronous Vs. Synchronous Communications

Synchronous (One thread):   1 thread -> |<---A---->||<----B---------->||<------C----->| Synchronous (multi-threaded):   thread A -> |<---A---->| \ thread B ------------> ->|<----B---------->| \ thread C ----------------------------------> ->|<------C----->|

WebSphere MQ Interview Questions

What is MQ and what does it do? Ans. MQ stands for MESSAGE QUEUEING. WebSphere MQ allows application programs to use message queuing to participate in message-driven processing. Application programs can communicate across different platforms by using the appropriate message queuing software products. What is Message driven process? Ans . When messages arrive on a queue, they can automatically start an application using triggering. If necessary, the applications can be stopped when the message (or messages) have been processed. What are advantages of the MQ? Ans. 1. Integration. 2. Asynchrony 3. Assured Delivery 4. Scalability. How does it support the Integration? Ans. Because the MQ is independent of the Operating System you use i.e. it may be Windows, Solaris,AIX.It is independent of the protocol (i.e. TCP/IP, LU6.2, SNA, NetBIOS, UDP).It is not required that both the sender and receiver should be running on the same platform What is Asynchrony? Ans. With messag...

Advantages & Disadvantages of Synchronous / Asynchronous Communications?

  Asynchronous Communication Advantages: Requests need not be targeted to specific server. Service need not be available when request is made. No blocking, so resources could be freed.  Could use connectionless protocol Disadvantages: Response times are unpredictable. Error handling usually more complex.  Usually requires connection-oriented protocol.  Harder to design apps Synchronous Communication Advantages: Easy to program Outcome is known immediately  Error recovery easier (usually)  Better real-time response (usually) Disadvantages: Service must be up and ready. Requestor blocks, held resources are “tied up”.  Usually requires connection-oriented protocol