[Openroad-users] David Tondreau will be giving a web cast...

Wed May 2 14:59:05 EST 2007

There seems to be some confusion here. Internally we use client-server -
no problem, but as a matter of fact we have controlled packaging rather
than allow downloads for software installation. 
The other problem we have is that we do not control where and how our
external users work and what rules they have w.r.t. installing software
etc , hence the web browser approach. Some companies - particularly
Shipping Companies are completely locked down behind firewalls (as we
are), others, such as small freight-forwarders may have a direct
internet connections and no rules. Basically they are not "our" clients
as described below but external users who we allow to use our web site
and change our data.

David, the above explanation came from our firewall man.

Robert 

-----Original Message-----
From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of David
Tondreau
Sent: Wednesday, 2 May 2007 4:17 p.m.
To: International OpenROAD Users
Subject: Re: [Openroad-users] David Tondreau will be giving a web
cast...

Hi Robert,

Its OpenROAD that I am looking to reproduce faithfully -- in another
product -- that's what's hard.  The real problem is putting definition
around "enough functions to be useful."  It's a bit of pulling on the
string at the end of the sweater.  Where do you stop before the whole
thing unravels?  

However, there is another issue from your post I would like to examine.
You said:

   "we do not allow eclient,to avoid clients having to download it."

I'm curious as to why.  Do you allow your clients to install Adobe
Acrobat to view a PDF file (identical concept - requires a digitally
signed ActiveX control).  Are they allowed to run Windows Update (yep,
ActiveX).  Could they run a Flash page (needs a plugin).  Run Java
Applications?  View Office documents?  All plug-ins that work against
"downloaded" content.  And the OpenROAD content is smart.  It only
downloads when it changes.  So I'd love to understand why the OpenROAD
infrastructure is different.  Perhaps there is a way for us to make it
more "acceptable."

Or is it a packaging issue?  I.e., the application is very large and
downloading it would conceivably take a long time?  Did you know the
.NET redistributable is 22.4 MB? Acrobat 8 -- 27.5 MB.  Yet OpenROAD's
eClient is a mere 3.5MB.  Even a large 20 MB image file will compress to
less than 2 1/2 MB.  Not to big in today's terms.

Or, it is it a security issue?  The requirement for a user to be a
power-user before it can be installed?  This can be solved with a push
rather than a pull based distribution of the eClient and application.

Anyway, very interested in your feedback.

David

-----Original Message-----
From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Robert
Allely
Sent: Tuesday, May 01, 2007 11:31 PM
To: International OpenROAD Users
Subject: Re: [Openroad-users] David Tondreau will be giving a web
cast...

David, I think you understood my question, but in fact I would not
expect it to reproduce any other product faithfully, just allow me to
use OpenROAD to write a web page that would work - with enough functions
to be useful.
Robert

-----Original Message-----
From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of David
Tondreau
Sent: Wednesday, 2 May 2007 2:39 p.m.
To: International OpenROAD Users
Subject: Re: [Openroad-users] David Tondreau will be giving a web
cast...

Hi Robert,

We looked at this and while it is conceptually possible, it's a
tremendous amout of work and would take several years to implement it --
only to end up with something that is probably two years of of date.
The two biggest problems are what to generate and how to reproduce the
native application faithfully.  For every person that wants .NET,
another will want PHP and AJAX and a third will want something else.
None of them have the richness and ease of OpenROAD and reproducing it
faithfully would be next to impossible.

That said, the tide is turning a bit on this issue of "rich internet
applications" and the idea of "downloading the application" as being a
bad idea.  Check out this article: 

http://www.ddj.com/199100436 

Regards,

David

David Tondreau
Architect
Ingres Corp.
01-703-738-4811 (w/m)
david.tondreau at ingres.com

-----Original Message-----
From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Robert
Allely
Sent: Tuesday, May 01, 2007 10:17 PM
To: International OpenROAD Users
Subject: Re: [Openroad-users] David Tondreau will be giving a web
cast...

David,

For me the ideal environment is OpenROAD, and I find it very easy to
use.
Problem is, the web page must be written in something else- we do not
allow eclient,to avoid clients having to download it. Most of our web
development is outsourced and the latest trend is the .net framework. If
only OpenROAD could be used to generate web pages without the use of
eclient.. Is there any possibility that this could happen?

Robert Allely
Ports of Auckland NZ 

