ATG Made Easy - part 3

9) JMS & ATG:

The Dynamo Application Framework includes a number of JMS-related tools, which are known collectively as the Dynamo Messaging System (DMS). The main parts of DMS are:

a) Two JMS providers, Local JMS and SQL JMS. Local JMS is built for high-speed lowlatency
synchronous messaging within a single process. SQL JMS is more robust, and
uses an SQL database to handle communication between components within the
same Dynamo application, or components running in different processes.

b) Patch Bay is an API and configuration system layered on top of JMS. Patch Bay is
designed to ease the development of messaging applications in Dynamo. The Patch
Bay API allows Nucleus components to send and receive messages. The configuration
system uses an XML file to specify how these components should be connected. This
file allows developers to change or add connections between components without
changing code.

**) Local JMS:

Local JMS does no queuing. When a message is sent, Local JMS immediately finds out who the receivers are and calls the appropriate methods on the receivers to deliver the message, waiting for each receiver to process the message before delivering the message to the next receiver. Only when the message has been delivered to all receivers does control return to the sender. In this way, Local JMS works more like Java Bean events than like typical JMS implementations; when a Java Bean fires an event, it actually calls a method on several registered listeners.
Local JMS is also non-durable; all messages are non-persistent. If a message is sent to a queue destination that has no listeners, the message disappears. Also, durable subscriptions to topic destinations act exactly like non-durable subscriptions—if a subscriber is not listening to a topic, it misses any messages sent to that topic whether it is subscribed durably or not.
Local JMS is most often used to pass data around to various components within a single request.

b) SQL JMS:
Asynchronous messaging and message persistence, it uses an SQL database for persistence of messages.
This ensures that messages are not lost in the event of system failure, and enables support for persistent queues and durable subscriptions, as described in Message Persistence.

c) Patch Bay:
Patch Bay is designed to simplify the process of creating JMS applications. Patch Bay includes a simplified API for creating Nucleus components that send and receive messages, and a configuration file where you declare these components and your JMS destinations. When a Nucleus-based application starts up, it examines this file and automatically creates the destinations and initializes the messaging components.
This means your code does not need to handle most of the JMS initialization tasks, such as obtaining a ConnectionFactory, obtaining a JMS Connection, and creating a JMS Session

Patch Bay is represented in Nucleus as the component /atg/dynamo/messaging/MessagingManager, which is of class atg.dms.patchbay.PatchBayManager

MessagingManager uses an XML file called the DMS configuration file to configure the individual parts of the Patch Pay system, such as JMS providers, message sources and sinks, and destinations. The definitionFile property of the MessagingManager component names the DMS configuration file.

Components: (all must be global scoped)
*Message source: A component that can send messages. A message source must implement the atg.dms.patchbay.MessageSource interface.
==>create and send messages
* Message sink: a component that can receive messages. A message sink must implement the atg.dms.patchbay.MessageSink interface.
==> This interface defines a single method, receiveMessage, which is called to notify the message sink that a message is being delivered.
* Message filter: a component that implements both interfaces, and can send and receive messages.
==>Message filters must implement both the MessageSource and the MessageSink interface. A message filter typically implements receiveMessage by manipulating the message in some way, then sending a new message.
* In addition to your sources and sinks, you must also define standard JMS destinations;

Patch Bay is represented in Nucleus as the component /atg/dynamo/messaging/MessagingManager.
The definitionFile property of the component MessagingManager names the XML file that
configures Patch Bay. The value of this property is:
/atg/dynamo/messaging/dynamoMessagingSystem.xml

Example for defining the 3 elements:
<?xml version="1.0" ?>
<dynamo-message-system>
<patchbay>
<message-source>
<nucleus-name>
/atg/dynamo/messaging/TestSource1
</nucleus-name>
</message-source>
<message-sink>
<nucleus-name>
/atg/dynamo/messaging/TestSink1
</nucleus-name>
</message-sink>
<message-filter>
<nucleus-name>
/atg/dynamo/messaging/TestFilter1
</nucleus-name>
</message-filter>
</patchbay>
</dynamo-message-system>

