I think I can speak directly to the architecture question based on my experience in building architectures over the years and my more recent experience with a very complex Rich Internet Application. I have seen many try and shoehorn a three-tier architecture into something useful for a Rich Internet Application by simply adding a facade to their business-tier. However, this tends to fall down because as it turns out many of the assumptions made in the presentation-tier of a web application are very different to those of a Flash application. Of course, you would expect that, but it seems that the assumptions some how spread to the business-tier thus infecting there two distinctly different presentation-tiers. I have seen people put a lot of work into their facade to make up for this, but that is a futile effort IMHO. An ivory tower view would be that a tight coupling between the presentation-tier and the business-tier is the problem. Well that may be, but I have realized that while decoupling may be a worthy goal it often isn't practical in a three-tier approach. That isn't to say there isn't an answer; it is just to say that I didn't find one with a three-tier approach.

I have found a four-tier architecture to be most appropriate. The four tiers are database, service, business, and presentation. The database-tier and presentation-tier is no different than you would have in a three-tier architecture. The service-tier wraps up the database-tier as a service as well as any other things an application might need such as authentication and authorization, workflow, search, etc. None of these services enforce business rules for an application. In fact, they are designed such that they no nothing of the application that uses them. Further, these services are available from a variety of APIs depending on the needs of the application. In most of my applications the services are available as a local object or as a web service. The business-tier is a little more tricky. It needs to wrap the service-tier and enforce business rules for the application. However, since the kind of applications we are talking about are both HTML and Flash-based there needs to be two implementations of the business-tier, one in CFML/Java and one in Flash. The CF-based presentation-tier would use a business-tier implemented in CFML and/or Java, while the Flash-based presentation-tier would use a business-tier implemented in Flash.

Now some may think initially that having two different business-tier implementations is a bad thing. However, I have found that once you separate out the "business" services into their own distinct tier, what is left tends to be specific to the application and a web application is really different than a Rich Internet Application. Thus, the four-tier approach actually gives maximum reuse, while maintaining proper separation. As you can imagine, in the context of a web application the service-tier is accessed using a local object API, while in the context of a Rich Internet Application the service-tier is accessed using a web service API.

Matt Liotta
President & CEO
Montara Software, Inc.
http://www.MontaraSoftware.com
(888) 408-0900 x901


On Dec 6, 2003, at 7:35 AM, robi sen wrote:


Sean,

Can you mention any Frameworks or Methodologies that focus on more of
service oriented architecture or approach to building applications that
are focused on using web services?

Thanks,

R


"Like Flash / Flash Remoting, Flex also requires a remote-CFC interface to interact with ColdFusion so I suspect that similar concerns apply for integrating Mach II with Flex, i.e., the problem is that Mach II does not expose a Web Service-style API."



----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).

An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]


----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.


CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).

An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]

Reply via email to