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

[David Tondreau]

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 shameless 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 accelerate 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 efficient 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://peerlessit.com/pipermail/openroad-users/attachments/20070501/6afcf238/attachment.html