Euclid’s Web Oriented Architecture – Eight years ahead of the industry 

Being eight years ahead of the industry has its benefits, however, it can also create a few issues. Before I 
talk of the benefits of Euclid’s Web Oriented Architecture (and explain what it is), let me first disclose 
the most common issue that we have faced with our WOA – which is that it is so simple to use and 
leverage that some vendors and “techies” have criticized it (granted, just a few, as many have embraced 
our approach and achieved tremendous success). It seems that simplicity, rapid implementation, low 
maintenance and platform independence is not what everyone wants. The good news for Euclid and its 
customers is that over the past couple of years a comprehensive body of independent research has been 
released that conclusively finds that Euclid’s approach to web development and web integration is the 
most straightforward, most efficient and most successful approach that exists today. In fact, the 
evidence is so overwhelming that this year, eight years after we created our WOA, Microsoft has 
adopted and is now promoting our web service approach with its new .Net 3.5 Data Services.  

So what does “Web Oriented Architecture” mean? The term “Web Oriented Architecture” was coined in 
2006 by Nick Gall, a vice president at the Gartner Group, to give a descriptive and meaningful name to a 
method of web integration that is based on Representational State Transfer (known by the acronym 
REST by forward thinking technologists). Although the term “WOA” is somewhat new, the biggest and 
most successful web service providers, including Google, Yahoo and Amazon, have used the concepts 
behind REST for many years. Before Mr. Gall created this term, we at Euclid didn’t quite know what to 
call our architecture, so we just called it “Euclid’s Web Architecture” – which, unsurprisingly, was not 
adopted as an industry standard.  

The principles behind REST, which apply to network‐based software architectures, were first published 
in 2000 in the doctoral dissertation of Dr. Roy Fielding 
(http://www.ics.uci.edu/~fielding/pubs/dissertation/abstract.htm ). This is the same year (2000) that 
Euclid built its first web services based upon REST. REST provides a simple and efficient – yet powerful – 
set of protocols for requesting, receiving, updating and rendering data via the web. Under REST, web 
services are called using URIs (uniform resource identifiers) which then return anything from an XML 
data packet to a fully rendered HTML page. REST relies on the standard communication mechanism that 
forms the foundation of the World Wide Web, that is, it uses GET, POST, PUT and DELETE calls to 
communicate. In real world REST implementations, PUT and DELETE are rarely used, as most 
implementations support the GET and POST commands only. Generally, a GET command is used to 
retrieve data, while POST commands are used to change it. However, there are many instances where a 
POST (e.g., using a search form) is used to retrieve data. On the other hand, a GET command should 
rarely if ever be used to update data. These terms may sound complex, but you already use URIs, GETs 
and POSTs all the time. For example, the URI http://maps.yahoo.com/ uses a GET command to call 
Yahoo’s mapping service and render an HTML page on your browser. By specifying arguments in the URI 
request, the web service is able to return more specific information. For example, the URI 
http://maps.yahoo.com/map?q1=8120%20Woodmont%20Avenue%20Bethesda%20MD%20%2020814&
mag=5&ard=1#mvt=m&lat=38.991646&lon=‐
77.09698&mag=3&q1=8120%20Woodmont%20Avenue%20Bethesda%20MD%2020814  passes the 
location of Euclid’s Bethesda office to the web service which then returns a rendered map on an HTML 
page (note: I generated the previous link by clicking on the Map button on the organization record in 
ClearVantage).  

An example of how Euclid’s WOA implements the REST principles can be seen by calling Euclid’s events 
web service. For example, the following URI shows a list of upcoming events for one of Euclid’s clients: 
http://gateway.nwppa.org/euclidweb/cgi‐
bin/eventsdll.dll/EventList?ONWEBFLG=Y&REGONLINEFLG=Y&SESSIONBEGDATE=%3Egetdate()‐
1&SORT=SESSIONBEGDATE. What the request above is asking for is a list of all events that start today or 
after (SESSIONBEGDATE=>GetDate()), should be seen on the web (ONWEBFLG=Y), allow online 
registration (REGONLINEFLG=Y), and is sorted by date (SORT=SESSIONBEGDATE).  The next example 
displays the same information for the current month in a calendar view by adding the CALVIEW=now 
argument: http://gateway.nwppa.org/euclidweb/cgi‐
bin/eventsdll.dll/EventList?ONWEBFLG=Y&REGONLINEFLG=Y&CALVIEW=now&sort=SESSIONBEGDATE&
RESPONSEHEADERPAGE=main_template.htm. While these Euclid web services are returning full HTML 
pages, they can easily return an HTML chunk (e.g., http://gateway.nwppa.org/euclidweb/cgi‐
bin/eventsdll.dll/EventList?ONWEBFLG=Y&REGONLINEFLG=Y&CALVIEW=now&sort=SESSIONBEGDATE&
WMT=none) to embed into a content management system or PHP/ASP.NET/Cold Fusion page. The 
service can also return XML packets, which are extremely useful for AJAX programming and/or can be 
bound to any data control using any web development platform. For example, this link, 
http://gateway.nwppa.org/euclidweb/cgi‐
bin/eventsdll.dll/EventInfo?sessionaltcd=080435&WRP=eventinfo.xml&WMT=none, returns a standard 
XML data packet.  

In addition to easily retrieving information, Euclid’s WOA also makes it easy to add and update 
information, even for the most complex processes. For example, you can add a new member, register 
her for an event, purchase products, create a membership record, and process her credit card in real 
time all in one easy and very fast POST call. The following register.dll web service call (which would be 
submitted in the POST format) will register an existing customer for an event (and automatically 
determine if customer gets member v. nonmember pricing, the early bird rate, etc), add two functions, 
update her home phone, process the credit card, return a confirmation page and send a confirmation 
email. Please note that I cannot provide an active URI for this service because we do not want to create 
test records in a live database. Furthermore, even if I did provide an active URI, security settings in the 
architecture would prevent an unauthorized POST). So again, here is the example call for the 
aforementioned registration transaction:  

