[Openroad-users] [OpenROAD-users] OpenROAD Server on Linux

Fri Jun 1 04:29:39 EST 2007

Thank you Durwin, for a very comprehensive response.

I always thought that the 'Private' server was for native OpenROAD apps
only, primarily for debugging, so I'll look into that.

I look forward to your presentations at the IUA on the futures of the
OpenROAD Server.

Kind Regards,

Pete

________________________________

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Durwin
Wright
Sent: 31 May 2007 17:11
To: International OpenROAD Users
Cc: Durwin Wright
Subject: Re: [Openroad-users] [OpenROAD-users] OpenROAD Server on Linux

Hello All,

There are a lot of topics that have been discussed on this thread.  I
would like to weigh in on this discussion.

*         Calling the OpenROAD Runtime directly rather than going
through the App Server

I see several scenarios: (1) Is there a way to call into an OpenROAD GUI
runtime from either a C or Java application?  The answer to this
question is no. (2) Can an OpenROAD GUI application call an external
application?  The answer to this question is yes.  This can be done
either through the External Class Interface for ActiveX controls or via
the 3GL interface.  (The 3GL interface can be adapted to call Java
through the JNI facility); (3) Can a C++, Java or .NET application call
into an OpenROAD non-GUI runtime?  The answer to this question is yes.
The OpenROAD Server actually has two modes - Shared Server and Private
Server.  A Shared Server is an OpenROAD runtime that can be accessed
from multiple clients by routing requests through the Shared Pooler
(SPO) process.  A Private Server is an OpenROAD runtime that can be
accessed directly from C++, Java, .NET or another OpenROAD GUI
application.  The interface used for the Private or Shared Server is
virtually identical.

If there is a need to access Java applications via the OpenROAD External
Class interface, then this will be an enhancement.  If there is a need
to access OpenROAD GUI runtimes from a C++ or a Java runtime, then this
will also be an enhancement.

*         Open Source for OpenROAD as it relates to Windows, Linux and
Unix

The source code for OpenROAD is identical across all platforms.  We will
provide instructions on how to build the 3GL on Windows using the
Windows tools.  We will provide instructions on how to build the 4GL as
well.   Joseph Kronk will give an Ingres VIP presentation on June 16,
2007 that gives more details on the OpenROAD Open Source plans.  

At the UKIUA event, I was initially scheduled to do three presentations:
(1) OpenROAD Open Source Plans; (2) How Transparent is OpenROAD Unicode
Support and (3) OpenROAD Server Futures.  The second presentation, How
Transparent is OpenROAD Unicode Support, has expanded and will be given
in two parts.  I will use the session that was originally titled
"OpenROAD Open Source Plans" and give Part 1 of the OpenROAD Unicode
presentation.  Part 2 of the OpenROAD Unicode presentation will be given
in the original slot.  I will take about OpenROAD Server Futures in the
last slot.

*         OpenROAD Server Futures

The OpenROAD Server originally had a very simple requirement -- Call
into the OpenROAD Runtime from a Visual Basic Application.  In the
initial prototype, this was exactly what was done.  A visual Basic
Application could launch an OpenROAD runtime and call frames directly.
There was a very rudimentary parameter passing.

This evolved into a requirement to call into an OpenROAD Runtime from an
Active Server Page (ASP) environment.  The idea was that the ASP would
provide a web-based user interface hosted by Internet Information Server
(IIS) and 4GL business logic and database access would be provided by
the OpenROAD Runtime.  Each ASP user would launch an instance of the
OpenROAD runtime for each session.  This was neither efficient nor
scalable. 

We looked seriously at what it would take to make the OpenROAD runtime
thread safe but were put off by the scope of this project.  Our solution
was to take a page out of the BEA Tuxedo handbook and build a
multithreaded process that would manage a pool of OpenROAD single
threaded runtimes and would then schedule requests into the OpenROAD
runtimes from clients.  Hence the Server Pooler (SPO) was born.

The implementation for these interfaces was based on D/COM automation
servers.  Since we already had D/COM available as a result our use of
Mainsoft for the GUI, we simply took advantage of what was already
present.

Additional capabilities were added to allow not just C++ applications to
call an OpenROAD Server but others.  The approach that was taken was to
wrap the existing C/C++ COM interface with other client interfaces.  The
C++ COM object that provides the basic interface to the OpenROAD Server
was wrapped by a set of Java classes that use JNI to access the C++ COM
object.  This provides a low level interface from a Java client to the
OpenROAD Server.  Similarly, a set of .NET classes that use the .NET/COM
interoperability layer was written that also wraps the C++ COM object
used to access the OpenROAD Server.