________________________________

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of David
Tondreau
Sent: Wednesday, 2 May 2007 1:05 p.m.
To: International OpenROAD Users
Subject: Re: [Openroad-users] David Tondreau will be giving a web
cast...

Hi Jim,

Actually, I was trying to arouse this kind of exchange!  So flame war?
No way, I don't believe in them -- unless it turns into personal attacks
which I'm sure won't happen with this group!  What I do believe in is
that when bright minds get together, they are likely to disagree on some
things because of their experiences and personal paradigms -- all of
which are material.  But I also believe we can learn from one another
and understand each other better if we are truly listening.  That's the
important part.  Its also important to note that any e-mail exchange
will only tell a fraction of the story as certainly is the case here.
To wit...

There are two primary ways in which our customers use OpenROAD.  First
is in a homogeneous environment where OpenROAD fat clients talk to a
database (Ingres or otherwise via the gateway) or OpenROAD thin clients
talk to the OpenROAD Server.  By homogeneous here I mean that the
majority of the customer's Ingres app development is done exclusively
with OpenROAD.  Not too many other tools fit in.  Interestingly, this
constitutes the vast majority of our customers.  Second OpenROAD is also
used a heterogeneous environment in which arbitrary clients (OpenROAD,
ASP, Java, whatever) consume services from an arbitrary server (the
OpenROAD Server, other application servers, other or API based data
services).  This is a small (but growing) set of our customers.

Like any organization, we have several competing agendas that are
constrained by time and resource.  One agenda is to provide the best
possible support to our customers.  This means that supporting our
existing releases is of paramount importance and this takes a lot of our
resource.  A second agenda is to make sure we can naturally evolve the
product within the resource constraints that any company has.  This
means we tend to do smaller, shorter term enhancements that over time
will evolve to larger end goals.  Third, to be a technology leader, we
need to be fully "buzz word" compliant (used loosely here as I don't
want to understate the value of standards).  We haven't focused on this
much in the past because at CA, we weren't a "growth" technology -- we
were simply being sustained for the user base.  Anyone who see's
Durwin's presentations at the UKIUA next month will realize that this is
no longer the case (yes, a sha meless plug to attend!).  To be standards
based, we have to support things like better OO, XML (which we do),
SOAP, etc.  Finally, we need to be responsive to the requests we have
from customers and other users to add new features to the product.  It
doesn't happen in the time frame that most people want (getting an idea
past the QA people is hard!) but it happens.  Most often though, we
assemble amalgamations of user requests and integrate them with our own
ideas before they get implemented.  This planning and engineering takes
time.  Nonetheless, the sheer volume of the requests ensures that a lot
won't make it into the product for a while.  I believe that the open
sourcing of OpenROAD is going to help dramatically in this area.  If a
customer has a true need for a specific feature and the skill set to
implement it, it can happen immediately.  This is actually already
happening.  We have a strategic business alliance with o ne partner
where they have brought resources to the project ! to accel erate the
implementation of a major new feature.  This is very exciting and marks
a dramatic new shift for the technology.  I fully expect people to start
ripping apart the Workbench environment as soon as we open source it.
Hopefully we will do that in a coordinated way!

Anyways, to your issues.  The decision to support a "proprietary" HTTP
transport for OpenROAD Client to OpenROAD Server communications was
smart and defendable.  It is in no way in conflict with a standards
based (i.e, SOAP/XML) interface which has been possible (albeit
non-trivial) for years.  To understand this, you need to understand the
intent of the HTTP transport.  Simply put, it was to respond to requests
from many customers using heterogeneous OpenROAD architectures to make
it as easy as possible to deploy an existing OpenROAD thin client
application talking to an OpenROAD Server across the web.  The current
DCOM interface didn't allow them to do that.  That's all it was designed
to do and it does it well!  Because the OpenROAD Client and Server are
tightly bound, there is no need to go through the overhead of generating
an XML document on the client (which would be much larger and therefore
less effici ent by definition), transmitting that with a SOAP header to
an Application Server (a heavier weight process than a simple web
server) where the header is ripped off, the enveloped passed into the
Server only to have to be parsed, processed and the reverse trip made
the same way.  Its unnecessary overhead which is why we didn't do it.
It was in this particular context that I said XML is "verbose-and-slow".
Instead, with the HTTP transport,  you change one line of code in the
client and the only additional resource you need is a simple web server
(IIS or Apache) with a minimally altered "gatekeeper" application.  You
can literally go from a intranet only to web deployment in a matter of
minutes.  I demonstrated this in the last of my webcasts.  That's the
value of the HTTP transport.  Nothing else.

