> -----Original Message-----
> From: Justin MacCarthy [mailto:[EMAIL PROTECTED]]
> Sent: 06 September 2002 15:55
> To: [EMAIL PROTECTED]
> Subject: [ cf-dev ] Performance of Remote objects - was RE: [
> cf-dev ] .cfm enryption
>
>
>
> > 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 believe so, but it would be nice if you could return them to a CF
server from a webservice.
>
> > 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??
>
I was thinking mostly of the port 80 thing and the use (generally
speaking) of high level protocols which don't compress the data
automatically before transmitting it across the internet. More bandwidth
is, of course, always good.
> 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?
>
As far as I know CF creates a Java class file which acts as a stub to do
the Axis webservice invocation. I suppose you could figure out how that
class file works internally by decompiling it, but they you'd probably
be in breach of your CF license agreement.
> 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]
>
>
>
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For human help, e-mail: [EMAIL PROTECTED]
