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

Wed May 2 23:17:30 EST 2007

Hi Gabriela,

Yes indeed.  We announced last fall during our Australia and New Zealand
Road show that we would be taking OpenROAD open source.  That project is
underway.  Look for details in the coming months.

Regards, 

David 

David Tondreau
Architect, Ingres Corp.
http://community.ingres.com/ <http://community.ingres.com/> 

________________________________

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Rheinfelder,
Gabriela, OPES15
Sent: Wednesday, May 02, 2007 8:52 AM
To: International OpenROAD Users
Subject: Re: [Openroad-users] David Tondreau will be giving a web
cast...

David,

you mentioned the words 'open source'. 

Is there any roadmap for Open Road in this direction already defined or
considered?

That would be great news and a consequent step in the right direction
!!!

Regards, 

    Gabriela Rheinfelder 

___________________________________________________________ 

Gabriela Rheinfelder 

EADS Deutschland GmbH 
Defence Electronics 
Mission Support Software (OPES15) 
89077 Ulm 

phone    +49-(0)731-3923483 
fax      +49-(0)731-392203483 
email    gabriela.rheinfelder at eads.com 
___________________________________________________________ 

EADS Deutschland GmbH
Registered Office: Ottobrunn
District Court of Munich HRB 107 648
Chairman of the Supervisory Board: Dr. Thomas Enders
Managing Directors: Dr. Stefan Zoller (chairman), Michael Hecht 
This E-mail and any attachment(s) to it are for the addressee's use
only. It is strictly confidential and may contain legally privileged
information. No confidentiality or privilege is waived or lost by any
mistransmission. If you are not the intended addressee, then please
delete it from your system and notify the sender immediateley. You are
hereby notified that any use, disclosure, copying or any action taken in
reliance on it is strictly prohibited and may be unlawful. - Thank you.

________________________________

Von: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] Im Auftrag von David
Tondreau
Gesendet: Mittwoch, 2. Mai 2007 14:29
An: International OpenROAD Users
Betreff: Re: [Openroad-users] David Tondreau will be giving a web
cast...

Jim,

You're definitely on the right track and this is a great way to exploit
OpenROAD on the Server side for those who want to do MVC.  This
capability is in the product now but you have to write (or generate) all
the "glue" code (the proxies) yourself.  The Proxy Generator will help
in this area when you have a very large application with 100s or 1000s
of services.  That said, we have many customers in prodution with Java,
ASP, JSP, etc. driving the OpenROAD Server today and I suspect that the
total overall level of engineering for fielding those applications was a
fraction of a pure Java implementation.  Kim's recent post points to
this.

We do still have work to do exploiting XML resources (XPath, XML
Schemas, etc.) at design time.  I suspect this will evolve more quickly
once we are open source.

Regards,

David

________________________________

From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Antill, Jim
Sent: Wednesday, May 02, 2007 7:04 AM
To: International OpenROAD Users
Subject: Re: [Openroad-users] David Tondreau will be giving a web
cast...

David,

Thanks for the reply. I admit to maybe slipping behind on the OpenROAD
front as regards the AppServer side of things. I'll have a look at this
to catch up a bit.

I guess my view of it is that I'd like to write servlets and other
server-side code in OpenROAD as well as Java. And it sounds as if the
Luminary proxy generator will allow me to do this. So, I'd have an HTML
view layer with OpenROAD running on the backend (on say Tomcat)
providing my Controller and Model layers.

Given this capability I'd like to think that maybe OpenROAD could be
used to develop some of the neat server-side stuff that Java is used to
do. One particular point of interest is in MVC frameworks used to
control web-based applications, an example being Struts. Being able to
build frameworks such as this in OpenROAD would, I think, be very
interesting. And in order to do this we'd need access to an XML parser
allowing us to use XPath, XSLT and also the ability to convert objects
to/from XML etc. Which is what my original mail was angling towards.

Or maybe another way would be to interface OpenROAD servlets to a
Struts-like Java framework ( in Struts case possibly by linking Struts
actionclasses to OpenROAD servlets via the proxies?), using the Java
framework to effectively control the running of an OpenROAD application.
The point of this would be to continue to use existing OpenROAD skills
whilst providing some of the features that Java does.

Having this kind of setup would enable an existing non-web (but OO)
OpenROAD application to be taken to a web-based environment where a
non-OpenROAD client (HTML/JSP etc) could be designed whilst retaining
the OpenROAD userclasses that form the business logic on the
server-side.

Or maybe this can be done now and I just don't know about it?

Regards,
Jim

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

*************************************

This e-mail has been received by the Revenue Internet e-mail service.
(IP)

*************************************

	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 sh! ameless 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! one 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 effic! ient 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.  !
We 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 message has been delivered to the Internet by the Revenue Internet
e-mail service (OP)

*************************

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