You can use SQL JMS as your JMS provider for your own applications. However, if you are running the ATG platform on IBM WebSphere Application Server or Oracle WebLogic Server, you might prefer to use your application server’s JMS provider.

NB: Use topic if you have multiple subscribers each provide different functionality and you want them all to list to it, and use Queue if you have only 1 functionality and you need only 1 type of listeners that process the messages only once.

10) Search Engine Optimization:
Search Engine Optimization (SEO) is a term used to describe a variety of techniques for making pages more accessible to web spiders (also known as web crawlers or robots), the scripts used by Internet search engines to crawl the Web to gather pages for indexing. The goal of SEO is to increase the ranking of the indexed pages in search results.

Available Options:
-URL Recoding
-Canonical URLs
-Sitemaps
-SEO Tagging

*Jumping Servlet:
The atg.repository.seo.JumpServlet class is responsible for translating static request URLs to their dynamic equivalents. This class extends the atg.servlet.pipeline.InsertableServletImpl class, so it can be inserted in the DAS or DAF servlet pipeline. However, because this servlet is intended to process only static URLs, and incoming URLs are typically dynamic, including the servlet in a pipeline may be very inefficient. Therefore, it is generally preferable to configure it as a URI-mapped servlet in the web.xml file of your application, to ensure that it processes only static URLs.

To configure the jump servlet in a web.xml file, you actually declare another class,
atg.repository.seo.MappedJumpServlet. This is a helper class that invokes the JumpServlet
component. In addition, you declare a servlet mapping for the pattern that the servlet uses to detect static request URLs.
For example, if you have configured your static URLs to include /jump/ immediately after the context root, the entry in the web.xml file would be something like this:
<servlet>
<servlet-name>MappedJumpServlet</servlet-name>
<servlet-class>atg.repository.seo.MappedJumpServlet</servlet-class>
<init-param>
<param-name>jumpServlet</param-name>
<param-value>ctx:dynamo:/atg/repository/seo/JumpServlet</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>MappedJumpServlet</servlet-name>
<url-pattern>/jump/*</url-pattern>
</servlet-mapping>

There also are several properties you can configure for the Nucleus component:
- templates
An array of IndirectUrlTemplate components that the servlet examines in the order specified until it finds one that matches the static request URL.
- defaultRepository
Specifies the repository to associate with repository items for which a repository is not
otherwise specified.
- defaultWebApp
Specifies the default web application to use when determining the context path for a URL.

In addition, the servlet has nextServlet and insertAfterServlet properties for including the
component in a servlet pipeline. If the servlet is configured through the web.xml file, you should not set these properties.

The templates point to a global component property files for the component: IndirectUrlTemplate or DirectUrlTemplate (atg.repository.seo.InDirectUrlTemplate and atg.repository.seo.DirectUrlTemplate) where you can specify many properties including:

indirectRegex=/shop/(mobile-phone)/(.*)/(.*)$
regexElementList=parentAlias | string,\
skuItem | id | /atg/commerce/catalog/ProductCatalog:skuLookup,sTab | string
urlTemplateFormat=/shop/{parentAlias}/{skuItem.id}/{sTab}

Then the forwarded URL by the jump servlet like:

forwardUrlTemplateFormat=/{skuItem.sku.template.URL,encode=true}?skuId\={skuItem.sku.id}&selectedTab\={sTab}

Another example: suppose you have a URL format that looks like this:

urlTemplateFormat=/jump/product/{item.id}/{item.parentCategory.id}\
/{item.displayName}/{item.parentCategory.displayName}

The regular expression pattern for this format might be specified like this:
indirectRegex=/jump/product/([^/].*?)/([^/].*?)/([^/].*?)/([^/].*?)$

Reference: ATG Platform documentation set : Version 9.1 - 7/31/09