Later, an extension was made that allows HTTP to be used to access the
OpenROAD Server from an OpenROAD client instead of relying on DCOM.
This was done to allow the eClient to access the OpenROAD Server through
a firewall in an internet deployment scenario.

The interface to the OpenROAD Server allows a very sophisticated
parameter passing capability.   While it is not as flexible as a native
OpenROAD application using CALLPROC, it never-the-less allows parameters
to be passed with only two restrictions: (1) System classes and system
attributes are not marshaled and (2) Circular references are not
allowed.  This capability is also based on COM.

So the challenges of moving the OpenROAD Server forward are as follows:

o        Replace the D/COM infrastructure with something else

o        Implement the SPO differently

o        Implement the ASO differently

o        Implement the Java interface differently

o        Implement the .NET interface differently

o        Implement the HTTP Transport differently

o        Implement the OpenROAD RemoteServer differently

o        Decouple the transport and administration of the OpenROAD
Server from COM and Windows

o        Provide backwards compatibility for existing OpenROAD eClient,
.NET and Java applications.

This is what my presentation at the UKIUA will discuss

I hope that this has helped clarify some of the points raised earlier.

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: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Bodo
Bergmann
Sent: Thursday, May 31, 2007 3:39 AM
To: International OpenROAD Users
Subject: Re: [OpenROAD-users] OpenROAD Server on Linux

See my comments below.

Bodo.

Bodo Bergmann

Senior Software Engineer

OpenROAD Worldwide Development

Ingres Corp.

________________________________

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Pete
Rabjohns
Sent: Thursday, May 31, 2007 12:12 PM
To: International OpenROAD Users
Subject: Re: [OpenROAD-users] OpenROAD Server on Linux

Thanks Bodo,

I was wondering what would happen with the Open Source OpenROAD on Linux
- are you looking at the Mono project?
[Bodo] 

Of course I already had a look at Mono project. It is interesting as it
is also available on some other Unix platforms (though not on AIX and
HP-UX).

The problem I see is that it runs .NET applications (Requirement:
applications are 100% .NET and do not make use of P/Invoke to call Win32
functions). 

The OpenROAD runtime is a Win32 app, not a .NET app.

So once OpenROAD is Open Source, the community can take the source and
convert it into a .NET app

(which will be no easy task with more than 10k source files :)

When I was thinking about J2EE, I was rather thinking that the call
could be 'inline' , i.e. Java calling the OpenROAD runtime directly,
rather than through the OpenROAD Server to give a simpler technology
stack. I presume the same logic could be applied to a .NET stack as
well. It would just mean that issues about scalability/threading etc are
handled in one place. Just a thought.
[berbo01] 

Wait for the announcements for the "OpenROAD Server Futures" (Durwin) -
this will make the technology stack easier.

Regards,

Pete

________________________________

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Bodo
Bergmann
Sent: 31 May 2007 10:56
To: International OpenROAD Users
Subject: Re: [OpenROAD-users] OpenROAD Server on Linux

Some other Windows features are provided by MainWin in the runtime,

e.g. registry, several ActiveX/COM libraries, etc.

They are also used by the OpenROAD workbench and OpenROAD Server,

so you could use them, too.

To convert a Windows app you'll need a MainWin development license to
cross compile.

Be aware, that the MainWin software dependency may disappear in future
releases of OpenROAD,

i.e. when it goes Open Source.

There are already plans to do this for the OpenROAD Server (Durwin's
session at the UKIUA meeting covering this).

That is: MainWin runtime would not be shipped, so if you create your
apps depend on the MainWin license,

you would have to get one from Mainsoft directly.

OpenROAD code can be called from a JavaEE AppServer already:
You can send external userevents to running OpenROAD images within a JNI
class (Java Native Interface). 

External UserEvents have been available for years.

One problem there is the limited parameter passing capability, as
External UserEvents only allow one integer parameter.

But you can use this integer parameter to pass a handle to a data area
in a shared library, so the JavaEE component could

write data into that memory and the OpenROAD application can read the
data using the handle (and vice-versa).

This is some work to do, you also have to handle the datatype mapping,
think about load balancing and failover, etc.

The OpenROAD Server (and its Java interface) does this all for you,

so you can decide if you want to use an out-of-the-box solution or
implement a custom solution on your own.

