Morphis Use Patterns

Since Morphis is an extensible translation system, there are a variety of ways in which it can be configured and used.

In general, Morphis provides wireless content translation as illustrated in the following "logical architecture" diagram. Although Morphis itself requires a Java Servlet application server to execute, it is able to obtain content from many different data sources. The usage patterns that follow enumerate how the different application components may be structured.

It is important to remember that Morphis is not restricted to the following usage patterns. As new Dispatchers, Requestors and Translators are created, new patterns may evolve. It is also possible for Morphis to be used in each of these patterns at the same time, for different applications.

1. Morphis as Content Server

Morphis can pull its source document from disk using file access, perform translation on the file, and return the translated content to the client. At first, this seems static and inflexible. However, dynamic content and complex business logic can be created with:

• Custom translators can adjust the translation stream at the byte-level
• Custom SAX translation filters will perform logic based on elements in an XML file
• XSLT extensions enable scripting and access to Java objects in the XSL file itself
• XSLT extension allow code to be executed whenever an XML element occurs (similar to custom SAX translation)
  

Performing logic in an XSL stylesheet is an excellent solution as it separates dynamic content from the content itself. Templating applications like JSP and ASP try to emulate this behavior, yet code still must be kept inside of the content file itself.

In this model, Morphis would request a document using the URL Requestor, and request a file URL like: file:///directory/to/file.xml.

2. Morphis as Proxy

Morphis can act as a proxy to other content generation systems, and translate the entire returned document. In this model, the source document itself may be served by the same application or web server as Morphis (say, a local Servlet or a JSP), or by a remote application or web server. Business logic can reside inside of Morphis just like in "1. Morphis as Content Server", but it can also reside in the application server itself.

This is very powerful since Morphis does not need to serve content - it can focus on translation. Other applications better at managing and delivering content can focus on this. Existing web sites or XML servers can be leveraged.

Morphis can retrieve remote content using HTTP and FTP, and if the appropriate Java packages are installed, HTTPS. See the section on the URL Requestor for more details.

3. Morphis as Servlet Chaining Recipient

If Morphis is being used on a servlet engine that supports Servlet chaining, then the output of a Servlet or JSP can be redirected into Morphis for translation. The benefit to this pattern is that all communication will happen in-process, and without any socket calls. Therefore, processing using this method should be faster than using "2. Morphis as Proxy". See the section on Requesting via Servlet Chaining for details on how to set this up.

4. Morphis as a Component Server

Morphis may be used in building parts of a larger document. For example, you may have an HTML page which is comprised of many smaller table components. The data for these components could originate as XML files, and Morphis would translate them into HTML fragments.

To do this, another application server would request a Morphis document using its own proprietary interface. For example, a Flash 5 drawing could use an XML Socket, a Servlet engine can use RequestDispatcher.include(), or a JSP can use <jsp:include>.

This is pattern is actually a sub-pattern of 1 and 2, since Morphis itself could obtain a source document locally or remotely.