And you are right.  We need to support other clients too.  And we do!
We have a low level COM interface to the server that you can drive via
ASP and JSP.  We provide a JNI and C# API so you can get to the OpenROAD
Server from Java and .NET.  And we've had XML In/Out in the OpenROAD
Server for years that customers are using it in very large deployments.
Check out section 6-13 of the Server Reference Guide for more
information.  I remember Neil Warnock gave a presentation called "Web,
Wireless and Beyond" way back in 2003 (Spring UKIUA meeting) using
OpenROAD to serve and consume web services.  So its not true that we
don't support this.  We do.  Do we need to make it easier?  Absolutely!
The Proxy Generator will make it easier to serve up web services via
your favorite Application Server by automatically generating Java or C#
proxies of OpenROAD Server services.  This is the way for us to go.  W e
don't want to be in the business of providing YAAS (yet another
application server).  What we do need to do is make it easier to
interface with the industry standard application servers (JBoss,
WebLogic, WebSphere, etc.).

The more our stack opens up and the use of it expands to include more
heterogeneous environments, the more we will focus on interoperability
and ease of use.   Developers like you tend to be ahead of that curve
and I think thats why you see some of these limitations.  But you have
some great ideas like querying Xpath -- very cool.  Generating and
validating from XML schemas is another.  Personally, I want a persistent
XML data store to coerce OpenROAD object instances to and from XML and
be able to persist them in the database (like Hibernate and we're
actually pretty close on this one).  I want to provide better support
for generating client proxies for any discoverable Web service.

At the end of the day, it's my hope that being open source, the entire
community will not only help us form these future directions with great
suggestions like the ones you given but actually participate in their
implementation!

Regards,

David

On Tue, 2007-05-01 at 23:09 +0100, Jim Antill wrote:

	Hi,

	I'll say here that I've never used OpenROAD to develop a
web-based app, instead using Java, XML and HTML etc. Apologies if any of
these points are wide of the mark.

	I must admit I'd assumed that Client->Server communication would
be handled by using something generic like SOAP. It's a bit of a
sweeping statement to say that SOAP and XML are slow and verbose, it
would surely depend on the size of the messages you were sending etc. Or
is it that an OpenROAD client/server setup needs to transfer a lot of
information in it's conversations. Having the facility to exchange
information in either format would be a lot more flexible.

	Opening up OpenROAD "web-services" would be great, apart from
OpenROAD's total lack of any XML functionality (and the aforementioned
lack of a SOAP interface). As with Adrian, I've raised this point a
couple of times and seemingly nothing has happened. XML is an extremely
powerful way of presenting and manipulating data as it presents the data
in a structure that can be easily validated. It also permits querying
with Xpath, transforming with XSLT, and is useful when transporting data
between the different application layers etc.

	The omission of these tools, I think, would seriously limit what
an OpenROAD service and web-based architecture could do. For example, it
wouldn't be able to build HTML dynamically by transforming XML documents
using XSLT (something that's done quite frequently), query XML documents
to locate specific parts etc. And it would be difficult to handle the
XML contents of a SOAP message. XML document generation tools would also
be required so that well-formed documents could be built
programatically. Fair enough, this could be introduced by using
something like MSXML but that introduces yet more complications.

	Maybe the work that Luminary are doing will introduce XML
processing to OpenROAD which will be a long-awaited, and very gratefully
received, feature.

	These points taken together would seem to limit an OpenROAD
client to being used usefully with an OpenROAD server and vice-versa
using it's non-SOAP interface. IMHO with OpenROAD now being capable of
building web-based apps XML processing suddenly becomes a very core
feature, one that must be supplied by Ingres rather than developed by
individual developers. Supplying the XML tools would make SOAP based
messaging (particularly handing the XML contained in the SOAP message on
the server side) much more achievable and so open up a whole range of
new possibilities.

	And if you're supplying XML tools, then part of this must be an
interface in the workbench to allow XML to be created and validated
against schemas. Writing XML documents can be tricky, made next to
impossible by using something that doesn't highlight errors such as
incomplete tag-pairs etc.

	Just my opinion - I'll stand back and warm my hands on the
rising flames :-)

	Regards,
	Jim

	On 1 May 2007, at 14:01, David Tondreau wrote:

		Hi Pete,

		Actually, I'm going to post the DAL generation utility
