[Openroad-users] David Tondreau will be giving a web cast...
Antill, Jim
jantill at revenue.ie
Wed May 2 21:04:10 EST 2007
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/be5536d6/attachment.html
More information about the Openroad-users
mailing list