Bodo.

Bodo Bergmann

Senior Software Engineer

OpenROAD Worldwide Development

Ingres Corp.

________________________________

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Pete
Rabjohns
Sent: Thursday, May 31, 2007 10:44 AM
To: International OpenROAD Users
Subject: Re: [OpenROAD-users] OpenROAD Server on Linux

Thanks Bodo.

When OR ships with MainWin does the run time license only include
OpenROAD apps? We have some Windows only additions to our application -
could they make use of the MainWin libraries? Presume I would need a
development license to cross compile.

Also noticed that MainWin supports a J2EE integration package - could
this be any use allowing OpenROAD code to be called directly from with a
J2EE App Server without the need to have the OpenROAD Server.

Pete

________________________________

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Bodo
Bergmann
Sent: 30 May 2007 10:24
To: International OpenROAD Users
Subject: Re: [OpenROAD-users] OpenROAD Server on Linux

DCOM on Linux (as on  other supported Unix systems)

is handled by the MainWin System Core (MSC) software

(supplied as part of the OpenROAD installation).

"dcomcnfg" is used to configure it (as on Windows).

You can run VASA on the Linux box itself, so you don't have to connect
"unauthenticated".

In addition to the "unauthenticated"  connection, you can also use
authentication.

For this purpose a Windows service "remotesa" is provided as part of the
MainWin installation

that needs to be installed on the primary domain controller for the
domain where authentication is used.

Its function is to provide authentication services for the Unix servers
that
are using the Visual MainWin DCOM.

The remotesa provides these authentication services by delegating them
to the Windows domain controller.

Bodo.

Bodo Bergmann

Senior Software Engineer

OpenROAD Worldwide Development

Ingres Corp.

________________________________

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Pete
Rabjohns
Sent: Wednesday, May 30, 2007 1:07 AM
To: International OpenROAD Users
Subject: Re: [OpenROAD-users] OpenROAD Server on Linux

Thanks Neil,

No problems yet, I just wondered what handled the DCOM interface and how
you configured it. 

I knew it was 'supposed' to work, but I wondered how and whether anybody
was using it in anger - just in case someone asked me the question.

Pete

________________________________

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of
Neil.Warnock at luminary.co.uk
Sent: 29 May 2007 17:22
To: openroad-users at peerlessit.com
Subject: Re: [OpenROAD-users] OpenROAD Server on Linux

Any specific problems, Pete? 4GL code is identical & VASA setup etc
pretty much the same. Need to put "unauthenticated" in the routing field
of the ASO config screen so that windows clients calling in don't go
through windows authentication. Other than that it's pretty straight
forwards (famous last words!).  Simple test is to use appserver client
DOS command:

comtestrso \\machinename <file:///\\machinename>  "unauthenticated"

from the remote client (and comtestaso/comtestspo from the server
machine if no joy)

Warning - a common gotcha that means you won't make it to first base is
getting VASA (on windows) to connect to the Linux AppServer machine.
VASA is an AppServer client so, guess what, it needs to connect
"unauthenticated" too (!)

If you come unstuck give me a shout. Be prepared to see a lot of
processes under Linux compared to unix. The way Linux does
'multithreading' involves starting up new processes for each thread (I
think that's what happens anyway) so you get shedloads of processes in a
real production environment. 

Neil Warnock 
Luminary Solutions 
Tel: +44 (0)845 371 4090 
Mob: +44 (0)771 265 0291  
Email: Neil.Warnock at luminary.co.uk 

For more information on Luminary go to http://www.luminary.co.uk
<http://www.luminary.co.uk/>  
Luminary Solutions Limited Registered in England No 4854134 VAT Reg No.
829 3166 13 
Registered Office: 16/17 Pavilion Business Park, Royds Hall Road, Leeds
LS12 6AJ 

________________________________

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Pete
Rabjohns
Sent: 29 May 2007 16:26
To: International OpenROAD Users
Subject: [OpenROAD-users] OpenROAD Server on Linux

Hi,

Just wondered what the differences in calling mechanism were if you run
you're OpenROAD Server on a Linux platform.

Has anyone done this that can give me a few tips on what's involved?

Thanks

Pete

Pete Rabjohns

Technical Manager

Atex
Email: pete.rabjohns at atex.com <mailto:pete.rabjohns at atex.com>  
Web: http://www.atex.com <http://www.atex.com/> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.peerlessit.com/pipermail/openroad-users/attachments/20070531/fb45c60f/attachment-0001.html 