/Register.dll/Post?customercd=103&customer.homephone=2025551212&sessionaltcd=043443&functio
ncdlist=DINNER,BREAKOUT101&paymenttypecd=AMEX&creditrefnum=37324443434334&paymentrefe
xpdate=06/09 

The examples shown so far have been direct calls from an URI link. However, many organizations have 
existing websites or content management systems that they need to integrate with (e.g., display a list of 
featured events inside an existing homepage). How hard is this using Euclid’s WOA?  Using the event 
service examples above, the following voluminous amount of code is required: 
 In Perl:   

$mycontent = file_get_contents(‘/cgi‐bin/eventsdll.dll/EventList?MINORCAT=Featured 
SESSIONBEGDATE=>getdate()‐1&SORT=SESSIONBEGDATE’);  

In ColdFusion:  

<cfset theURLString = (“/cgi‐
bin/eventsdll.dll/EventList?MINORCAT=Featured&SESSIONBEGDATE=%3Egetdate()‐
1&SORT=SESSIONBEGDATE"/>  
<cfhttp url="#theURLString#" method="GET" resolveUrl="false" ></cfhttp>  
<cfset mycontent = #cfhttp.FileContent# /> <cfoutput>#mycontent#</cfoutput> 
 

While the examples above are for Perl and ColdFusion, it is just as easy to integrate a website (or a web‐
enabled application) with Euclid’s web services using any platform. For example, now that .Net 3.5 Data 
Services support REST (http://astoria.mslivelabs.com/), integrating with Microsoft products such as 
SharePoint and ASP.net is now even easier. It should be noted that a web development platform is not 
required to effectively utilize Euclid’s WOA – even a novice can create a completely functional website 
using plain old HTML. However, for more advanced developers, the possibilities are endless. As a 
starting point, a web developer can use her preferred language to dynamically build URI strings to create 
a highly personalized online experience for members. For example, a developer could use the 
member.dll web service to get a list of a member’s interests and then create a custom list of events and 
products on the member’s homepage based upon these interests – all in just a couple of minutes (OK, 
maybe an hour).  

In the opening paragraph I mentioned that there is a large body of evidence that shows that the 
WOA/REST approach to web integration is unsurpassed in flexibility, power and ease of use. The 
question of course is “compared to what?” AMS vendors that offer web integration tend to use one of 
three approaches. The first is the “Fat Page” approach where business and display logic are combined in 
a baseline set of pages that are then customized to meet client needs. This generally requires that a 
specific language, such as ASP or ColdFusion, be used to customize the website. In this common 
approach, no form of web services are used  and all of the site’s logic (including display, data, and 
processing) are hard coded into a site that is language dependent, difficult to maintain and almost 
impossible to upgrade. The second approach is where a vendor provides a set of proprietary objects that 
encapsulate functionality for data access and manipulation. This approach has the benefit of separating 
business logic from display logic (hence if a data table’s structure changes or a business rule changes, 
you don’t have to recode all the pages that rely on it). The disadvantages to this approach are that the 
objects themselves are usually accessible only through a specific language (e.g., to use our web objects 
you must use Visual Studio), it generally takes a good bit of expertise to “instantiate, utilize and release” 
the objects within the programming language, and the objects themselves don’t provide any tools to 
make rendering (displaying) information any easier – a developer usually has to write code to get data 
from objects and then bind it row by row and field by field to a visual control. Ouch. The final approach 
is the use of traditional SOAP‐based web services (XML‐RPC). This approach is the least commonly used, 
although some vendors make a small portion of their functionality available through these services to 
tout the use of web services. Rarely, if ever, is all the functionality needed to build a robust and 
integrated website available through the SOAP‐based web services that are provided. Hence, when this 
third approach is used, it is generally combined with the first approach (Fat Pages) to create the desired 
level of online integration and functionality. There are some advantages to SOAP‐based web services – 
in fact, we use them quite a bit at Euclid. A significant advantage is that they support UDDI – universal 
discovery description and identification – so when they are implemented correctly, these web services 
are self documenting. However, there are many disadvantages to this approach as well, the primary of 
which being a) you cannot just call a SOAP web service – you must use a programming language to do 
so, b) even when using a programming language, you cannot just call a SOAP web service ‐ you must first 
import the web service and build a “wrapper” around it so that the program language understands it 
(and if the web service changes, it will often have to be re‐imported) and c) SOAP web services require a 
lot of unnecessary overhead, making them slower and less scalable. There a quite a few other issues 
related to SOAP‐web service integration (see http://hinchcliffe.org/archive/2008/02/27/16617.aspx) – 
but the disadvantages can be boiled down to this: doing web integration using SOAP/XML‐RPC is just a 
lot harder and slower than it needs to be. 

Did I say there were three approaches? Actually, there is a fourth – Euclid’s Web Oriented Architecture 
approach. It is built upon the proven foundation of REST and adds numerous enhancements, such as 
display templates and centrally applied security settings,  to create the industry’s first and best WOA. 
However, you need not come to this conclusion based solely on what we think here at Euclid. Like I said, 
there is a whole body of evidence out there that supports our view. Here are few tidbits from it (for 
more, Google “REST” or “WOA”):  1) Amazon makes all of its web services available through both REST 
and traditional XML‐RPC calls (SOAP based web services), giving developers a choice.  The result is that 
85% of developers choose the REST approach to integrate their applications. I surmise that with 
Microsoft now supporting REST (http://astoria.mslivelabs.com/) , this percentage will increase; 2) all of 
the biggest web service providers, Amazon, Yahoo and Google (even Microsoft is coming on board) use 
WOA/REST as their web service foundation; 3) many organizations have abandoned the SOAP‐based 
web service model and moved to the WOA model with tremendous success 
(http://hinchcliffe.org/archive/2008/02/27/16617.aspx); and 4) WOA is the chosen platform for Web 2.0 
(http://blogs.zdnet.com/Gardner/?p=2631).  

So here we are, eight years later, and it seems the world is coming around to the Euclid way of doing 
things (e.g., using approaches that work as opposed to pushing a specific technology).  This is exciting. I 
have barely touched on the extensive functionality available through Euclid’s Web Oriented 
Architecture. However, you can see it in use in CV Mobile (a complete AMS available on your iPhone or 
Blackberry), CV Member Connect (everything your members need online), CV CLAS (chapter leader 
access system) and now even in the ClearVantage 7 smart client (which uses Euclid’s web services to 
access data). Exciting times indeed!