> 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.
Isn't this is exactly what RMI or Jini does? > 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. I think the main improvement here will be bandwidth. What "networking protocols" do you mean? IP6? Only thing, you think there might be a port 80 backlash?? A lot of security folks talk about this.. http://www.xml.com/pub/a/2002/02/27/security-lather.html http://www.counterpane.com/crypto-gram-0006.html#SOAP http://www.sdmagazine.com/documents/s=7556/sdm0209b/sdm0209b.htm > 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. In EJB 2.0 you can add a lightweight local interfaces so that EJB's can call each other locally, and implement CMR too. I wonder what CF does internally regarding this? Does it build local interfaces? I wonder... Has anyone done any comparisons of calling a cfc locally v calling a cfc as a web service? Justin > 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 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED]
