AMQP Support in Hyrax - Revision history

Jimg: /* How the OLFS connects to the BES */

2013-12-19T20:45:57Z

How the OLFS connects to the BES

← Older revision		Revision as of 20:45, 19 December 2013
Line 20:		Line 20:
	=== How the OLFS connects to the BES ===		=== How the OLFS connects to the BES ===

	On start-up the OLFS makes a connection to the BES. When the OLFS is started, the BES Daemon (''besdaemon'') has already started and bound a well-known port (~~10002~~ by default; set in both the bes and olfs configuration files). The OLFS starts when Tomcat starts or restarts the servlet and initially makes a pool of connections. These are really TCP socket connections to specific instances of the BES listener (''beslistener''). When the OLFS gets a request it needs to process using the BES, it checks this pool of connections and picks the next available one. If no connections are available, then a new connection is made unless the maximum number of allowed connections have already been made. In the latter case the request for a the next available connection blocks until there is an available connection. The maximum number of connections to the BES, which is really the maximum number of BES listeners (i.e., processes) to make is set in the OLFS configuration file.		On start-up the OLFS makes a connection to the BES. When the OLFS is started, the BES Daemon (''besdaemon'') has already started and bound a well-known port (10022 by default; set in both the bes and olfs configuration files). The OLFS starts when Tomcat starts or restarts the servlet and initially makes a pool of connections. These are really TCP socket connections to specific instances of the BES listener (''beslistener''). When the OLFS gets a request it needs to process using the BES, it checks this pool of connections and picks the next available one. If no connections are available, then a new connection is made unless the maximum number of allowed connections have already been made. In the latter case the request for a the next available connection blocks until there is an available connection. The maximum number of connections to the BES, which is really the maximum number of BES listeners (i.e., processes) to make is set in the OLFS configuration file.

	To see how the OLFS does this, look at [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/bes BES.java], [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/bes/OPeNDAPClient.java OPeNDAPClient.java], and [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/bes/NewPPTClient.java NewPPTClient.java]		To see how the OLFS does this, look at [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/bes BES.java], [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/bes/OPeNDAPClient.java OPeNDAPClient.java], and [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/bes/NewPPTClient.java NewPPTClient.java]

Jimg: /* Use Cases */

2009-12-12T00:33:09Z

Use Cases

