I don't think the underlying technologies behind webservices will necessarily improve so much, as the ability to return things like java objects which are themselves executable code. There are a whole bunch of security issues with doing that from a client perspective, but it would be nice to see.
I think the performance of webservices and calls to them will probably improve as time goes on, and the networking protocols they use are changed/improved, but how much that improvement will be is pretty hard to tell. There is also the question of how to best architect your applications so they are fast, but still keep the core logic at a remote location. Something similar to writing a complex app with a combination of JavaScript and ColdFusion. How much of the logic do you put in the JavaScript, how much on the server, and how do you minimize the number of function calls required for your app to function. Spike > -----Original Message----- > From: Douglas Humphris [mailto:[EMAIL PROTECTED]] > Sent: 06 September 2002 15:18 > To: [EMAIL PROTECTED] > Subject: RE: [ cf-dev ] .cfm enryption > > > Thanks for this Spike. > > The performance cost is more than I thought. I'm still not > completely off the idea...just mostly. A cost of 50ms isn't a > problem, but 500ms would be. > > Do you think that the web service technology will improve in > performance? (I don't really understand it that much yet) > > Douglas > > > -----Original Message----- > From: Spike [mailto:[EMAIL PROTECTED]] > Sent: 06 September 2002 13:05 > To: [EMAIL PROTECTED] > Subject: RE: [ cf-dev ] .cfm enryption > > > Just ran a few tests on a simple component. The component > allows you to store individual items per user. Something like > a shopping cart. The data for each user is stored in the > server scope on the server which hosts the cfc. > > Initial results from locally invoked component never idicated > anything other than 0ms for the page to render. > > When the component was invoked as a webservice from another > computer on the same LAN the numbers were from 40-50ms. > > In both the above cases, the numbers are for a single > function call to the component. > > After modifying the calling pages so that they made in the > region of 100 calls to the component the numbers were around > 10-20ms for the locally invoked version compared to 1.9-2.0 > seconds for the version invoked as a webservice. > > It should be noted that the component in question is brutally > simple, so the actual numbers are not so important as the > difference between them for locally vs remotely invoked components. > > Spike > > > -----Original Message----- > > From: Spike [mailto:[EMAIL PROTECTED]] > > Sent: 05 September 2002 13:19 > > To: [EMAIL PROTECTED] > > Subject: RE: [ cf-dev ] .cfm enryption > > > > > > I'll try to put one together this evening and run a few tests > > to see how it goes. > > > > Spike > > > > > -----Original Message----- > > > From: Douglas Humphris [mailto:[EMAIL PROTECTED]] > > > Sent: 05 September 2002 13:15 > > > To: [EMAIL PROTECTED] > > > Subject: RE: [ cf-dev ] .cfm enryption > > > > > > > > > Yeah, run the component from a seperate server so that they can't > > > touch it. I'd be interested to know what effect this > would have on > > > performance because this is a genuine solution I was > thinking about > > > the other day...I guess the only way is to run a few tests. > > > > > > Would anyone like to set up a test CFCOMPONENT as a > webservice that > > > I could run from here, and then compare the time with > invoking it on > > > the same server? > > > > > > Cheers, > > > Douglas > > > > > > -- > > > Douglas Humphris, Programmer > > > http://www.unitech.net > > > > > > -----Original Message----- > > > From: Spike [mailto:[EMAIL PROTECTED]] > > > Sent: 05 September 2002 12:07 > > > To: [EMAIL PROTECTED] > > > Subject: RE: [ cf-dev ] .cfm enryption > > > > > > > > > That's an interesting suggestion... > > > > > > How would you stop the nasty evil code thief from rewriting the > > > component so that it skipped the DB check for the > registration key? > > > > > > Or were you suggesting that the component should reside on a > > > separate server not controlled by the client? > > > > > > If so, then you're probably going to run into some performance > > > issues. Having said that, I think it's exactly the way it > should be > > > done (performance aside), and is a major feature of webservices. > > > > > > Spike > > > > > > > -----Original Message----- > > > > From: Douglas Humphris [mailto:[EMAIL PROTECTED]] > > > > Sent: 05 September 2002 12:55 > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [ cf-dev ] .cfm enryption > > > > > > > > > > > > With CFMX, you could write key parts of your app as > > CFCOMPONENTS and > > > > deploy them as webservices. Program your app to depend > on running > > > > the components in order to work. For each component, have > > a required > > > > argument which takes a registration key. The first thing each > > > > component does is check your db that the registration key > > provided > > > > matches the registered IP/domain - if not email yourself, > > and return > > > > a warning message. > > > > > > > > Then to completely freak them out, phone them up as soon as the > > > > email comes in and tell them your solicitor will be in touch... > > > > > > > > Douglas > > > > > > > > -- > > > > Douglas Humphris, Programmer > > > > http://www.unitech.net > > > > > > > > > > > > -----Original Message----- > > > > From: Spike [mailto:[EMAIL PROTECTED]] > > > > Sent: 05 September 2002 11:39 > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [ cf-dev ] .cfm enryption > > > > > > > > > > > > It is perfectly possible to decrypt .cfm templates > encrypted with > > > > all versions of cfencode. This includes CF5 and CFMX. > > > > > > > > If you are using CFMX there are several things you could do to > > > > protect your IP. > > > > > > > > 1. Ensure that the client signs a contract that puts them > > in legal > > > > hot water if they as much as look at even the encrypted > > templates. > > > > (This is mostly a deterrent, but it does give you legal > > grounds to > > > > go after any > > > > abusers) > > > > > > > > 2. Put legal notices in the templates that make it clear that by > > > > reading the notices they have broken the terms of their > > contract and > > > > that they should immediately delete the decrypted template. Some > > > > other well worded stuff on the legal implications of > > decrypting the > > > > template wouldn't go amiss either. (Again, this provides > > a deterrent > > > > and some more legal back-up. They may not have read or be > > aware of > > > > the contract that was signed, so putting the information in each > > > > templates makes sure that they know they should not be > doing what > > > > they are doing.) > > > > > > > > 3. If you are using CFMX you can (in theory at least) deploy the > > > > class files for the application without the CFM templates > > > > themselves. That would be totally unsupported by MM, and would > > > > probably break as soon as a service pack or what-ever was > > applied to > > > > the server, but if you're really paranoid about your cfm > > templates > > > > being stolen it's worth investigating. > > > > > > > > 4. Create a COM Object, CFX tag, or similar external > > system on which > > > > your code heavily relies. Make sure that this will only > > work on one > > > > server. There are lots of ways you could go about this, > > but none of > > > > them are really simple and most are prone to the same sort of > > > > problems that you would get with deploying the app with > > class files > > > > only. > > > > > > > > 5. Write your code in such a way that no-one except you can > > > > understand it. This is actually a lot harder than it sounds if > > > > you've been programming for a long time, and it makes it > > a nightmare > > > > to debug and maintain. > > > > > > > > In general, unless you've come up with a killer app of some sort > > > > it's probably only worth going to the legal contract > and warning > > > > notices route, as the potential hassle involved with the other > > > > solutions isn't worth the gain. > > > > > > > > Spike > > > > > > > > > -----Original Message----- > > > > > From: Garry Mills [mailto:[EMAIL PROTECTED]] > > > > > Sent: 05 September 2002 11:31 > > > > > To: '[EMAIL PROTECTED]' > > > > > Subject: RE: [ cf-dev ] .cfm enryption > > > > > > > > > > > > > > > > btw I don't think cfdecrypt can decrypt cf5 files, although > > > > > looking at > > > > > > the shrewm notice board, there seem to be people > > > claiming they can > > > > > > (for a > > > > > fee). > > > > > > > > > > Interesting, anybody tried it with MX? > > > > > > > > > > Garry > > > > > > > > > > > -----Original Message----- > > > > > > From: Garry Mills [mailto:[EMAIL PROTECTED]] > > > > > > Sent: 05 September 2002 10:10 > > > > > > To: '[EMAIL PROTECTED]' > > > > > > Subject: [ cf-dev ] .cfm enryption > > > > > > > > > > > > > > > > > > We're rolling out a product to a customer soon, and > > > > bluntly speaking > > > > > > we don't want them to be able to copy the app onto > > > another server. > > > > > > > > > > > > Know about cfencrypt, and also know about cfdecrypt and > > > whilst it > > > > > > will stop the numpties getting into it doubt the tech > > > department > > > > > > will > > > > > find it as > > > > > > difficult > > > > > > > > > > > > A google search for coldfusion dongle returns a load of > > > > > links to crack > > > > > > files... > > > > > > > > > > > > What do the rest of you do, or is cfentrpt our only > > > > option? (oh, and > > > > > > I tried CF encrypted files on a Cobalt once and it > > > didn't seem to > > > > > > work, although thats a separate issue) > > > > > > > > > > > > Garry > > > > > > > > > > > > -- > > > > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > For human help, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > -- > > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > For human help, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > -- > > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > For human help, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > For human help, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > For human help, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] For human help, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] For human help, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] For human help, e-mail: > > [EMAIL PROTECTED] > > > > > > > > -- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] For human help, e-mail: > [EMAIL PROTECTED] > > > > -- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] For human help, e-mail: > [EMAIL PROTECTED] > > -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED]
