[Openroad-users] OpenROAD Server on Linux
Pete Rabjohns
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.r...@atex.com
Web: http://www.atex.com
Neil.W...@luminary.co.uk
Neil Warnock
Luminary
Solutions
Tel:
+44 (0)845 371
4090
Mob: +44 (0)771 265 0291
Email:
Neil.W...@luminary.co.uk
For more information on Luminary
go to 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-us...@peerlessit.com [mailto:openroad-us...@peerlessit.com] On Behalf Of Pete Rabjohns
Sent: 29 May 2007 16:26
To: International OpenROAD Users
Subject: [Openroad-users] OpenROAD Server on Linux
Pete Rabjohns
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
Bodo Bergmann
are using the Visual MainWin DCOM.
To: International OpenROAD Users
Neil.W...@luminary.co.uk
Neil Warnock
Luminary
Solutions
Tel:
+44 (0)845 371
4090
Mob: +44 (0)771 265 0291
Email:
Neil.W...@luminary.co.uk
For more information on Luminary
go to 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
To: International OpenROAD Users
Pete Rabjohns
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
Bodo Bergmann
You can send external userevents to running OpenROAD images within a JNI class (Java Native Interface).
Pete Rabjohns
Thanks Bodo,
I was wondering what would happen with the Open Source OpenROAD on Linux – are you looking at the Mono project?
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.
Regards,
Bodo Bergmann
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 OpenSource, 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.
Durwin Wright
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...@ingres.com | Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 | USA +1 650-587-5523 | fax: +1 650-587-5550
From:
openroad-us...@peerlessit.com [mailto:openroad-us...@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-us...@peerlessit.com
[mailto:openroad-us...@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-us...@peerlessit.com
[mailto:openroad-us...@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.
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.
Joseph C. Kronk
One correction to what Durwin wrote below:
I will be giving the Ingres VIP presentation on June 20th, 2007 that gives more details on the OpenROAD Open Source plans instead of June 16th as it would be difficult to do the presentation from an airplane J
-Joe
Pete Rabjohns
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-us...@peerlessit.com [mailto:openroad-us...@peerlessit.com] On Behalf Of Durwin Wright
Sent: 31 May 2007 17:11
To: International
OpenROAD Users
Cc: Durwin Wright
gareth.2...@bt.com
Cheers,
Gareth Edwards
BT Global Services
tel: +44 (0)131 345 4671
email: gareth.2...@bt.com
Neil.W...@luminary.co.uk
Neil Warnock
Luminary
Solutions
Tel:
+44 (0)845 371
4090
Mob: +44 (0)771 265 0291
Email:
Neil.W...@luminary.co.uk
For more information on Luminary
go to 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-us...@peerlessit.com [mailto:openroad-us...@peerlessit.com] On Behalf Of gareth.2...@bt.com
Sent: 04 June 2007 16:50
To: openroa...@peerlessit.com
Subject: [Openroad-users] Sage line 50
Chris Clark
This isn't a recommendation it is more of an anecdote....
Many, many years ago I was working on an an add-on tool for SAGE and
didn't have an SDK (I don't think they even existed at that time). We
also needed to make changes to the data and we ended up using the
"import transactions" option (driven by a DOS command line tool) which
was documented. The issue with going that route is that you are forced
into batch replication, and the potential issues of time lag. Whether
that is an issue or not depends on the data (we were working with sale
inventory so it wasn't an issue as the add on tool could only sell
things that physically existed in the store, the time lag was that the
main SAGE repository thought things were in stock until the batch import
job ran).
Chris
Neil.W...@luminary.co.uk wrote:
>
> Hi Gareth,
>
> I worked on a project some time ago that extracted data from SAGE and
> found that read-only access was dead easy via ODBC. Dunno if there is an
> API for read/write too. If you want tips on using ODBC from OpenROAD
> see pres:-
> http://www.iua.org.uk/conference/Autumn2005/NeilWarnock_1005.pdf
>
> Assuming it's on windows (does Sage run on unix/linux?) I'd put a few
> AppServer SCPs on the windows machine which wrap and hide the ODBC stuff
> and expose them as a service to your OpenROAD clients.
>
> You will laugh / cry / head-butt your desk repeatedly when you see the
> data model... It didn't quite make it to 1NF !
>
> Neil Warnock
> Luminary Solutions
> Tel: +44 (0)845 371 4090
> Mob: +44 (0)771 265 0291
> Email: Neil.W...@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-us...@peerlessit.com
> [mailto:openroad-us...@peerlessit.com] On Behalf Of
> gareth.2...@bt.com
> Sent: 04 June 2007 16:50
> To: openroa...@peerlessit.com
> Subject: [Openroad-users] Sage line 50
>
>
> Win XP
> ORd 2006
>
> Hi All,
>
> A project has come up which requires interfacing with Sage Line 50. I've
> never used Sage before and apparently you need to be a business
> developer to have access to the Sage tables.
>
> Just wandered if anyone has any experience on doing this and could make
> comment on how easy/difficult it is.
>
> Cheers,
> Gareth Edwards
>
> BT Global Services
> tel: +44 (0)131 345 4671
> email: gareth.2...@bt.com <mailto:daryn...@bt.com>
>
>
>
> ------------------------------------------------------------------------
>
> ________________________________________________________________
> OpenROAD-Users mailing list
>
> You can maintain your subscription here:
> http://www.peerlessit.com/mailman/listinfo/openroad-users
>
> To unsubscribe click on this link
> mailto:openroad-user...@peerlessit.com&subject=unsubscribe
>
> To subscribe click on this link
> mailto:openroad-use...@peerlessit.com&subject=subscribe
________________________________________________________________
OpenROAD-Users mailing list
You can maintain your subscription here:
http://www.peerlessit.com/mailman/listinfo/openroad-users
To unsubscribe click on this link
mailto:openroad-user...@peerlessit.com&subject=unsubscribe
To subscribe click on this link
mailto:openroad-use...@peerlessit.com&subject=subscribe
gareth.2...@bt.com
From: openroad-us...@peerlessit.com [mailto:openroad-us...@peerlessit.com] On Behalf Of Neil.W...@luminary.co.uk
Sent: Monday, June 04, 2007 5:56 PM
To: openroa...@peerlessit.com
Subject: Re: [Openroad-users] Sage line 50
gareth.2...@bt.com
Pete Rabjohns
The easiest way of implementing this are those services that give you an e-mail address to map to a mobile number. Very simple to implement.
There are some that even allow you to map a mobile to an e-mail for free.
http://help.yahoo.com/help/uk/mobile/mobile-10.html