[openroad-developer] Re: New OpenROAD HTTP Gatekeeper

Mon May 5 10:27:18 PDT 2008

I'll go back to my initial reasoning:  I am trying to draw a parallel to 
it's use from a 4GL developers perspective (which is the only 
perspective that counts for this particular servlet since its the only 
way it is used -- to connect an OpenROAD client).   

On the client side, we use an instance of the "RemoteServer" class to 
connect to the OpenROAD Server.  In that context, having the Java 
servlet called "RemoteServlet" or "IngresRemoteServer" simply fits and 
creates that parallel.  I.e., a 4GL developer connects a RemoteServer 
object to an "RemoteServlet" or an "IngresRemoteServer" using a URL as a 
location and http as a protocol.

IMHO, "HTTP" is irrelevant and should not be in the name.  All servlets 
communicate via HTTP so that does not add anything.  It would be like 
calling a Toyota Camry a "Toyota Camry Car".  (Oh no, what did I unleash 
with that!).

The more I think about it, the more I like "IngresRemoteServer".  This 
is consistent with a unified brand and the future direction of the 
OpenROAD architecture as well as fitting into the current context of the 
product.

David

On 05/05/2008 01:17 PM, Roger L. Whitcomb wrote:
> HttpServlet is already used as the generic class in javax.servlet.http.HttpServlet (see http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpServlet.html) 
>
>
> Roger Whitcomb
> Architect, Engineering
> Ingres Corp.
> +1 (650) 587-5596
> roger.whitcomb at ingres.com
>
> -----Original Message-----
> From: openroad-developer-bounces at lists.ingres.com [mailto:openroad-developer-bounces at lists.ingres.com] On Behalf Of Durwin Wright
> Sent: Monday, May 05, 2008 10:14 AM
> To: David Tondreau; openroad-developer at lists.ingres.com
> Subject: RE: [openroad-developer] Re: New OpenROAD HTTP Gatekeeper
>
> Why not simply call it what it is: "HttpServlet" or "IngresHttpServlet".
>
> Durwin Wright | Sr. Architect | Durwin.Wright at ingres.com | Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 | USA  +1 650-587-5523 | fax: +1 650-587-5550 
>
> -----Original Message-----
> From: openroad-developer-bounces at lists.ingres.com [mailto:openroad-developer-bounces at lists.ingres.com] On Behalf Of David Tondreau
> Sent: Monday, May 05, 2008 9:53 AM
> To: openroad-developer at lists.ingres.com
> Subject: [openroad-developer] Re: New OpenROAD HTTP Gatekeeper
>
> Skipping back to Bodo's response that "RemoteServer" is not good because it is already used in our Java namespace, why not simply call it the "RemoteServlet"  class.  I have seen a number of examples of servlets that use "Servlet" in the name and it holds to the premise of simply calling it what it is ... a servlet.  I think it also provides an indication that communications to the class would be through HTTP (since all servlets communicate though HTTP or HTTPS).  It makes sense to me (even given the little I know about servlets), that connecting to one from an OpenROAD client would take a URL as a "location" and HTTP as a "routing" protocol.  This makes the parameters to the RemoteServer class make a lot of sense.
>
> I am also in favor of not replacing the existing SRS.java class for two
> reasons:  One, I don't like names that are acronyms as it is not obvious enough as to what the resource is or does.  Two, we have existing production users that use this template.  Since this is a component we provide is source form and allow/encourage users to modify, we may need to start using a naming scheme that preserves these templates even when we upgrade an installation.  For instance, if we were to name this new version of the gatekeeper "RemoteServlet.java" then the next major architectural rendition of it (i.e., not just bug fixes to the first
> version) should probably be called "RemoteServer2.java" or something like that.
>
> If "RemoteServlet" is too "generic" (i.e., is that meaningful from a Java perspective to identify this as something that relates to OpenROAD or Ingres), then another idea would be to call it the "IngresRemoteServer" class.  I want to avoid if at all possible the use of OpenROAD in the name to ensure we don't run afoul of Empire or any other future use of the technology.
>
> David
>
>
> On 05/05/2008 12:26 PM, Durwin Wright wrote:
>   
>> DCOM has the same problem.  If everyone feels comfortable with this 
>> fact and considering that we have just open source the 4GL (so 
>> everyone will know every possible SCP that can be called in CORE.PLB) 
>> then it is okay with me.
>>
>>  
>>
>> BTW, one possible thing that could be done with a gatekeeper is to 
>> implement the collection of performance statistics (Call4GL, 
>> Initiates, etc) at the SCP level since the Gatekeeper has the ability 
>> to peek inside the HTTP Serial Message.
>>
>>  
>>
>> Durwin Wright | Sr. Architect | Durwin.Wright at ingres.com 
>> <mailto:Durwin.Wright at ingres.com> | Ingres | 500 Arguello Street | 
>> Suite 200 | Redwood City | CA | 94063 | USA 
>> <http://maps.google.com/maps?q=500+arguello+street,+94063&ll=37.487297
>> ,-122.233200&spn=0.004602,0.012771&t=k&hl=en>  +1
>> 650-587-5523 | fax: +1 650-587-5550
>>
>> ----------------------------------------------------------------------
>> --
>>
>> *From:* Bodo Bergmann
>> *Sent:* Monday, May 05, 2008 9:21 AM
>> *To:* Durwin Wright
>> *Cc:* Joseph C. Kronk; Roger L. Whitcomb; David Tondreau
>> *Subject:* RE: New OpenROAD HTTP Gatekeeper
>>
>>  
>>
>> You mean, as it is included in the permitted application, any of its 
>> 4GL procedures can be called.
>>
>>  
>>
>> But don't we have the same problem when using DCOM?
>>
>> Remember - most security attacks are coming from the inside anyway.
>>
>>  
>>
>> ----------------------------------------------------------------------
>> --
>>
>> *From:* Durwin Wright
>> *Sent:* Monday, May 05, 2008 6:15 PM
>> *To:* Bodo Bergmann
>> *Cc:* Joseph C. Kronk; Roger L. Whitcomb; David Tondreau; Durwin 
>> Wright
>> *Subject:* RE: New OpenROAD HTTP Gatekeeper
>>
>> You can call anything in CORE.PLB.
>>
>>  
>>
>> Durwin Wright | Sr. Architect | Durwin.Wright at ingres.com 
>> <mailto:Durwin.Wright at ingres.com> | Ingres | 500 Arguello Street | 
>> Suite 200 | Redwood City | CA | 94063 | USA 
>> <http://maps.google.com/maps?q=500+arguello+street,+94063&ll=37.487297
>> ,-122.233200&spn=0.004602,0.012771&t=k&hl=en>  +1
>> 650-587-5523 | fax: +1 650-587-5550
>>
>> ----------------------------------------------------------------------
>> --
>>
>> *From:* Bodo Bergmann
>> *Sent:* Monday, May 05, 2008 8:54 AM
>> *To:* Durwin Wright; 'openroad-developer at lists.ingres.com'
>> *Cc:* Joseph C. Kronk; Roger L. Whitcomb; David Tondreau
>> *Subject:* RE: New OpenROAD HTTP Gatekeeper
>>
>>  
>>
>> Durwin,
>>
>>  
>>
>> if the access is limited to one distinct appllication (AkaName), i.e. 
>> using the //OpenROAD_ServerApp// parameter in the web.xml,
>>
>> then there shouldn't be a way to call SCPs defined in other images.
>>
>> Or do I miss something here ?
>>
>>  
>>
>> What do you mean with "Could the new Gatekeeper be written as a pure 
>> Java Servlet with no references to any pre-compiled java classes?"
>>
>>  
>>
>> It has to use the "com.ca.openroad.SerialRemoteServer" class (provided 
>> in the openroad.jar archive).
>>
>>  
>>
>> A servlet in Tomcat is a combination of web.xml file and one or more 
>> class files - that's what I provided.
>>
>> The goal is also to not even require a Java SDK on the machine - a JRE 
>> should be enough to run Tomcat,
>>
>> so even an "autocompile" feature for *.java sources would not help.
>>
>>  
>>
>> Bodo.
>>
>>  
>>
>> ----------------------------------------------------------------------
>> --
>>
>> *From:* Durwin Wright
>> *Sent:* Monday, May 05, 2008 5:09 PM
>> *To:* openroad-developer at lists.ingres.com
>> *Cc:* Joseph C. Kronk; Roger L. Whitcomb; Bodo Bergmann; David 
>> Tondreau
>> *Subject:* RE: New OpenROAD HTTP Gatekeeper
>>
>> The Serial Remote Server (SRS or Gatekeeper) has several purposes:
>>
>>  
>>
>> §         HTTP Access to the COM Remote Server class
>>
>> §         Authentication of requestor
>>
>> §         Authorization of access to SCPs
>>
>>  
>>
>> The latter is the main reason why this is called the Gatekeeper.  
>> There is nothing that will prevent an OpenROAD Client application from 
>> invoking any SCP that is defined in CORE.PLB.  The idea of the SRS was 
>> to only allow the screening of SCPs invoked by OpenROAD Clients.  The 
>> reason why this was deemed important was that it was envisioned that 
>> this would provide Internet Access to the OpenROAD Server.  If there 
>> were not limits on which SCP could be access then the OpenROAD Server 
>> could be exposed to a DNOS attack.
>>
>>  
>>
>> I really would like to see the SRS be replaced.  I understand that 
>> another goal is to provide an out-of-the-box solution that does not 
>> require any compiling of Java code.
>>
>>  
>>
>> Could the new Gatekeeper be written as a pure Java Servlet with no 
>> references to any pre-compiled java classes?
>>
>>  
>>
>> Durwin Wright | Sr. Architect | Durwin.Wright at ingres.com 
>> <mailto:Durwin.Wright at ingres.com> | Ingres | 500 Arguello Street | 
>> Suite 200 | Redwood City | CA | 94063 | USA 
>> <http://maps.google.com/maps?q=500+arguello+street,+94063&ll=37.487297
>> ,-122.233200&spn=0.004602,0.012771&t=k&hl=en>  +1
>> 650-587-5523 | fax: +1 650-587-5550
>>
>> ----------------------------------------------------------------------
>> --
>>
>>  
>>
>>     
> _______________________________________________
> openroad-developer mailing list
> openroad-developer at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/openroad-developer
> _______________________________________________
> openroad-developer mailing list
> openroad-developer at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/openroad-developer
>
>   