as an open source tool and community project.  We are working on a
publicly accessible web site to host these projects.  Stay tuned!

		The HTTP protocol is very specific to an OpenROAD client
talking to an OpenROAD server and uses an internal encoding of the data
stream -- i.e, not-soap-because-soap-and-xml-are-too-verbose-and-slow
;-).  Its part of a strategy to make sure we keep the link between an
OpenROAD Client and the OpenROAD Server very simple and is a unique
solution to that configuration.

		I agree that we need to make it easier to "publish" SCPs
as web services.  The Proxy Generator that is being contributed by
Luminary Solutions will do exactly that.  It will support the automatic
generation of Java and C# proxies to object and SCPs in the OpenROAD
Server so that they can be easily published using your favorite
application server.  Again, more on this as we get closer.

		Regards, 

		David 

		David Tondreau
		Architect
		Ingres Corp.
		01-703-738-4811 (w/m)
		david.tondreau at ingres.com 

________________________________

		From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Pete
Rabjohns
		Sent: Tuesday, May 01, 2007 8:15 AM
		To: International OpenROAD Users
		Subject: Re: [Openroad-users] David Tondreau will be
giving a web cast...

		Great talk - sorry I missed it, but I enjoyed the
Webinar recording on Hello OpenROAD.

		Quick question on your DAL, which you mentioned you have
something to auto generate the SQL for simple DB classes - is that
something that is planned for inclusion into OpenROAD?

		Another question - is the HTTP protocol used to talk to
the App Server a SOAP protocol, or an OpenROAD looky-likey? 

		It seems so close to opening up to direct Web Services
into the OpenROAD Server without the need to build your own translation
stack. It would be a nice feature to expose SCP's and GSCP's as Web
Services.

		Pete

		_______________________________________________
		Openroad-users mailing list
Openroad-users at peerlessit.com

		To unsubscribe please click on this link

mailto:openroad-users-unsubscribe at peerlessit.com&subject=unsubscribe

		To subscribe please click on this link

mailto:openroad-users-subscribe at peerlessit.com&subject=subscribe 

	_______________________________________________
	Openroad-users mailing list  Openroad-users at peerlessit.com

	To unsubscribe please click on this link

mailto:openroad-users-unsubscribe at peerlessit.com&subject=unsubscribe

	To subscribe please click on this link
	mailto:openroad-users-subscribe at peerlessit.com&subject=subscribe

***
This e-mail is privileged and confidential.  If you are not the intended
recipient please delete the message and notify the sender at Ports of
Auckland Limited.
***

_______________________________________________
Openroad-users mailing list  Openroad-users at peerlessit.com

To unsubscribe please click on this link
mailto:openroad-users-unsubscribe at peerlessit.com&subject=unsubscribe

To subscribe please click on this link
mailto:openroad-users-subscribe at peerlessit.com&subject=subscribe 

_______________________________________________
Openroad-users mailing list  Openroad-users at peerlessit.com

To unsubscribe please click on this link
mailto:openroad-users-unsubscribe at peerlessit.com&subject=unsubscribe

To subscribe please click on this link
mailto:openroad-users-subscribe at peerlessit.com&subject=subscribe
***
This e-mail is privileged and confidential.  If you are not the intended
recipient please delete the message and notify the sender at Ports of
Auckland Limited.
***

_______________________________________________
Openroad-users mailing list  Openroad-users at peerlessit.com

To unsubscribe please click on this link
mailto:openroad-users-unsubscribe at peerlessit.com&subject=unsubscribe

To subscribe please click on this link
mailto:openroad-users-subscribe at peerlessit.com&subject=subscribe 

_______________________________________________
Openroad-users mailing list  Openroad-users at peerlessit.com

To unsubscribe please click on this link
mailto:openroad-users-unsubscribe at peerlessit.com&subject=unsubscribe

To subscribe please click on this link
mailto:openroad-users-subscribe at peerlessit.com&subject=subscribe 
***
This e-mail is privileged and confidential.  If you are not the intended recipient please delete the message and notify the sender at Ports of Auckland Limited.
***