 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / ColdFusion / Advanced Techniques / April 2006How to deploy mvc from server standpoint?.
Does anyone know how to deploy mvc framework from server standpoint?. I have all my business logic as cfcs but I want to move them to different server so that my cfm code is in one server and my cfcs are in another. Has anyone done this or point me in the right direction?. There are a couple of ways to do this but the easiest is to use XML. Either a REST approach or SOAP adn WSDL with CF will work. This would not exactly be a MVC pattern but more of a service pattern. You might want to create a service manager, which would act like your controller in mvc, and direct requests for specific methods to the right server or service. You might want to look at http://www.tartanframework.org/tartan/ > Does anyone know how to deploy mvc framework from server standpoint?. I have > all my business logic as cfcs but I want to move them to different server so > that my cfm code is in one server and my cfcs are in another. Has anyone done > this or point me in the right direction?. My first question would be why you don't want to have your .cfm pages and your CFCs on the same physical server? I would think you'd have to have a very compelling reason to do this in order to add the additional complexity as well as the performance hit you'll take by instantiating remote objects (if it's even doable, which I'd have to think about). Matt  SignatureMatt Woodward mpwoodward@gmail.com Adobe Community Expert - ColdFusion Thanx Matt for replying. Unfortunately it was not my decision. My company wanted to do it like that for security reasons. They wanted to make coldfusion apps like Java 3-tier with jsps in one server and servlets/ejbs in another, if possible. I thought that it would be like making it unncessarily complex. But didn't have facts to prove it. Can you give me some reasons why I should stick to keeping them in one server?. and why I shouldn't move them into different servers. May be I can convince them if there are some solid reasons. By the way, I'm using model-glue. Matt, Actually one of the main reasons to implement a more service oriented architecture, federated architecture, or n tiered architecture is performance and robustness. RIA's are a good example of abstracting the UI tier to the client machine and most RIA systems interact with the business layer through a remote request. This is also good for process separation which can make debugging and development a lot easier. This is actually best practice in the Java, .Net, Python, etc worlds. For example we just delivered an application for a mission critical system where the web accessible tier is on one cluster of machines with linux, and apache. The business layer is on another Cluster with JBoss servers (and no web server since they use web connectors to interact with the UI layer much like you can do with JRUN and CF), the database is on another cluster, messaging and integration on other cluster, etc. This is far more scalable than a traditional approach of putting the webserver, UI elements, application server and code on one layer. As for CFDEBUG.. note - Tartan works well with model glue. can you just use coldfusion mappings? like, if cfcs are on \\myoneserver\mycfcroot and you map /mycfcroot to that directory, can your cfm pages on server 2 use createobject("component","mycfcroot.mycfc"); never tried it, but seems like it should work. > Thanx Matt for replying. Unfortunately it was not my decision. My company > wanted to do it like that for security reasons. They wanted to make [quoted text clipped - 10 lines] > convince them if there are some solid reasons. By the way, I'm using > model-glue. i had a minute and gave this mapping idea a shot. i had a cfc on our nas drive, mapped it in administrator like so: /frameworkroot = \\ournasdrive\com\company\framework then in a cf page running on a differnet machine, did createObject("component","frameworkroot.mycfc") and it worked fine > can you just use coldfusion mappings? > [quoted text clipped - 18 lines] >> convince them if there are some solid reasons. By the way, I'm using >> model-glue. > Thanx Matt for replying. Unfortunately it was not my decision. My company > wanted to do it like that for security reasons. I'd be curious to hear the reasoning behind the argument that putting your CFCs on another server necessarily gives you increased security. > They wanted to make coldfusion > apps like Java 3-tier with jsps in one server and servlets/ejbs in another, if > possible. I thought that it would be like making it unncessarily complex. But > didn't have facts to prove it. More moving parts = more complex. I guess I'd just have to hear a compelling argument for doing this other than a blanket "because it's more secure" statement. The main reason this sort of setup is used in the Java world is for distributed computing purposes, not for security. I'm not saying there is absolutely no security benefit for doing this--conceptually one could argue this is similar to putting your database server behind a firewall so it can't be hit by the outside world--but that reason alone doesn't make the argument complete in my mind. > Can you give me some reasons why I should stick to keeping them in one > server?. and why I shouldn't move them into different servers. May be I can > convince them if there are some solid reasons. By the way, I'm using model-glue. Biggest one I can think of would be performance, not to mention deployment complexities, increased hardware requirements (if your CFCs are on a server other than the ones your CFML pages are on, you better be darn sure you have redundancy there!), and increased licensing costs for CF (different physical server = another CF license). I'd be very surprised if you didn't take a big performance hit calling the objects from another server, but I'd have to experiment with timing the mapping process Marc E outlines. I guess to me you're asking why you shouldn't move them onto different servers, when the real question in my mind is why you *should*. Security alone doesn't sell it for me, but there may be other reasons in your particular environment why this makes sense. Matt SignatureMatt Woodward mpwoodward@gmail.com Adobe Community Expert - ColdFusion Matt, I think I'm going to go convince my people not to proceed in that direction. I have everything written using model-glue framework and I don't want to complicate stuff just to adhere to the policy that may not apply to all languages since not all languages follow the same architecture. Thanx Marc. At the worst case, if I have to go with that architecture, I will look into your idea. Looks pretty simple. Thanx guys for your suggestions. They are helpful. we've actually been trying to go in the opposite direction, mostly for ease of deployments. we have a cluster of CF servers, and every time we do a code push, we have to migrate to all servers. it's annoying and prone to problems. We want to move all our code onto one machine, such that no webserver has any code on it at all. we deploy code to one machine, and all webservers on the cluster benefit from the push. this machine is not web accessible at all and thus one could say less prone to security problems than a webserver is, although i'm not sure that's such a good reason. mostly for us it's ease of deployment. separating normal cfm files from objects seems kind of silly, when if you want security you'd put all code on a separate, non-web-accessible machine. thanks to CF mapping, you can just point "/" to the code root of hte machine on which the code lives, and all is well with the world. This is actually how we have our internal environment set up, it's just our production environment where our host is a pain in the a.s about it. i'd be extremely surprised to see a performance problem with this setup. It's not like the web servers are in philly and the code servers are in taiwan, sending thousands of bytes per second. you've probably literally got the webserver sitting right beside the server on which the code lives. it's virtually the same thing as just keeping CF on the C drive and all the code on the D Drive (assuming disk speeds on the machines are adequate). > Matt, I think I'm going to go convince my people not to proceed in that > direction. I have everything written using model-glue framework and I [quoted text clipped - 8 lines] > > Thanx guys for your suggestions. They are helpful. > we've actually been trying to go in the opposite direction, mostly for ease > of deployments. we have a cluster of CF servers, and every time we do a code > push, we have to migrate to all servers. it's annoying and prone to > problems. Actually that's exactly the way we have our new high availability environment configured. All the code runs off an EMC device. Not sure why I didn't draw this parallel yesterday with running the CFML on one server and the CFCs on another server--as long as you have a sufficiently fast network (we're on gigabit) and device/drives (our stuff is fiber channel), then as you mention below performance probably isn't an issue. I'd be curious if doing this over 100 megabit with more low-end hardware would perform as well as having things on a local drive, however. > We want to move all our code onto one machine, such that no webserver has > any code on it at all. we deploy code to one machine, and all webservers on > the cluster benefit from the push. this machine is not web accessible at all > and thus one could say less prone to security problems than a webserver is, > although i'm not sure that's such a good reason. mostly for us it's ease of > deployment. Yep, very true, and although the NAS/DAS device isn't *directly* accessible via the web, remember that's it's accessible by the user that's being used by the web site users, so there isn't a huge security benefit here vs. having the code locally. You're absolutely right > separating normal cfm files from objects seems kind of silly, when if you > want security you'd put all code on a separate, non-web-accessible machine. Yeah, this is where we head was earlier in the discussion--putting the CF "pages" on one server and the CFCs on another just seemed a bit wacky to me. > thanks to CF mapping, you can just point "/" to the code root of hte machine > on which the code lives, and all is well with the world. > This is actually how we have our internal environment set up, it's just our > production environment where our host is a pain in the a.s about it. Right, this is what we do on our production environment but we don't even use a CF mapping (though you could). We just point our web server to the EMC device and everything else just falls into place, provided you've set up the user CF and your web server process (or using "connect as" in IIS in W2K3) are running as so they have access to the network storage device. > i'd be extremely surprised to see a performance problem with this setup. > It's not like the web servers are in philly and the code servers are in > taiwan, sending thousands of bytes per second. you've probably literally got > the webserver sitting right beside the server on which the code lives. it's > virtually the same thing as just keeping CF on the C drive and all the code > on the D Drive (assuming disk speeds on the machines are adequate). True, good point. We have extremely good performance (might even be *faster* than local drive speed) with our EMC device, and again I'm not sure why I didn't see this parallel yesterday in the discussions. Blame it on a very hectic week. ;-) Matt SignatureMatt Woodward mpwoodward@gmail.com Adobe Community Expert - ColdFusion Marc, That was a great idea. So basically if I have a server within vendor dmz and another server within trusted network, I can put the "/" mapping in my vendor dmz server and let it point to all the code in trusted network server and the trusted network server will not have any webserver at all?. So if the user accesses the site, it goes to the vendor dmz server and then it gets the page from trusted network server due to mapping?. I think so. also, since the cf files are just byte code when CF actually gets them, the "code" itself isn't being read from disk except for the first time it's loaded into the JVM. so in terms of disk reads, it's minimal except on startup. that is, if my understanding of jvm is correct. i asked about this on java.programmer, and someone on there said the same thing you did matt: that reading from the external drive could conceivably be faster if the drive on that machine is faster, as is apparently typical with storage type devices. i'm no expert here, though. of course, all fo this is probably splitting hairs anyway. > Marc, That was a great idea. So basically if I have a server within vendor > dmz [quoted text clipped - 6 lines] > the > page from trusted network server due to mapping?. Yeah I dont think Matt has had experiance with these sort of n tiered architectures. Your not going to get performance issues from executing a cfc thats on another server in this sort of architecture any more than having a database on another machine will be a bottle neck. Often the reverse. What CFDEBUG was trying to do is often considered a best practice and usally its trivial to show performance gains but just testing the typical 3 tiered application approach versus a N tiered application using a load and testing tool. Robi |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.