Application architecture using Weblogic Integration - Part 3
Gabriel Bechara's Blog |
September 1, 2006 9:09 AM
|
Comments (2)
After focusing on a simple case in the
second part of this blog Application architecture using Weblogic Integration - Part 2 let's see what are some of the
motivations behind the choices that were made.
Part 3: Impact on performance tuning and deployment
Performance tuning
Having multiple projects chosen depending
on the layer, the business module or the backend, as shown in part 2 of this blog,
will give more possibilities for tuning the application. This will be very
useful, when events coming from a backend are numerous, for preventing thread
starvation that may occur if all threads from the default queue are used for
processing those events. For Files Event Generators we surely could do some
tuning using the read limit for polling files in the file event generator itself,
but this may not be enough. Thereafter assigning a dedicated thread queue for all
processes belonging to a project may be a better approach.
For the processes called asynchronously, or
for controls having buffered method calls, the AsyncDispatcher queue will be
used calling a Message Driven Bean that will use the execute queue specified in
WEB-INF/wlw-config.xml of the Workshop project. This setting will generate the
appropriate dispatch element in the DD for the underlying EJB.
<wlw-config
xmlns="http://www.bea.com/2003/03/wlw/config/">
...
...
<async-dispatch-policy>application.project.ExecuteQueueName</async-dispatch-policy>
</wlw-config>
For the synchronous call, being started by
an external http Web Service call for example, you need to specify the thread
queue in WEB-INF/web.xml.
The associated execute queues should be
created using Weblogic Server administration console. If those queues do not
exist on the server the default queue will be used.
More information can be found at wlw-config.xml Configuration File.
For the internals of Workshop you
may want to look at this article http://dev2dev.bea.com/pub/a/2004/06/wlw_internals.html.
Project and application naming
A Workshop project name must be unique in a
Weblogic domain. A Weblogic domain may be hosting many Workshop applications
that are composed of Workshop projects. To avoid collision of contexts it can
be a good choice to prefix all projects by the application name giving:
[WorkshopProjectName] =
[ApplicationName][ModuleName]
Access to the context of the project or
to a process using a Web Service Control or a Service Broker Control is done
using an URL that contains (by default) the project name. We will have for
example:
http://server:port/[WorkshopProjectName]/com/mycompany/mymodule/.../ClientOrder.jpd
JMS queues used internally by a Workshop project
are also deduced form the Workshop project name. A project named WorkshopProjectName
will need those two queues:
[WorkshopProjectName]Processes.queue.AsyncDispatcher
[WorkshopProjectName]Processes.queue.AsyncDispatcher_error
Consider versioning stateful processes
from the beginning
An interesting support pattern on this
matter should be examined on Versioning JPD On Running Instances.
Calling processes and related
considerations
When calling a process from another on the
same domain you may choose to use a Process Control or use the Message Broker
depending design choices. This will work for processes being in different
projects or different applications provided they are on the same Weblogic
Integration domain. Calling a process form another Weblogic domain can be done using
a Service Broker Control, a Web Service Control or a JpdProxy. The latter can
be used in any java client.
The Process Controls can be copied to a Controls
Project to be shared between processes being in different projects or different
applications.
When using a Process Control if the child
process is synchronous it will be executed in the same thread as the caller. Using
a Service Broker Control instead of a Process Control in the same Weblogic Integration
domain will use another thread on the side of the called process since it will
be called thru the SOAP protocol on HTTP; this is not optimal for performances.
Special considerations are needed when making
synchronous calls using a Process Control across application boundaries with
complex Java types. The java classes should be added to the application server system
classpath to avoid classcast exceptions as documented in http://e-docs.bea.com/wli/docs81/relnotes/relnotesLimit.html#1268647.
Note: The XmlBeans documents created in a
jpd are handled in a special manner. This is being done by the Factory of the XmlBean
that will create the bean depending on the context of its execution. When the Factory
of the XmlBean is called in the context of a process it will create a proxy object
of type com.bea.wli.variables.ProcessXML allowing synchronous calls using a
Process Control across application boundaries with XmlObjects without having
the XmlObjects classes in the application server system classpath.
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Under the section titled [WorkshopProjectName] = [ApplicationName][ModuleName]
The line below:
[WorkshopProjectName]Processes.queue.AsyncDispatcher_erreur
should be:
[WorkshopProjectName]Processes.queue.AsyncDispatcher_error
Posted by: oagbo on November 20, 2006 at 12:20 PM
-
This typo is one of the linguistic side effects I have to overcome :-). Thanks. Gabriel.
Posted by: BECHARAG on November 22, 2006 at 12:58 AM
|