← Older revision		Revision as of 00:33, 12 December 2009
Line 107:		Line 107:

	http://www.oceanobservatories.org/spaces/display/CIDev/Data+Exchange		http://www.oceanobservatories.org/spaces/display/CIDev/Data+Exchange


			== TODO email from John ==

			David,

			May I explicitly ask if the report can please include the following?
			- a summary of work (I'm sure it will have that);
			- a list of issues addressed and issues identified;
			- a set of recommendations for going forward with additional work. (Based on your results, what do you think should be done to extend, finish, or improve these results?)

			I think this shouldn't represent painful additional work, but it will be valuable to put this in place now, in preliminary form, to make sure we can have the big picture captured before the year mysteriously disappears.

			I think David may be the point person to take care of a lot of this, but I wanted to surface the desired content for everyone to be aware of. Thanks, I'll go away now!

			John

Ndp: /* Abstracting the request-response logic of the OLFS */

2009-12-11T22:35:44Z

Abstracting the request-response logic of the OLFS

← Older revision		Revision as of 22:35, 11 December 2009
Line 86:		Line 86:
	Most of the work in defining the set of values to be extracted from the ''HttpServletRequest'' object has already been done and resides in the [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/coreServlet/ReqInfo.java ReqInfo] class. This class has eleven (11) methods that return information needed by one or more of the dispatch handlers. Nine (9) of the methods return string values and two return boolean values. Searching within the OLFS source code, there are 128 uses of the HttpServletRequest class (excluding the ''experiment'' code and all the classes that provide support for WCS). This corresponds to 23 classes in three packages.		Most of the work in defining the set of values to be extracted from the ''HttpServletRequest'' object has already been done and resides in the [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/coreServlet/ReqInfo.java ReqInfo] class. This class has eleven (11) methods that return information needed by one or more of the dispatch handlers. Nine (9) of the methods return string values and two return boolean values. Searching within the OLFS source code, there are 128 uses of the HttpServletRequest class (excluding the ''experiment'' code and all the classes that provide support for WCS). This corresponds to 23 classes in three packages.

	Replacing the ''HttpServletResponse'' object may be more complicated, depending on the capabilities of the AMQP Client software base. The servlet response provides methods to write certain specific headers that will preface the response body in HTTP's pseudo-MIME response document. The response also contains a stream used to write the body of the response. ~~I t~~ may be that the best approach is to modify the dispatch software so that it builds two things: the response preface material and the response body. Some implementations of the ''HyraxResponse'' class would ignore the preface material (e.g., the ContentType header), others might format that in different ways. To determine more about this class' construction, we need to know what the AMQP client object expects and the facilities it provides.		Replacing the ''HttpServletResponse'' object may be more complicated, depending on the capabilities of the AMQP Client software base. The servlet response provides methods to write certain specific headers that will preface the response body in HTTP's pseudo-MIME response document. The response also contains a stream used to write the body of the response, and it allows the OLFS to provide HTTP status responses. It may be that the best approach is to modify the dispatch software so that it builds two things: the response preface material and the response body. Some implementations of the ''HyraxResponse'' class would ignore the preface material (e.g., the ContentType header), others might format that in different ways. To determine more about this class' construction, we need to know what the AMQP client object expects and the facilities it provides.

	Additionally, components of the OLFS need access to resources held on the local drive, both within the web applications distribution directory and in the persistent content directory used by the OLFS to hold configuration, logs, and as a pace for components to store state information. The class [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/coreServlet/ServletUtil.java ServletUtil] currently provides those local resources paths. This information would also need to be included in the data object that we develop to abstract the HttpServletRequest information.		Additionally, components of the OLFS need access to resources held on the local drive, both within the web applications distribution directory and in the persistent content directory used by the OLFS to hold configuration, logs, and as a pace for components to store state information. The class [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/coreServlet/ServletUtil.java ServletUtil] currently provides those local resources paths. This information would also need to be included in the data object that we develop to abstract the HttpServletRequest information.

Ndp: /* Abstracting the request-response logic of the OLFS */

2009-12-11T22:33:01Z

Abstracting the request-response logic of the OLFS

← Older revision		Revision as of 22:33, 11 December 2009
Line 87:		Line 87:

	Replacing the ''HttpServletResponse'' object may be more complicated, depending on the capabilities of the AMQP Client software base. The servlet response provides methods to write certain specific headers that will preface the response body in HTTP's pseudo-MIME response document. The response also contains a stream used to write the body of the response. I t may be that the best approach is to modify the dispatch software so that it builds two things: the response preface material and the response body. Some implementations of the ''HyraxResponse'' class would ignore the preface material (e.g., the ContentType header), others might format that in different ways. To determine more about this class' construction, we need to know what the AMQP client object expects and the facilities it provides.		Replacing the ''HttpServletResponse'' object may be more complicated, depending on the capabilities of the AMQP Client software base. The servlet response provides methods to write certain specific headers that will preface the response body in HTTP's pseudo-MIME response document. The response also contains a stream used to write the body of the response. I t may be that the best approach is to modify the dispatch software so that it builds two things: the response preface material and the response body. Some implementations of the ''HyraxResponse'' class would ignore the preface material (e.g., the ContentType header), others might format that in different ways. To determine more about this class' construction, we need to know what the AMQP client object expects and the facilities it provides.

			Additionally, components of the OLFS need access to resources held on the local drive, both within the web applications distribution directory and in the persistent content directory used by the OLFS to hold configuration, logs, and as a pace for components to store state information. The class [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/coreServlet/ServletUtil.java ServletUtil] currently provides those local resources paths. This information would also need to be included in the data object that we develop to abstract the HttpServletRequest information.

	== How Best to Combine AMQP and HTTP ==		== How Best to Combine AMQP and HTTP ==

Jimg: /* Abstracting the request-response logic of the OLFS */

2009-12-09T00:12:04Z

Abstracting the request-response logic of the OLFS

← Older revision		Revision as of 00:12, 9 December 2009
Line 76:		Line 76:
	=== Abstracting the request-response logic of the OLFS ===		=== Abstracting the request-response logic of the OLFS ===

	[[Image:OLFS new servlet.png\|thumb\|440px\|right\|Figure 4. The OLFS implemented using ''HyraxRequest'' and ''HyraxResponse'' objects. Using these factors out the coupling between Servelt and the OLFS at all but the highest levels of implementation.]][[Image:OLFS new AMQP.png\|thumb\|~~400px~~\|right\|Figure 5. The AMQP front end using ''HyraxRequest'' and ''HyraxResponse'' objects. This uses the same code as the OLFS with the ''HyraxRequest''/''Response'' objects, limiting issues with long-term maintenance.]]		[[Image:OLFS new servlet.png\|thumb\|440px\|right\|Figure 4. The OLFS implemented using ''HyraxRequest'' and ''HyraxResponse'' objects. Using these factors out the coupling between Servelt and the OLFS at all but the highest levels of implementation.]][[Image:OLFS new AMQP.png\|thumb\|440px\|right\|Figure 5. The AMQP front end using ''HyraxRequest'' and ''HyraxResponse'' objects. This uses the same code as the OLFS with the ''HyraxRequest''/''Response'' objects, limiting issues with long-term maintenance.]]

	The main obstacle we see to building a second front end for Hyrax is that the ''DispatchHandler'' interface takes instances of the ''HttpServletRequest'' and ''...Response'' classes and then passes those along to the lowest levels of the software. This creates close coupling between the [http://docs.huihoo.com/javadoc/javaee/5/javax/servlet/http/HttpServletRequest.html ServletRequest] interfaces and the OLFS code.		The main obstacle we see to building a second front end for Hyrax is that the ''DispatchHandler'' interface takes instances of the ''HttpServletRequest'' and ''...Response'' classes and then passes those along to the lowest levels of the software. This creates close coupling between the [http://docs.huihoo.com/javadoc/javaee/5/javax/servlet/http/HttpServletRequest.html ServletRequest] interfaces and the OLFS code.

Jimg at 00:01, 9 December 2009

2009-12-09T00:01:49Z

Jimg: /* How complex would this be to implement */

2009-12-08T23:57:29Z

How complex would this be to implement

← Older revision		Revision as of 23:57, 8 December 2009
Line 82:		Line 82:
	However, the coupling between ServletRequest and the OLFS is not actually needed. The software could be refactored so that ''DispatchHandler'' would accept two objects more suitable to the dispatching needs of the front end (see Figure 2). At the outermost levels, in the software that calls the ''requestCanBeHandled'' and ''handleRequest'' methods, those new parameters would be the formal parameters. Instances of the proposed request and response implementations could be built from a factory that accept instances of ''ServletRequest'' and ''ServletResponse'' as well as other things such as a set of hypothetical ''AMQPRequest'' and ''AMQPResponse'' objects. Instances of the request and response implementations would be passed into the new ''DispatchHandler'' implementations, allowing them to be used by both the OLFS and the proposed AMQP front end.		However, the coupling between ServletRequest and the OLFS is not actually needed. The software could be refactored so that ''DispatchHandler'' would accept two objects more suitable to the dispatching needs of the front end (see Figure 2). At the outermost levels, in the software that calls the ''requestCanBeHandled'' and ''handleRequest'' methods, those new parameters would be the formal parameters. Instances of the proposed request and response implementations could be built from a factory that accept instances of ''ServletRequest'' and ''ServletResponse'' as well as other things such as a set of hypothetical ''AMQPRequest'' and ''AMQPResponse'' objects. Instances of the request and response implementations would be passed into the new ''DispatchHandler'' implementations, allowing them to be used by both the OLFS and the proposed AMQP front end.

	==== How complex would this be to implement ====		==== How complex would this be to implement? ====

	Most of the work in defining the set of values to be extracted from the ''HttpServletRequest'' object has already been done and resides in the [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/coreServlet/ReqInfo.java ReqInfo] class. This class has eleven (11) methods that return information needed by one or more of the dispatch handlers. Nine (9) of the methods return string values and two return boolean values. Searching within the OLFS source code, there are 128 uses of the HttpServletRequest class (excluding the ''experiment'' code and all the classes that provide support for WCS). This corresponds to 23 classes in three packages.		Most of the work in defining the set of values to be extracted from the ''HttpServletRequest'' object has already been done and resides in the [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/coreServlet/ReqInfo.java ReqInfo] class. This class has eleven (11) methods that return information needed by one or more of the dispatch handlers. Nine (9) of the methods return string values and two return boolean values. Searching within the OLFS source code, there are 128 uses of the HttpServletRequest class (excluding the ''experiment'' code and all the classes that provide support for WCS). This corresponds to 23 classes in three packages.

Jimg: /* How complex would this be to implement */

2009-12-08T23:56:58Z

How complex would this be to implement

← Older revision		Revision as of 23:56, 8 December 2009
Line 85:		Line 85:

	Most of the work in defining the set of values to be extracted from the ''HttpServletRequest'' object has already been done and resides in the [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/coreServlet/ReqInfo.java ReqInfo] class. This class has eleven (11) methods that return information needed by one or more of the dispatch handlers. Nine (9) of the methods return string values and two return boolean values. Searching within the OLFS source code, there are 128 uses of the HttpServletRequest class (excluding the ''experiment'' code and all the classes that provide support for WCS). This corresponds to 23 classes in three packages.		Most of the work in defining the set of values to be extracted from the ''HttpServletRequest'' object has already been done and resides in the [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/coreServlet/ReqInfo.java ReqInfo] class. This class has eleven (11) methods that return information needed by one or more of the dispatch handlers. Nine (9) of the methods return string values and two return boolean values. Searching within the OLFS source code, there are 128 uses of the HttpServletRequest class (excluding the ''experiment'' code and all the classes that provide support for WCS). This corresponds to 23 classes in three packages.

	Unfortunately, it may not be that simple. Lines like: <tt>response.sendRedirect(Scrub.urlContent(request.getContextPath()+dsName+"/"));</tt> can be found, so the total number of values needed from the request object maybe more than eleven.

	Replacing the ''HttpServletResponse'' object may be more complicated, depending on the capabilities of the AMQP Client software base. The servlet response provides methods to write certain specific headers that will preface the response body in HTTP's pseudo-MIME response document. The response also contains a stream used to write the body of the response. I t may be that the best approach is to modify the dispatch software so that it builds two things: the response preface material and the response body. Some implementations of the ''HyraxResponse'' class would ignore the preface material (e.g., the ContentType header), others might format that in different ways. To determine more about this class' construction, we need to know what the AMQP client object expects and the facilities it provides.		Replacing the ''HttpServletResponse'' object may be more complicated, depending on the capabilities of the AMQP Client software base. The servlet response provides methods to write certain specific headers that will preface the response body in HTTP's pseudo-MIME response document. The response also contains a stream used to write the body of the response. I t may be that the best approach is to modify the dispatch software so that it builds two things: the response preface material and the response body. Some implementations of the ''HyraxResponse'' class would ignore the preface material (e.g., the ContentType header), others might format that in different ways. To determine more about this class' construction, we need to know what the AMQP client object expects and the facilities it provides.

Jimg: /* How complex would this be to implement */

2009-12-08T23:55:56Z

How complex would this be to implement

← Older revision		Revision as of 23:55, 8 December 2009
Line 86:		Line 86:
	Most of the work in defining the set of values to be extracted from the ''HttpServletRequest'' object has already been done and resides in the [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/coreServlet/ReqInfo.java ReqInfo] class. This class has eleven (11) methods that return information needed by one or more of the dispatch handlers. Nine (9) of the methods return string values and two return boolean values. Searching within the OLFS source code, there are 128 uses of the HttpServletRequest class (excluding the ''experiment'' code and all the classes that provide support for WCS). This corresponds to 23 classes in three packages.		Most of the work in defining the set of values to be extracted from the ''HttpServletRequest'' object has already been done and resides in the [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/coreServlet/ReqInfo.java ReqInfo] class. This class has eleven (11) methods that return information needed by one or more of the dispatch handlers. Nine (9) of the methods return string values and two return boolean values. Searching within the OLFS source code, there are 128 uses of the HttpServletRequest class (excluding the ''experiment'' code and all the classes that provide support for WCS). This corresponds to 23 classes in three packages.

	Unfortunately, it may not be that simple. Lines like:		Unfortunately, it may not be that simple. Lines like: <tt>response.sendRedirect(Scrub.urlContent(request.getContextPath()+dsName+"/"));</tt> can be found, so the total number of values needed from the request object maybe more than eleven.
	response.sendRedirect(Scrub.urlContent(request.getContextPath()+dsName+"/"));
	can be found, so the total number of values needed from the request object maybe more than eleven.

	Replacing the ''HttpServletResponse'' object may be more complicated, depending on the capabilities of the AMQP Client software base. The servlet response provides methods to write certain specific headers that will preface the response body in HTTP's pseudo-MIME response document. The response also contains a stream used to write the body of the response. I t may be that the best approach is to modify the dispatch software so that it builds two things: the response preface material and the response body. Some implementations of the ''HyraxResponse'' class would ignore the preface material (e.g., the ContentType header), others might format that in different ways. To determine more about this class' construction, we need to know what the AMQP client object expects and the facilities it provides.		Replacing the ''HttpServletResponse'' object may be more complicated, depending on the capabilities of the AMQP Client software base. The servlet response provides methods to write certain specific headers that will preface the response body in HTTP's pseudo-MIME response document. The response also contains a stream used to write the body of the response. I t may be that the best approach is to modify the dispatch software so that it builds two things: the response preface material and the response body. Some implementations of the ''HyraxResponse'' class would ignore the preface material (e.g., the ContentType header), others might format that in different ways. To determine more about this class' construction, we need to know what the AMQP client object expects and the facilities it provides.

Jimg: /* Abstracting the request-response logic of the OLFS */

2009-12-08T23:54:08Z

Abstracting the request-response logic of the OLFS

← Older revision		Revision as of 23:54, 8 December 2009
Line 76:		Line 76:
	=== Abstracting the request-response logic of the OLFS ===		=== Abstracting the request-response logic of the OLFS ===

	[[Image:OLFS new servlet.png\|thumb\|440px\|right\|The OLFS implemented using ''HyraxRequest'' and ''HyraxResponse'' objects. Using these factors out the coupling between Servelt and the OLFS at all but the highest levels of implementation.]][[Image:OLFS new AMQP.png\|thumb\|400px\|right\|The AMQP front end using ''HyraxRequest'' and ''HyraxResponse'' objects. This uses the same code as the OLFS with the ''HyraxRequest''/''Response'' objects, limiting issues with long-term maintenance.]]		[[Image:OLFS new servlet.png\|thumb\|440px\|right\|Figure 2. The OLFS implemented using ''HyraxRequest'' and ''HyraxResponse'' objects. Using these factors out the coupling between Servelt and the OLFS at all but the highest levels of implementation.]][[Image:OLFS new AMQP.png\|thumb\|400px\|right\|Figure 3. The AMQP front end using ''HyraxRequest'' and ''HyraxResponse'' objects. This uses the same code as the OLFS with the ''HyraxRequest''/''Response'' objects, limiting issues with long-term maintenance.]]

	The main obstacle we see to building a second front end for Hyrax is that the ''DispatchHandler'' interface takes instances of the ''HttpServletRequest'' and ''...Response'' classes and then passes those along to the lowest levels of the software. This creates close coupling between the [http://docs.huihoo.com/javadoc/javaee/5/javax/servlet/http/HttpServletRequest.html ServletRequest] interfaces and the OLFS code.		The main obstacle we see to building a second front end for Hyrax is that the ''DispatchHandler'' interface takes instances of the ''HttpServletRequest'' and ''...Response'' classes and then passes those along to the lowest levels of the software. This creates close coupling between the [http://docs.huihoo.com/javadoc/javaee/5/javax/servlet/http/HttpServletRequest.html ServletRequest] interfaces and the OLFS code.

	However, the coupling between ServletRequest and the OLFS is not actually needed. The software could be refactored so that ''DispatchHandler'' ~~accepts~~ two objects ~~defined by the OLFS (not the generic Servlet software) using interfaces~~ more suitable to ~~its~~ needs. At the outermost levels, in the software that calls the ''~~request can be handled~~'' and ''~~handle request~~'' methods, those new ~~OLFS-defined interfaces~~ would be the formal parameters. Instances of the proposed request and response implementations could be built from ~~constructors~~ that accept instances of ''ServletRequest'' and ''ServletResponse'' as well as other things such as a set of hypothetical ''AMQPRequest'' and ''~~...Response~~'' objects. Instances of the request and ~~respose~~ implementations would be passed into the ''DispatchHandler'' implementations, allowing them to be used by both the OLFS and the ~~porposed~~ AMQP front end.		However, the coupling between ServletRequest and the OLFS is not actually needed. The software could be refactored so that ''DispatchHandler'' would accept two objects more suitable to the dispatching needs of the front end (see Figure 2). At the outermost levels, in the software that calls the ''requestCanBeHandled'' and ''handleRequest'' methods, those new parameters would be the formal parameters. Instances of the proposed request and response implementations could be built from a factory that accept instances of ''ServletRequest'' and ''ServletResponse'' as well as other things such as a set of hypothetical ''AMQPRequest'' and ''AMQPResponse'' objects. Instances of the request and response implementations would be passed into the new ''DispatchHandler'' implementations, allowing them to be used by both the OLFS and the proposed AMQP front end.

			==== How complex would this be to implement ====

			Most of the work in defining the set of values to be extracted from the ''HttpServletRequest'' object has already been done and resides in the [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/coreServlet/ReqInfo.java ReqInfo] class. This class has eleven (11) methods that return information needed by one or more of the dispatch handlers. Nine (9) of the methods return string values and two return boolean values. Searching within the OLFS source code, there are 128 uses of the HttpServletRequest class (excluding the ''experiment'' code and all the classes that provide support for WCS). This corresponds to 23 classes in three packages.

			Unfortunately, it may not be that simple. Lines like:
			response.sendRedirect(Scrub.urlContent(request.getContextPath()+dsName+"/"));
			can be found, so the total number of values needed from the request object maybe more than eleven.

			Replacing the ''HttpServletResponse'' object may be more complicated, depending on the capabilities of the AMQP Client software base. The servlet response provides methods to write certain specific headers that will preface the response body in HTTP's pseudo-MIME response document. The response also contains a stream used to write the body of the response. I t may be that the best approach is to modify the dispatch software so that it builds two things: the response preface material and the response body. Some implementations of the ''HyraxResponse'' class would ignore the preface material (e.g., the ContentType header), others might format that in different ways. To determine more about this class' construction, we need to know what the AMQP client object expects and the facilities it provides.

	== How Best to Combine AMQP and HTTP ==		== How Best to Combine AMQP and HTTP ==

← Older revision		Revision as of 00:01, 9 December 2009
Line 6:		Line 6:
	== Proposed Architecture for AMQP Support in Hyrax ==		== Proposed Architecture for AMQP Support in Hyrax ==

	[[Image:Hyrax with AMQP.png\|left\|thumb\|Hyrax with AMQP]] Figure 2. shows how a AMQP module could be added to work with Hyrax. The diagram implies that an actual installation could support both DAP/HTTP and DAP/AMQP interactions using one BES. That might be true, or it might not, depending on how the connection pooling is handled by the OLFS and new AMQP front-end. The DAP/SOAP interface of the OLFS is really different than the other three interfaces shown in the diagram because the SOAP messaging software uses the request document body ''instead of'' the URL while the other three interfaces/protocols all use the URL and ignore the request document body. However, it's still part of the OLFS because Hyrax uses SOAP messaging over HTTP.		[[Image:Hyrax with AMQP.png\|left\|thumb\|Figure 2. Hyrax with AMQP]] Figure 2. shows how a AMQP module could be added to work with Hyrax. The diagram implies that an actual installation could support both DAP/HTTP and DAP/AMQP interactions using one BES. That might be true, or it might not, depending on how the connection pooling is handled by the OLFS and new AMQP front-end. The DAP/SOAP interface of the OLFS is really different than the other three interfaces shown in the diagram because the SOAP messaging software uses the request document body ''instead of'' the URL while the other three interfaces/protocols all use the URL and ignore the request document body. However, it's still part of the OLFS because Hyrax uses SOAP messaging over HTTP.

	One option we should consider is supporting DAP over AMQP using SOAP.		One option we should consider is supporting DAP over AMQP using SOAP.
Line 49:		Line 49:

	=== How the current OLFS dispatching works ===		=== How the current OLFS dispatching works ===
	[[Image:OLFS current.png\|thumb\|400px\|right\|The current OLFS implementation is tightly coupled with the Servlet classes, especially the HttpServletRequest and Response classes]]		[[Image:OLFS current.png\|thumb\|400px\|right\| Figure 3. The current OLFS implementation is tightly coupled with the Servlet classes, especially the HttpServletRequest and Response classes]]
	The OLFS is a dispatch handler, a giant switch statement that looks at each incoming request and shunts it to the correct software for processing. In many cases the BES is not actually involved in the processing or is involved in only a tangential way. In fact, however, the OLFS' dispatch code is more sophisticated than a switch statement. Instead it consists of two layers of processing where the outer layer is made up of a set of ''DispatchHandler'' classes. Each of these classes implements the [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/coreServlet/DispatchHandler.java DispatchHandler] interface. This interface has five methods:		The OLFS is a dispatch handler, a giant switch statement that looks at each incoming request and shunts it to the correct software for processing. In many cases the BES is not actually involved in the processing or is involved in only a tangential way. In fact, however, the OLFS' dispatch code is more sophisticated than a switch statement. Instead it consists of two layers of processing where the outer layer is made up of a set of ''DispatchHandler'' classes. Each of these classes implements the [http://scm.opendap.org/trac/browser/trunk/olfs/src/opendap/coreServlet/DispatchHandler.java DispatchHandler] interface. This interface has five methods:
	;init		;init
Line 76:		Line 76:
	=== Abstracting the request-response logic of the OLFS ===		=== Abstracting the request-response logic of the OLFS ===

	[[Image:OLFS new servlet.png\|thumb\|440px\|right\|Figure 2. The OLFS implemented using ''HyraxRequest'' and ''HyraxResponse'' objects. Using these factors out the coupling between Servelt and the OLFS at all but the highest levels of implementation.]][[Image:OLFS new AMQP.png\|thumb\|400px\|right\|Figure 3. The AMQP front end using ''HyraxRequest'' and ''HyraxResponse'' objects. This uses the same code as the OLFS with the ''HyraxRequest''/''Response'' objects, limiting issues with long-term maintenance.]]		[[Image:OLFS new servlet.png\|thumb\|440px\|right\|Figure 4. The OLFS implemented using ''HyraxRequest'' and ''HyraxResponse'' objects. Using these factors out the coupling between Servelt and the OLFS at all but the highest levels of implementation.]][[Image:OLFS new AMQP.png\|thumb\|400px\|right\|Figure 5. The AMQP front end using ''HyraxRequest'' and ''HyraxResponse'' objects. This uses the same code as the OLFS with the ''HyraxRequest''/''Response'' objects, limiting issues with long-term maintenance.]]

	The main obstacle we see to building a second front end for Hyrax is that the ''DispatchHandler'' interface takes instances of the ''HttpServletRequest'' and ''...Response'' classes and then passes those along to the lowest levels of the software. This creates close coupling between the [http://docs.huihoo.com/javadoc/javaee/5/javax/servlet/http/HttpServletRequest.html ServletRequest] interfaces and the OLFS code.		The main obstacle we see to building a second front end for Hyrax is that the ''DispatchHandler'' interface takes instances of the ''HttpServletRequest'' and ''...Response'' classes and then passes those along to the lowest levels of the software. This creates close coupling between the [http://docs.huihoo.com/javadoc/javaee/5/javax/servlet/http/HttpServletRequest.html ServletRequest] interfaces and the OLFS code.

	However, the coupling between ServletRequest and the OLFS is not actually needed. The software could be refactored so that ''DispatchHandler'' would accept two objects more suitable to the dispatching needs of the front end (see Figure 2). At the outermost levels, in the software that calls the ''requestCanBeHandled'' and ''handleRequest'' methods, those new parameters would be the formal parameters. Instances of the proposed request and response implementations could be built from a factory that accept instances of ''ServletRequest'' and ''ServletResponse'' as well as other things such as a set of hypothetical ''AMQPRequest'' and ''AMQPResponse'' objects. Instances of the request and response implementations would be passed into the new ''DispatchHandler'' implementations, allowing them to be used by both the OLFS and the proposed AMQP front end.		However, the coupling between ServletRequest and the OLFS is not actually needed. The software could be refactored so that ''DispatchHandler'' would accept two objects more suitable to the dispatching needs of the front end (see Figure 4). At the outermost levels, in the software that calls the ''requestCanBeHandled'' and ''handleRequest'' methods, those new parameters would be the formal parameters. Instances of the proposed request and response implementations could be built from a factory that accept instances of ''ServletRequest'' and ''ServletResponse'' as well as other things such as a set of hypothetical ''AMQPRequest'' and ''AMQPResponse'' objects. Instances of the request and response implementations would be passed into the new ''DispatchHandler'' implementations, allowing them to be used by both the OLFS and the proposed AMQP front end.

	==== How complex would this be to implement? ====		==== How complex would this be to implement? ====