| Oracle® Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal 10g Release 3 (10.3.2) Part Number E14235-02 |
|
|
View PDF |
| Oracle® Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal 10g Release 3 (10.3.2) Part Number E14235-02 |
|
|
View PDF |
This chapter describes the key actors and logical parts of a federated portal and discusses how they interact. The information in this chapter informs many of the best practices recommended for developers of federated portals. It is helpful to review this chapter before reading Chapter 14, "Other Topics and Best Practices." In addition, this chapter discusses a key standard technology upon which federation relies: Web Services for Remote Portlets (WSRP).
This chapter includes these topics:
The key actors in a federated portal are producers, consumers, and end users, as illustrated in Figure 3-1.
Figure 3-1 Components of a Federated Portal
A consumer is a web application that collects remote portlets and offers them in a unified portal to end users who use a browser to view and interact with the portal. In addition to federating portlets, WebLogic Portal lets you federate books and pages. See Section 3.2, "Federating Books and Pages" for more information.
Typically, a consumer does not include the business logic, data, or user interface parts of a portlet: it simply collects user interface markup delivered from producers and presents that user interface to users.
Tip:
Although most business logic processing occurs in producer applications, you can write consumer-side classes called interceptors that let you programmatically examine the content of a WSRP message and take specific action based on that content. Interceptors are discussed in Chapter 9, "The Interceptor Framework."Consumers are administration-centric. This means that administrators, rather than developers, typically focus their time on consumers. Administrators locate and consume remote portlets, manage users, set up entitlements, and so on.
A producer is also a web application, typically running on a remote system from the consumer. The producer acts as a container for portlets that are offered to consumer portals. The producer is where the user interface, data, and business logic for remote portlets reside. While a consumer is administration centric, a producer is application centric. This means that developers write the actual portlet code and deploy those resources on producers.
Tip:
All WebLogic Portal applications are, by default, both consumers and producers. This means that every WebLogic Portal application is capable of hosting remote portlets and consuming them.For more information on producers and consumers, see Section 3.4, "Understanding Producers and Consumers".
WebLogic Portal has extended the WSRP protocol to include the ability to federate books and pages. This feature is useful if you have large numbers of portlets that you want to federate. You can group the portlets in books and pages in the producer application, and consume them as a group, rather than one at a time. For more information, see Chapter 4, "Creating Remote Portlets, Pages, and Books" and Chapter 18, "Adding Remote Resources to the Library."
Web Services for Remote Portlets (WSRP) is a web services protocol for aggregating content and interactive web applications from remote sources. WSRP is a key standard that underlies federated portals. Essentially, WSRP allows remote, distributed portlets to be brought together at runtime into a unified portal page.
Web Services for Remote Portlets provide both application and presentation logic. This is different from standard web services, or data-oriented web services, which contain business logic but lack presentation logic and thus require that every client implement that logic on its own.
While the data-oriented approach works well in many implementations, it is not well suited for dynamically integrating business applications. For example, to integrate an order status web service into a commerce portal, you would need to write code to display the results of the status services into the portal. Using WSRP, with the presentation logic included in the web service, you can achieve the aggregation of applications and services dynamically. You no longer need to develop the presentation logic in order to do the integration; you can simply request the order status service to show up as a portlet inside the commerce portal at a predetermined location.
Tip:
WLP fully supports the WSRP 2.0 OASIS standard. OASIS, the Organization for the Advancement of Structured Information Standards, is responsible for creating the WSRP standard. To read more about WSRP 2.0, including the full technical specification, go to:
http://www.oasis-open.org/committees/wsrp.One way to understand WSRP is to compare it with another web protocol, HTTP. The most familiar use of HTTP is viewing and interacting with remote web applications using a browser. Using HTTP, browsers communicate with remote HTTP servers to post data (for example, by submitting forms) and to retrieve markup (typically, HTML). WSRP is a similar protocol between server and client applications. In WSRP terminology, the server is called a producer. It hosts services, typically portlets, that clients, or consumers, communicate with.
Like a browser in the HTTP analogy, the consumer retrieves markup and submits user interactions to the producer. The producer hosts actual portlets while the consumer contains proxies for those portlets. Consumers use WSRP to collect and present markup from the remote portlets to end users who interact with that markup. To an end user, a remote or proxy portlet is indistinguishable from a local portlet.
WSRP consumers are more sophisticated than browsers, however. Unlike browsers, consumers can:
Offer features like personalization, customization, and security
Handle markup fragments rather than entire HTML documents
Combine markup from different producers into a single page and apply consistent consumer-specific layouts and styles to that page
In summary, the WSRP protocol defines a set of web services that WSRP producers implement. Consumers view and interact with these web services; they retrieve user interface fragments from the producer, display the fragments, and allow users to interact with them. The WSRP protocol allows consumers to act as clients for applications hosted by producers.
This section focuses on the producer and consumer implementations for WebLogic Portal. This section includes these topics:
A producer is a container web application that hosts portlets. Through proxy portlets (called "remote portlets" in WLP), consumers collect and present portlets hosted on producers to users. All application code (backing files, Java classes, controls, EJBs, and so on) resides on the producer. Consumers only receive fragments of markup from producers which are collected and presented to users.
Figure 3-2 illustrates the components of a federated portal. Note that the WebLogic Portal WSRP implementation allows the addition of typical WebLogic Portal services, such as personalization, customization, and user management. This means that remote portlets are given the same look and feel and the same levels of portal security as local portlets.
Figure 3-2 Web Services Between Producer and Consumer
Tip:
Every WebLogic Portal contains both producer and consumer implementations. That is, all WebLogic Portals can function as producers and consumers. For an in-depth technical explanation of the WebLogic Portal producer and consumer implementations, refer to the technical white paper, Inside WSRP athttp://www.oracle.com/technology/pub/articles/dev2arch/2005/03/inside_wsrp.html.WebLogic Portal supports two kinds of producers: simple and complex. Before describing these two kinds of producers, it is helpful to understand the parts of the WSRP protocol and which operations must be implemented in a producer (required operations) and which are optional.
Table 3-1 lists the set of required and optional operations defined by the WSRP protocol. Note that the minimum requirement for a WSRP-compliant producer is to implement the required service description and markup operations. As you will see, WebLogic Portal simple and complex producers differ in the kinds of operations they support.
Table 3-1 Required and Optional WSRP Operations
| WSRP Protocol | Operations | Implemented Methods |
|---|---|---|
|
Required for WSRP |
Service description operations Markup operations |
getServiceDescription() initCookie() getMarkup() performBlockingInteraction() |
|
Optional for WSRP |
Registration Portlet Management |
register() modifyRegistration() deregister() getPortletPropertyDescription() setPortletProperties() getPortletProperties() clonePortlet() destroyPortlets() |
|
Extensions (Add new operations to the WSRP protocol.) |
Event Handling Render Dependencies |
handleEvents() getRenderDependencies() |
A simple producer supports only some basic features of the WSRP protocol. These basic features do not require the producer to be deployed in a full WebLogic Portal domain. You can, for example, deploy a simple producer in a basic WebLogic Server domain.
Tip:
For detailed information on configuring a simple producer in a WebLogic Server domain, see Chapter 8.A simple producer:
Does not depend upon WebLogic Portal features – A simple producer cannot take advantage of WebLogic Features features such as user management and personalization.
Does not depend on WebLogic Portal APIs – Again, a simple producer cannot rely on any WebLogic Portal dependencies.
Does not require registration – Registration allows a producer to associate portlets and any portlet customization data with the consumer that is interacting with it. The producer can also use the registration to tailor the scope of the portlets offered to specific consumers.
Does not support event handling – You cannot use the event handling API with a simple producer.
Despite these limitations, you might want to use a simple producer for the following reasons:
To WSRP-enable non-portal projects, such as WebLogic Server projects
To offer portlets without actually installing WebLogic Portal
The section Section 8.2, "Using WSRP in a Basic WebLogic Server Domain" describes how to configure a (non-portal) WebLogic Server environment as a WSRP producer so that you can expose portlets based on Struts or Java Page Flows. The exposed portlets can then be consumed as remote portlets running in a regular WebLogic Portal Domain.
Note:
Page flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. Apache Struts is also an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.A complex producer supports the complete WSRP 1.0 protocol plus some extensions for interportlet communication, portlet look and feel, and other features. A complex producer also lets you take advantage of other WebLogic Portal features, such as personalization, customization, and user management security features. By contrast, simple producers cannot take advantage of these WebLogic Portal features.
By default, all WebLogic Portal applications are complex producers. Portlets that are exposed in a complex producer can use the APIs and features that are available in any WebLogic Portal application.
Tip:
In some cases, it is inappropriate to use API calls in portlets deployed on a producer. This is because a producer does not have access to portal artifacts, such as books and pages, in that are deployed in consumer applications. See Chapter 14 for information on best programming practices for portlet development in producers.Typically, a complex producer:
Requires registration – Registration allows a producer to associate portlets and any portlet customization data with the consumer that is interacting with it. By deploying consumer entitlements, the producer can also use the registration to tailor the scope of the portlets offered to specific consumers. For detailed information on consumer entitlements, see Chapter 11, "Consumer Entitlement." By default, registration is enabled; however, you can disable registration by setting the <registration required> element in the /WEB-INF/wsrp-producer-config.xml file to false.
Supports a management interface – By default, the WebLogic Portal management interface is enabled; however, you can disable the management interface by setting the <portlet-management required> element to false in the file /WEB-INF/wsrp-producer-config.xml.
Supports interportlet communication – Extensions that support event handling allow remote portlets to communicate with one another.
Supports portlet render dependencies – WebLogic Portal allows you to specify certain dependencies associated with individual portlets, such as Cascading Style Sheets (CSS files) and script files, such as JavaScript (JS) files.
A complex producer includes the required WSRP interfaces, optional interfaces, and some extended interfaces. A simple producer implements the required interfaces. A complex producer requires WebLogic Portal, but a simple producer can be deployed in a basic WebLogic Server domain. Figure 3-3 illustrates these relationships.
Table 3-1 compares the capabilities of standard and complex producers.
Note:
Page flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.Table 3-2 Comparison of Producer Features
| Feature | Complex Producer | Simple Producer |
|---|---|---|
|
Java portlets |
Yes |
No |
|
Page flow portlets |
Yes |
Yes |
|
Registration |
Required |
Not Supported |
|
Support for URL rewriting (producer and consumer) |
Yes |
Yes |
|
Support for portal administration |
Yes |
No |
|
Support for JSP portlets |
Yes |
No |
|
Support for backing files |
Yes |
No |
|
Support for JSF portlets |
Yes |
Yes |
|
Support for Struts portlets |
Yes |
Yes |
As previously noted, all WebLogic portals are, by default, able to consume portlets hosted on producers. The WebLogic Portal consumer implementation is closely integrated into the WebLogic Portal framework.
To consume a remote portlet hosted on a producer, a consumer must ask a producer for information about the portlets it offers. The consumer first contacts a producer using the producer's WSDL URL. This initial contact verifies the availability of the producer and its services. Next, the consumer asks the producer for a description of the portlets it offers. The producer responds to the consumer with a SOAP message that describes the portlets and associated metadata that are offered by the producer. This communication is illustrated in Figure 3-4.
Figure 3-4 Getting the Service Description for a Producer
After a consumer receives a producer's metadata, the metadata is added to the consumer enabling you to create remote portlets. A remote portlet is a proxy to a portlet hosted on a producer. When a remote portlet is added to a portal or desktop, the WebLogic Portal framework uses the WSRP protocol to present the portlet to portal users. To users, remote portlets look and feel just like local portlets; users are not aware that a given portlet is hosted remotely. Furthermore, remote portlets inherit the particular styles, layouts, and themes from the portal in which they reside. To the user, this integration is seamless.
Tip:
As noted previously, WebLogic Portal lets you create consumer-side classes called interceptors. Interceptors let you programmatically examine the content of a WSRP message and take specific action based on that content. Interceptors are discussed in Chapter 9, "The Interceptor Framework."WebLogic Portal consumers handle cookies by following the prescriptions of RFC2109:
A Set-Cookie response header whose NAME is the same as a previous cookie, and whose Domain and Path attribute values exactly (string) match those of the previous cookie, will replace the old cookie with the new one.
If the Set-Cookie has a value for Max-Age of zero, the (old and new) cookie is discarded.
Otherwise cookies accumulate until they expire (resources permitting), at which time they are discarded.
Cookies are sent based on the specified request-host (including request-URI) and should be sent until they expire.
In WSRP, cookies are specific to the portletHandle and the end user on whose behalf the consumer is invoking the producer and may only be resupplied for this specific pair (the portletHandle is relaxed to one from a group for cookies returned from initCookie() when ServiceDescription.requiresInitCookie=perGroup.)
A remote portlet goes through a well defined life cycle. The steps of this life cycle that are executed depend on which of the following scenarios is requested:
The portlet is simply being rendered (or re-rendered).
A user is interacting with the portlet (submitting a form, for instance).
An event is fired.
The portlet has render dependencies
It is important to realize that these life cycle phases are decoupled from one another. As explained later in this section, this decoupling has implications for developers writing portlets hosted on producers. For example, you cannot expect a portal to receive the same HTTP response or request for the render phase as it receives for an interaction.
This section does not address the ways in which interceptors can influence the remote portlet life cycle. Interceptors are consumer-side classes that intercept WSRP messages and allow you to programatically take specific actions based on the content of those messages. Interceptors are discussed in Chapter 9.
Tip:
The information in this section informs many of the best practices for developers discussed in Chapter 14, "Other Topics and Best Practices." It is particularly important for developers creating portlets in a producer to understand the life cycle of a remote portlet. By understanding this life cycle, you will avoid making unwarranted assumptions and avoid common mistakes.This section includes the following topics:
Section 3.5.1, "Rendering a Remote Portlet"
Rendering occurs independently of user interaction in a remote portlet. The render phase does not allow a remote portlet's state to change. It happens, for instance, when a portal page is refreshed.
Section 3.5.2, "Interacting With a Remote Portlet"
The interaction phase occurs when a user interacts with a remote portlet, for example, by submitting a form or clicking a link.
Section 3.5.3, "Rendering Versus Interaction"
This section summarizes the differences between rendering and interaction.
Section 3.5.4, "Interportlet Communication with Events"
A third life cycle for remote portlets occurs when events are fired. Events provide the best mechanism for interportlet communication between remote portlets.
Section 3.5.5, "Retrieving Render Dependencies"
A fourth life cycle for remote portlets occurs a portlet deployed on a producer includes render dependencies.
Tip:
This section provides an overview of the remote portlet life cycle phases. For an in-depth technical review of this subject, refer to the white paper, Inside WSRP at
http://www.oracle.com/technology/pub/articles/dev2arch/2005/03/inside_wsrp.html.A well defined series of steps occurs whenever a remote portlet is rendered in a consumer portal. Anytime a portlet needs to be re-rendered in exactly the same state (for example, if the user simply refreshes a page), the rendering phase is executed. If a user directly interacts with a remote portlet, then a different phase, called the interaction phase is triggered. The interaction phase is discussed in the next section.
With a typical (non-federated) web application, when you send a request to a JSP, for instance, you receive back the markup for the requested page. In a federated portal, the user is viewing a page that consists of markup fragments received from portlets hosted on producers (or, possibly a mix of local portlets and portlets deployed on producers). The consumer's job is to contact the producers, retrieve their markup, and render it in a unified portal page.
In Figure 3-5 a portlet exists on a producer, and a proxy for that portlet (a remote portlet) has been created in a consumer portal. The sequence of steps needed to render the portlet in the consumer are listed, and discussed in the following sections.
To render a remote portlet, a consumer must first compose a SOAP message to send to the producer. These initial steps include:
Find producer metadata.
The consumer's first job is to find the metadata for a producer. When a developer or administrator creates a remote portlet, metadata about each producer is received and stored internally by WebLogic Portal (on the consumer).
Collect the portlet state. The state consists of a view state and a navigational state:
View state – This includes the mode (view mode or edit mode) and the state (minimized or maximized).
Navigational state – For example, if a user has already filled in a form and submitted it, the navigational state reflects the fact that the user has moved from page one to page two of the portlet. Knowledge of this state allows remote portlets to be re-rendered correctly any number of times.
Collect all cookies.
Just as a browser acts as a client to a web server, a consumer acts as a client to a producer. For example, a browser maintains cookies that keep track of sessions on the server. In the same way, a consumer maintains cookies that keep track of the producer sessions for each user of the portal. For each user interacting with a consumer, the consumer maintains one session with each producer.
Create a SOAP message.
All of the information gathered by the consumer must be formed into a SOAP message and sent to the producer.
After the producer receives the SOAP message from the consumer, the producer must take the following steps to render the requested portlet and return the portlet's markup to the consumer.
Set up servlet request and response objects.
Establish a session.
Establish the portlet state.
In steps 1, 2, and 3, the producer creates an HTTP environment for the portlet. Because the producer receives a SOAP request, and not an HTTP request, the producer must take the information in the SOAP request and recreate the appropriate HTTP environment for the portlet, including such things as the servlet request and response objects, the session, and the portlet state.
Enable portal API support (optional).
The producer must decide whether or not to offer complex features. WebLogic Portal has implemented WSRP extensions and optional interfaces. These extensions and options allow WebLogic Portal producers to offer features such as user management, entitlements, portlet preferences, and event handling. In some cases, you may want to deploy a producer portal without these extra capabilities; therefore, the producer must determine whether or not to enable them. For more information on simple versus complex producers, see Section 3.4, "Understanding Producers and Consumers".
Create a URL rewriter.
In a traditional web application, URLs in, for instance, JSP pages, always point to the web server hosting the JSP page. In a federated portlet, URLs must always point back to the consumer, not to the producer. This is because the producer might, in fact, be inaccessible to the user clients. The producer may be located behind a firewall, for instance. To properly manage URLs, the producer contains URL rewriters that know how to create URLs that are consumer oriented.
Tip:
If you are developing portlets in a producer, always be sure to use WebLogic Portal APIs and tags to create URLs. These APIs and tags know how to generate URLs so that they function properly in a federated environment. For more information, see Section 14.4, "Avoid Coupling by URL".Generate markup for the portlet.
At this stage, the producer renders the portlet. The producer may have created a new session for the portlet or added new cookies. The producer collects all this information and generates a response to the consumer.
Collect markup and the session ID (if one was created), and send this data back to the consumer.
The consumer receives from the producer markup fragments from the producer. The consumer must take these fragments and compose them into a portal page that can be displayed to the user. To do this, the consumer takes these final steps:
Collect cookies sent from the producer.
Collect the session ID for each portlet.
Rewrite markup (optional).
Write markup to the response.
This cycle repeats each time the portlet is rendered, as long as caching is not enabled on the consumer.
Just as with the rendering life cycle described in the previous section, interaction with a remote portlet follows a well-defined series of steps. Interaction occurs, for example, when a user submits a form through a JSF portlet. Typically, a JSP on the producer performs some background action, such as executing business logic, and prepares a response.
As you will see, the steps taken for remote portlet interaction are similar to those taken for simple rendering. The differences are highlighted in Figure 3-6 and described in this section.
Tip:
It is crucial to understand that the rendering and interaction phases of the remote portlet life cycle are decoupled. This decoupling has important consequences on how you develop portlets in a producer. You cannot expect a portal to receive the same HTTP response or request for the render phase as it receives after an interaction. For more information on this and other practical advice, see Chapter 14, "Other Topics and Best Practices."Figure 3-6 Remote Portlet Interaction Life Cycle
When a user interacts with a remote portlet, the consumer must first compose a SOAP message to send to the producer. These initial steps include the following. Steps highlighted in bold differ from the render phase described previously.
Find producer metadata.
Collect the portlet state.
Collect all cookies.
Collect request parameters.
Because the user is interacting with the portlet, the request parameters must be collected and returned to the producer.
Create a SOAP message.
All of the information gathered by the consumer must be formed into a SOAP message and sent to the producer.
After the producer receives the SOAP message from the consumer, the producer must take the following steps to invoke the portlets action, generate markup for the requested portlet, and return the portlet's markup to the consumer. Steps highlighted in bold differ from the render phase described previously.
Receive the SOAP request from the consumer.
Create an HTTP environment for the portlet.
Decide whether or not to offer extended features.
Create a URL rewriter.
Invoke the portlet's action.
In this step, the actions submitted by the consumer must be replayed on the producer. The producer is not directly aware of where the request for this action comes from. After the business logic is executed, a page must be prepared that displays the results of the logic. For instance, if the user submitted a login form, after a successful login, the portlet must return another page that tells the user that the login was successful.
Collect changes to the portlet state.
After the request is processed, the producer must collect changes to the portlet's state. This state is returned to the consumer in the form of a markup fragment that can be collected and displayed for the end user.
Collect the session ID, if a new session was created.
Sends the markup back to the consumer.
These steps are the same as for the render phase described previously.
Steps highlighted in bold differ from the render phase described previously.
Collect cookies.
Collect the session ID for each portlet.
Save portlet state changes.
Portlet state information is maintained on the consumer.
Rewrite markup (optional)
Write markup to the response.
This cycle repeats each time the portlet is rendered, as long as caching is not enabled on the consumer.
Both the rendering and interaction phases are available to any remote portlet. The render phase is required in cases where the user does not directly interact with a portlet, but the portlet needs to be refreshed anyway. For instance, if a user interacts with one portlet on a page, she doesn't want the other portlets on the page to change or disappear.
Because the render phase is not always driven by a user's interaction, it is idempotent (the producer returns the same portlet state that the consumer submits). This makes sense, because if you simply refresh a page, you do not want to regenerate data from a database. Likewise, in the render phase, mode and state changes are not allowed.
Tip:
Separate rendering and interaction phases are not unique to remote portlets; local portlets incorporate a rendering and interaction phase as well.Table 3-1 summarizes the characteristics of these two phases. These two phases are decoupled so that a portlet's state can only change if you interact with it. If, for instance, you submit a form from Portlet A, and then interact with Portlet B in the same portal page, you do not want the state or view of Portlet A to change when it is refreshed. A portlet's state must only change if you interact with it directly. The interaction phase is always driven by user interaction, while the render phase can happen any number of times and is driven arbitrarily.
Table 3-3 Render Versus Interaction for Remote Portlets
| Render Phase | Interaction Phase |
|---|---|
|
Focus on presentation (view) |
Focus on business logic (controller) |
|
May be replayed several times |
Driven by user interaction |
|
Idempotent
|
Non-idempotent
Can redirect users |
|
Generates markup |
Optionally generates markup. |
To facilitate interportlet communication with events, WebLogic Portal extended the WSRP protocol to add a third phase in the remote portlet life cycle. This extension allows a portlet to fire an event during its interaction phase. You can register events with remote portlets; however, when a proxy portlet receives an event, it cannot process it locally because it is a proxy. The remote portlet must send the event to the producer for processing. The portlet on the producer then fires the event and the producer handles it as appropriate.
Note:
The WebLogic Portal IPC framework is location independent. This means that the framework is not concerned with where an event originated. Portlets in consumers and producers can both listen for and fire events.This phase is similar to the interaction phase. The primary difference is that in the interaction phase, the portlet gets the user interaction data and in response it changes the navigational state of the portlet. The portlet can also fire events.
In the event processing phase, the portlet does not receive a user interaction; rather, it always gets an event fired by another component. In response to the event, the producer can change the state of the portlet and can generate more events, which are stored in an event chain. If it generates events, then the cycle repeats.
WebLogic Portal allows you to specify certain dependencies associated with individual portlets. Dependencies typically include Cascading Style Sheets (CSS files) and script files, such as JavaScript (JS) files. Portlet dependencies are configured in an XML file that is referenced in a .portlet file. The dependencies file explicitly lists the CSS and script files upon which the portlet depends.
WebLogic Portal has extended the WSRP protocol to allow remote portlets to retrieve render dependencies from producers.
In summary, WebLogic Portal applications can act as consumers and/or producers. WebLogic Portals are configured to handle:
Communication with multiple producers
Federation from producers running WebLogic Server or other non-WebLogic Portal applications.
Aggregation of remote portlets
Addition of personalization, customization, security management, look and feel, and other typical WebLogic Portal features to remote portlets
Displaying remote portlets to end users as rendered HTML content
Figure 3-8 shows a sequence diagram depicting the flow of actions between end users, consumers, and producers. This diagram highlights the notion that a consumer acts as an intermediary between a producer and an end user.
If you are interested in learning more about the technical details of the WebLogic Portal implementation of WSRP, you can refer to the following:
Inside WSRP at http://www.oracle.com/technology/pub/articles/dev2arch/2005/03/inside_wsrp.html
This Oracle white paper discusses in detail the messaging that occurs between consumers and producers and highlights best practices for developers writing portlets that will be hosted on producers.
WSRP v.1.0 Primer at http://www.oasis-open.org/committees/wsrp.
The purpose of this document is to provide a tutorial-oriented explanation of the main concepts of the WSRP 1.0 specification. This document is maintained by OASIS, the Organization for the Advancement of Structured Information Standards. OASIS is responsible for creating the WSRP standard.
Web Services for Remote Portlets Specification Version 1.0 at http://www.oasis-open.org/committees/wsrp.
This is the official specification for WSRP version 1.0. This document was also created by and is maintained by OASIS.
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
