Scaleability vs OOD
Björn Ekberg
(Maybe there is a thread about this subject already. If so, please tell me
wich one.)
I've been taking interest in COM/DNA for som time now, but haven´t quite
understood all the features in MTS (component manager for W2000?).
As I see it, COM is a beautiful way of using object oriented concepts beyond
compilation time. Along woth automation, it also offers great features for
ASP programmers. Of course, it is better to move ASP script code to compiled
code in components, improving performance for the web application. Yet
better that MTS offers object (thread) pooling and JITA. Now, as I've
understood it, what JITA does is offer a wrapper interface instead of the
"real" interface. My application (ASP) does not actually get hold of the
object until it actually uses it, JITA then "attaches" a real object to the
wrapper. And this happens every time I'm using it, making it impossible to
store "state" information in the object. Example: I have an class "User"
that has the two properties "FName" and "LName". Printing (or setting) these
two properties in an ASP page would not make sense as I could not be sure
that it is the same object that I'm using in the two (property) calls.
Right?
This may improve scaleability a whole lot, but it also makes it virtually
impossible to keep an object oriented design for the application.
Components/Objects are now reduced to simply be containers of functions, to
be used totally independant from each other. Right?
Sure, you could find examples where you could store som kind of general
data, but in reality this totally detroys any OO attempts.
Does anyone have any opinion about how you still could keep som OO approach
for building scaleable DNA applications?
Would the following (C-like) approach be recomendable?
Let the JITA components be just containers of functions. These functions
will be get/set functions for "data" object such as "User", not JITA (but
maybe pooled?). I.e. you "get" a user object, use it, modify it, and then
"set" it.
Is there any point in doing it like this, or is it just a bad in-between
solution?
Eggie
COM
> objects, but instead write all your code straight in an ASP page. However
> don't listen to him...don't go over to the dark side :)
>
Yes,
Whynot write straight ASP pages that deal with the whole stuff? So don't use
DCOM or COM or whatever :) Some people will directly reply to me to say that
ASP is COM too but don't listen to them too...
Michael D. Kersey
> With pure ASP you have the following issues:
> 1) You dont have your buisnesslogic naturally encapsuled in nice packages.
"nice packages" is a relative term: most ISPs won't let you install your
"nice packages" on their systems, and with good reason.
And since COM components are stateless, they are little more than
collections of subroutines/functions. You can do the same thing with an
INCLUDE file, and it's quite apparent that INCLUDEs are much easier to
code and maintain. And all ISPs will let you put them on their system.
> 2) You do not have as strong a typechecker, this causes more errors in you
> code.
Never noticed a problem. ASP is quick to tell if there's a problem. FWIW
typeless languages are very useful (I wish VBScript were one of
them!-)).
> 3) no events.
Gee, just what we needed: a return to classic client/server
event-oriented programming where, on an object with N events, each
associated with a segment of event code, N x N possible sequences of two
events can occur(we aren't even counting the possibility of 3, 4, or
more events). Add global/shared variables to this witches' brew and we
have a situation that is *impossible* to debug, since now we don't have
the time/ability to actually test these possible interactions.
> 4) no JITA.
Yeah, sure, we really needed JITA. Reminds me of that old joke:
Q. What is a psychologist?
A. A person who puts mental hurdles before you and, as you jump over
them one by one, points out the progress that you've made!
Q. What is a Microsoft developer?
A. A person who puts the terms "JITA", "MTS", "MSMQ" and "components" in
front of you and, as you code past them one by one, points out the
progress that you've made.
> 5) not as flexible Transaction handling.
Current databases have all the transaction handling required. And they
do it exceedingly well.
> 6) no Asyncronos method calls (queued components).
"asynchronous"?
Queuing of procedure requests can turn what is a slow system into a
tolerable system and can increase reliability. For those who use COM
heavily, in some uncommon and specialized cases MSMQ's queuing may help
make up for the lost time spent loading/unloading components and
marshalling data between IIS and MTS on Windows.
But IMO it's better to write efficient ASP code instead.
> 7) your security isn't as tight (again encapsulation)
The same security is available with Windows Script Encoder.
> 8) documentation and structure quikly becomes a problem if your application
> is just a littel bigger than small.
Components won't overcome bad design. Spaghetti code can be written in
either VB or ASP. However the VB spaghetti code will be less reliable,
contain more lines of code, be more difficult to develop and maintain,
and be less portable from one Windows system to another.
> 9) limited UML modelling possibilities
Read up on both UML and Microsoft's DNA architecture(I recommend
starting with the former, so as to not waste time). Microsoft's entire
component methodology is at cross-purposes with UML, which was designed
for *object-oriented* systems development, not for component-oriented
development. Also, AFAIK there is no generally-accepted UML
model/pattern for the web, although there are proposed models/patterns
(all designed for non-Microsoft architectures, I might add).
> 10) no optional arguments to functions
This is very far down on developers' list of useful language features.
> COM+ is the way to go with your buisness logic when building well
> documented, robust and scaleable web applications.
> You have to know how to utilize the possibilities of COM+ though - a good
> and tested best-practise is a nice thing.
This is the Microsoft party line without any supporting argumentation.
If it's repeated often enough, will developers believe it?
> For minor RAD jobs and prototypes, pure ASP is fine - you need a good
> best-practise though ;-)
We should *always* have best practices.
Allan Ebdrup
news:eA9f47eVAHA.244@cppssbbsa03...
> > Michael D Keresy will now reply and say not to use MTS or DCOM or your
own
> COM
> > objects, but instead write all your code straight in an ASP page.
However
> > don't listen to him...don't go over to the dark side :)
>
use
> DCOM or COM or whatever :) Some people will directly reply to me to say
that
> ASP is COM too but don't listen to them too...
Hi.
Actually I won't say that ASP is COM too but this instead:
With pure ASP you have the following issues:
1) You dont have your buisnesslogic naturally encapsuled in nice packages.
2) You do not have as strong a typechecker, this causes more errors in you
code.
3) no events.
4) no JITA.
5) not as flexible Transaction handling.
6) no Asyncronos method calls (queued components).
7) your security isn't as tight (again encapsulation)
8) documentation and structure quikly becomes a problem if your application
is just a littel bigger than small.
9) limited UML modelling possibilities
10) no optional arguments to functions
11) and more.
COM+ is the way to go with your buisness logic when building well
documented, robust and scaleable web applications.
You have to know how to utilize the possibilities of COM+ though - a good
and tested best-practise is a nice thing.
For minor RAD jobs and prototypes, pure ASP is fine - you need a good
best-practise though ;-)
Kind Regards,
Allan Ebdrup
Adrian Forbes
> "nice packages" on their systems, and with good reason.
True, if you use an ISP and you don't have a dedicated server then COM is of
no use to you.
> And since COM components are stateless
No they're not.
> You can do the same thing with an INCLUDE file, and it's quite apparent
> that INCLUDEs are much easier to code and maintain.
You can't conditionally include a file and an include file can't be shared
with VB or VC++.
> Never noticed a problem. ASP is quick to tell if there's a problem. FWIW
> typeless languages are very useful
The typless nature of VBScript isn't an issue in itself, the problem lies in
the fact that you can't access non IDispatch interfaces.
> Gee, just what we needed: a return to classic client/server
True, I think I've only missed events once in ASP. If your code needs
events then you should think about how it is working.
> > 4) no JITA.
> Yeah, sure, we really needed JITA.
What's wrong with JITA? It makes your solution scalable. I can have
1,000,000 active users all with a valid reference to my COM object yet only
5 physical objects on the server. What is wrong with that?
> Current databases have all the transaction handling required. And they
> do it exceedingly well.
Well, SQL Server (and I assume Oracle) do. Access doesn't but you can't use
Access with MTS anyway. The advantage with MTS transactions is that you get
them code-free, and they can include not just database updates but LDAP,
ADSI, Exchange, text files, anything that you have a broker for. If you
want just database transactions then you could get away with using explicit
transactions.
> Queuing of procedure requests can turn what is a slow system into a
> tolerable system and can increase reliability.
And what happens when demand finally outstrips supply? Your users get
timeout errors, not nice. Using things like MSMQ really come into their own
when your request is very intensive like create a report or e-mailing lots
of people, or doing both. Using MSMQ also gives you fault tolerance.
> But IMO it's better to write efficient ASP code instead.
True, but some tasks are just too intensive due to the amount of data being
updated, the location of the servers, or the various systems that required
updating.
> The same security is available with Windows Script Encoder.
Method level security? Packet-level security? Role-based security?
> > 10) no optional arguments to functions
> This is very far down on developers' list of useful language features.
True, optional arguments will hardly sway an argument.
> This is the Microsoft party line without any supporting argumentation.
> If it's repeated often enough, will developers believe it?
I feel I've answered your arguments quite well. It depends what kind of
sites you are writing, but if you want case studies I'm sure I can think
some up.
Adrian Forbes
that regard there really is no comparison between COM and straight ASP
Michael D. Kersey
>
> > "nice packages" is a relative term: most ISPs won't let you install your
> > "nice packages" on their systems, and with good reason.
>
> True, if you use an ISP and you don't have a dedicated server then COM is of
> no use to you.
>
> > And since COM components are stateless
>
> No they're not.
No sooner did my head hit the pillow last night than I realized the
implicit assumption in my statement above that everyone who uses MTS and
COM for only web applications. I apologize for the error.
Of course, Adrian is right: COM components as customarily used by VB
programmers (and especially for client/server applications) *do*
maintain state and there are many VB applications that create stateful
instances of components and use them quite well every day. These can be
large systems with 100's of users.
However when using COM with MTS for web applications, Microsoft
discourages stateful behavior in COM components since such usage incurs
a heavy performance penalty under certain circumstances. And that was
what I should have said.
> > You can do the same thing with an INCLUDE file, and it's quite apparent
> > that INCLUDEs are much easier to code and maintain.
>
> You can't conditionally include a file and an include file can't be shared
> with VB or VC++.
No, but you can
a. use classes and dynamically create objects in ASP, or
b. Use WSC to create components written in the ASP languages. These
*can* be shared with VB and VC++ and have several other advantages.
> the problem lies in
> the fact that you can't access non IDispatch interfaces.
Again, never noticed a problem with this: despite the incremental
overhead of late binding, that overhead is so small compared with the
overhead associated with component creation/destruction and marshalling
of data that it is ridiculous. Using components in MTS renders the
overhead almost physically perceptible. Using MTS on a separate server I
find myself, like Lawrence Welk, saying "And a one, and a two, and a
three... ahhh! The component finally executed!"
This seems an appropriate time for one of my favorite quotes:
"Rule of thumb: unless there are at least 100 lines of script and some
big loops in that script, it's probably not worth thinking about
translating that page into a component."
Alex Homer, Dave Sussman, Brian Francis,
page 1042, "Active Server Pages 3.0" (Wrox Press Ltd., 1999)
The book goes on to describe in more detail the circumstances under
which one should use components.
Note the implication that any component-based architecture requires that
you do some very heavy compute-bound work. This is not a common
requirement.
> > Yeah, sure, we really needed JITA.
>
> What's wrong with JITA? It makes your solution scalable. I can have
> 1,000,000 active users all with a valid reference to my COM object yet only
> 5 physical objects on the server. What is wrong with that?
Do you mean to say that you have a million concurrent sessions (a
million ASP pages in execution, because it all starts with an ASP page)
executing at once? I don't think so! But maybe you mean:
a. a million users browsing, of which perhaps
b. 5000 are concurrently executing ASP pages, and in shared usage among
those are
c. 5 COM object instances?
Sounds like what mainframes and Unix systems refer to as "shared
libraries", a feature that's been around since the beginning of computer
time. Compare "Dynamic Link Libraries(DLL)".
Point is that JITA is just an acronym. Microsoft has this habit of
assigning new names to things that have been around forever and then
presenting them as something new. It's a marketing trick: but it works
on programmers too, since they're always eager to find the next great
tool to solve their problems. Unfortunately, as one of my cohorts once
said of another: "He's always searching for the latest and greatest tool
to solve his problems. That's why he never finishes his projects."
> The advantage with MTS transactions is that you get
> them code-free, and they can include not just database updates but LDAP,
> ADSI, Exchange, text files, anything that you have a broker for. If you
> want just database transactions then you could get away with using explicit
> transactions.
a. Most sites don't use these tools,
b. MTS isn't necessary to use LDAP, ADSI, Exchange, or text files,
c. AFAIK MTS does not support full transaction capability for LDAP,
ADSI, Exchange or even text files.
> > Queuing of procedure requests can turn what is a slow system into a
> > tolerable system and can increase reliability.
>
> And what happens when demand finally outstrips supply? Your users get
> timeout errors, not nice. Using things like MSMQ really come into their own
> when your request is very intensive like create a report or e-mailing lots
> of people, or doing both. Using MSMQ also gives you fault tolerance.
This is called "batch processing": mainframes and Unix boxes have been
doing it for years. There are subsystems available for even Windows.
Message queuing (store-and-forward) is a mechanism that can be easily
implemented with a database: you put the message into a database and
process it later. Such a mechanism is "fault tolerant". You don't need a
new acronym or a new piece of software to do what MSMQ does. And you can
do it on *any* system.
> > But IMO it's better to write efficient ASP code instead.
>
> True, but some tasks are just too intensive due to the amount of data being
> updated, the location of the servers, or the various systems that required
> updating.
>
> > The same security is available with Windows Script Encoder.
> Method level security? Packet-level security? Role-based security?
Generally:
These are red herrings. Other than the simple fact that *any*
processing, including "security" processing, creates additional
overhead, what they have to do with this thread is questionable.
Specifically:
1. The first must be written by the application developer, so whether
done using components or functions/subroutines makes little difference.
2. The second is a communications-level matter,
3. Role-based security models have been around for years: you can
implement your own or some database vendors provide it as part of their
database.
> > > 10) no optional arguments to functions
> > This is very far down on developers' list of useful language features.
>
> True, optional arguments will hardly sway an argument.
:)
> > This is the Microsoft party line without any supporting argumentation.
> > If it's repeated often enough, will developers believe it?
>
> I feel I've answered your arguments quite well. It depends what kind of
> sites you are writing, but if you want case studies I'm sure I can think
> some up.
Be certain, noble reader, that every day across millions of locations
the internet runs without Microsoft, without MTS, without ADSI, without
Exchange, without Outlook, without COM, without COM+, without iDispatch,
without JITA, without MSMQ and that their disappearance from the face of
the earth would have no effect whatsoever on that network other than to
increase the information content of the medium.
Michael D. Kersey
>
> I'd also like to add that the subject is scalability, not performance. In
> that regard there really is no comparison between COM and straight ASP
Any definitions of terms or supporting arguments would be appreciated.
Do you include cost?
Allan Ebdrup
news:3A25E042...@hal-pc.org...
> Allan Ebdrup wrote:
> > With pure ASP you have the following issues:
> > 1) You dont have your buisnesslogic naturally encapsuled in nice
packages.
> "nice packages" on their systems, and with good reason.
>
> INCLUDE file, and it's quite apparent that INCLUDEs are much easier to
If you are not your own ISP, or don't have the possibility of registrering
components on your server then we are definately talking a small website
compared to the ones that I am talking about. Perhaps that is the whole key
to our different oppinions ?
I agree that the programming possibilities in ASP includes are in most
instances the same as coding COM+ components. There are a few things that
you need components for in ASP though (emails, HTTP gets, News get and post,
and they are also good for uploads even though you can do it with pure ASP).
> > 2) You do not have as strong a typechecker, this causes more errors in
you
> > code.
> Never noticed a problem. ASP is quick to tell if there's a problem. FWIW
> typeless languages are very useful (I wish VBScript were one of
> them!-)).
Well, when you have a large system, with many developers (let's say 10-20)
there are lots of problems arising from the typelessness of VBScript.
Unexpected side effects are a very common thing in pure VBScript code.
> > 3) no events.
> Gee, just what we needed: a return to classic client/server
> event-oriented programming where, on an object with N events, each
> associated with a segment of event code, N x N possible sequences of two
> events can occur(we aren't even counting the possibility of 3, 4, or
> more events). Add global/shared variables to this witches' brew and we
> have a situation that is *impossible* to debug, since now we don't have
> the time/ability to actually test these possible interactions.
No, but events can be usefull on a few occasions, I'm simply pointing out
that they are not an option when coding pure ASP. (are you allways this
hostile to the people who wave a different view than you ?)
> > 4) no JITA.
> Yeah, sure, we really needed JITA. Reminds me of that old joke:
[cut "jokes"]
Well if you want to build a scaleable website it helps to use JITA
components. JITA components improve scalebility.
> > 5) not as flexible Transaction handling.
> Current databases have all the transaction handling required. And they
> do it exceedingly well.
The fact that you can remove transaction considerations from your ASP code
is in my experience a great plus, that whay you can have different people
working on the buisness-logic and the web-presentation part of the
application. I don't know if this is true or not, but it seems that you do
all the coding yourself and have a total control of the entire application,
in that case it doesn't make any difference if you have your transaction
considerations coded directly into your ASP. But, and there definattely is a
but, when building larger websites (ie. a portal) the size of the
development project requires a bit more robust method. Splitting the work
and encapsulation is a very good tool, you do your transaction
considerations once and pack them up in your components.
> > 6) no Asyncronos method calls (queued components).
> "asynchronous"?
As you might have guessed english is not my native language, thank you for
pointing that out, I find it most relevant.
> Queuing of procedure requests can turn what is a slow system into a
> tolerable system and can increase reliability. For those who use COM
> heavily, in some uncommon and specialized cases MSMQ's queuing may help
> make up for the lost time spent loading/unloading components and
> marshalling data between IIS and MTS on Windows.
>
> But IMO it's better to write efficient ASP code instead.
Things like advanced statistics and error logs on other servers spring to
mind, no need to hold on to the HTTP request untill they have been handled.
Even if everything else is in pure ASP. Again these things are nice to have
encapsuled.
> > 7) your security isn't as tight (again encapsulation)
> The same security is available with Windows Script Encoder.
Can you make sure that all ASP developers and designers don't have the
login-access to your highly sensitive database ?
And how hard is the Windows Script Encoder to hack ? (really I don't know)
Is it 128 bit encryption ?
> > 8) documentation and structure quikly becomes a problem if your
application
> > is just a littel bigger than small
>
> Components won't overcome bad design. Spaghetti code can be written in
> either VB or ASP.
True
> However the VB spaghetti code will be less reliable,
> contain more lines of code, be more difficult to develop and maintain,
> and be less portable from one Windows system to another.
You are right that people who write spaghetti code often have more success
coding pure ASP applications. But I see no point in discussing what method
handles spaghetti code best, we're talking about a well designed system
here.
I'm talking about the following situation:
- A large website, with lot's of applications that iterate through roughly
1-2 month development cycles (and not in the same frequency :-)
- millions of visitors
- 10-20 developers
- best practices and good coding conventions have been established and
educated to the developers
- they produce well structured code, or the spaghetti gets caught by
reviewing the code before staging.
- some parts of the database are so sensitive that only a few developers
should have access to it.
In this scenario and in my experience, pure ASP applications give a lot more
pitfalls for bad design and spaghetti-code, the lack of encapsulation, the
typlessness, the magnitude of include files that are included across
applications (common functions), the weak security, they all contribute to
making a big mess of things. Not to mention that scaleability is a problem.
Plus the developers who work on the sensitive application all have access to
the sensitive database.
In smaller scenarioes I will grant you that pure ASP (VBScript) applications
are just fine (heck I develop and sell some myself)
Choose the right tool for the job one might say :-)
> > 9) limited UML modelling possibilities
> Read up on both UML and Microsoft's DNA architecture(I recommend
> starting with the former, so as to not waste time). Microsoft's entire
> component methodology is at cross-purposes with UML, which was designed
> for *object-oriented* systems development, not for component-oriented
> development. Also, AFAIK there is no generally-accepted UML
> model/pattern for the web, although there are proposed models/patterns
> (all designed for non-Microsoft architectures, I might add).
Hmm, again the hostility, when someone has a different view than you they
mus need to "Read up on both UML and Microsoft's DNA architecture", forgive
me for asking, but quite frankly, don't you think that's rather arrogant ?
Are you the only human beeing that has never misunderstood or been wrong
about somthing (and this has nothing to do with the discussion we are
currently in the middle of) ?
For example Rational Rose 2000e is good for modelling components for Windows
DNA, it has forward and reverse engeneering for components, this is what
speeds up the documentation and development of the buisness logic.
There is no way to forward or reverse engeneer a method/function/sub in ASP,
this is my point.
As for how generally-accepted and usefull their entire model for Windows DNA
applications is in general, I'm sure it will change a lot before it's
finished.
> > COM+ is the way to go with your buisness logic when building well
> > documented, robust and scaleable web applications.
> > You have to know how to utilize the possibilities of COM+ though - a
good
> > and tested best-practise is a nice thing.
>
> This is the Microsoft party line without any supporting argumentation.
> If it's repeated often enough, will developers believe it?
- I've pointed out the weaknesses of pure ASP compared to applications that
utilize COM+, and there are some technical possibilities with COM+ that you
don't have with pure ASP - this noone can deny.
- I've clarified (as best I can) what, in my experince, are the weaknesses
of pure ASP applications, and this is associated with large development
jobs.
- I have stated that pure ASP is the way to go for smaller applications and
prototypes.
Personally I think I have a pretty good case, based on undisputable fact and
my experince.
I fail to see why this might not equally well be Michael D. Kersey's
partyline without any supporting argumentation.
If it's repeated often enough, will developers believe it? (sorry, couldn't
help it - you seem like you need a bit of your own medicine :-)
I hope we can have a more constructive discussion, I would really like to
know what makes you so convinced that COM+ is "the work of the devil" :-)
Kind Regards,
Allan Ebdrup
Björn Ekberg
connot help beeing surprised how eager some are to critisize just about
everything Microsoft does. Arguments like " X has been around on mainframes
or UNIX systems for years" is is just pointless. One could say that all you
really need is a few mnemonics, and you could do just about anything, even
25 years ago.
"Shared librarys" could maybe be compared to DLL:s. There is however a big
difference between DLL:s and COM components.
If you preffer hacking perl, python, RPG, PHP or whatever and enjoy
inventing the wheel for the millionth time, please feel free to do so, but
learn about COM before you enter the discsson.
The thing is that Microsoft offers high end functionality, wrapped in
easy-to-use products.I find COM and everything sprung out of it to be one of
the greatest software accievments the latest 10 years. No other platform
offers a component model and the tools that come with it that can compare to
COM/Devstudio.
/Björn
"Michael D. Kersey" <mdke...@hal-pc.org> wrote in message
news:3A26B69F...@hal-pc.org...
Adrian Forbes
You can't do it for free. If your app needs to be scalable then you'll have
the budget
Adrian Forbes
> a. use classes and dynamically create objects in ASP, or
> b. Use WSC to create components written in the ASP languages. These
> *can* be shared with VB and VC++ and have several other advantages.
Define b. I know you can create COM objects from VBS, but if that is what
you are suggesting then you're changing your argument.
> Again, never noticed a problem with this:
It can be a problem if you're using interfaces to version your code. Things
like ADO etc never use custom interfaces. Custom Interfaces are a great
tool, but you can't use them if you're using script languages like VBS. The
reason you've never seen a problem is because you are being locked out of
using the feature all together. A bad thing.
Also I see you are very keen to gloss over the performance hit you get from
using IDispatch over early binding. Selective perception? Look at this
code;
while not objRS.EOF
for each objField in objRS.Fields
response.write objField.Name & " = " & objField.Value
next
objRS.MoveNext
wend
Now you count up all those calls, ouch! If that code was in a COM object it
would have much less work to do.
> Using components in MTS renders the
> overhead almost physically perceptible. Using MTS on a separate server I
> find myself, like Lawrence Welk, saying "And a one, and a two, and a
> three... ahhh! The component finally executed!"
Again I see you steer the arguments constantly onto performance again
despite the fact that this is not an issue. We are talking about
scalability. Do you actually understand what that is and why it is good?
MTS on the same server has no additional overhead above any other out of
process call on the same machine. You are arguing for milliseconds (even
less) of performance over scalability. Madness.
> Do you mean to say that you have a million concurrent sessions (a
> million ASP pages in execution, because it all starts with an ASP page)
> executing at once? I don't think so! But maybe you mean:
> a. a million users browsing, of which perhaps
> b. 5000 are concurrently executing ASP pages, and in shared usage among
> those are
> c. 5 COM object instances?
Still pretty good. Add to that your non-web users as well.
> Sounds like what mainframes and Unix systems refer to as "shared
> libraries", a feature that's been around since the beginning of computer
> time. Compare "Dynamic Link Libraries(DLL)".
Yes but the difference is (again) JITA is scalable. If your object is under
the control of JITA and you do
set obj = CreateObject("MyObject")
1,000,000 times, how many objects do I have? None. If your DLL is NOT
using JITA then how many do you have? 1,000,000 - you call that scalable
and well performing? I don't. Also MTS caches the type library info so
that re-creating the objects is FASTER than it is with pure COM.
> > The advantage with MTS transactions is that you get
> > them code-free, and they can include not just database updates but LDAP,
> > ADSI, Exchange, text files, anything that you have a broker for. If you
> > want just database transactions then you could get away with using
explicit
> > transactions.
> a. Most sites don't use these tools,
I know, if you do use them then MTS allows you to transact them. Something
you couldn't otherwise do.
> b. MTS isn't necessary to use LDAP, ADSI, Exchange, or text files,
Since when did I say it was? You're really clutching at straws. I said you
can enlist them in transactions.
> c. AFAIK MTS does not support full transaction capability for LDAP,
> ADSI, Exchange or even text files.
MTS allows you to include any resource that has a manager for it. The
things I listed do have them (not sure about Exchange but only cos I don't
use it, if one isn't available now then it soon will be). You can even
write your own with VB if you want.
> This is called "batch processing": mainframes and Unix boxes have been
> doing it for years.
But using a different architecture.
> There are subsystems available for even Windows.
> Message queuing (store-and-forward) is a mechanism that can be easily
> implemented with a database:
I know, again you are clutching at straws. You say MSMQ is useless, I
describe the benefits, you then admit those benefits but say "oh that's been
around for years". Come on, stop arguing just for the sake of it.
> You don't need a
> new acronym or a new piece of software to do what MSMQ does. And you can
> do it on *any* system.
Yes, but MSMQ gives you it FOR FREE. Also I'd like to see you code the kind
of routing and fault tolerance built into MSMQ, as well as it's
transactional support. Why code all this yourself when MS are handing it to
you on a plate? You must like making things hard for yourself.
> what they have to do with this thread is questionable.
What they have to do with this thread? The way you advocate fractions of
milliseconds of performance over scalability means you don't even know what
this thread is about. I've said it before and I'll say it again,
performance is not everything.
> 3. Role-based security models have been around for years: you can
> implement your own or some database vendors provide it as part of their
> database.
Yes, but what does MTS give it to you for? For free. So why write your
own?
> Be certain, noble reader, that every day across millions of locations
> the internet runs without Microsoft, without MTS, without ADSI, without
> Exchange, without Outlook, without COM, without COM+, without iDispatch,
> without JITA, without MSMQ and that their disappearance from the face of
> the earth would have no effect whatsoever on that network other than to
> increase the information content of the medium.
And I run those sites and they run very well. However I also run sites
where, quite frankly, the user can wait that extra 1 second, I don't
care....but those sites have to be available 24/7 and they have to scale cos
they get hammered. Your above statement is entirely shallow and redundant.
Maybe YOU don't do sites that needs those things but others do. And if your
site needs to scale then you should look into them.
Adrian Forbes
> everything Microsoft does. Arguments like " X has been around on
mainframes
> or UNIX systems for years" is is just pointless. One could say that all
you
> really need is a few mnemonics, and you could do just about anything, even
> 25 years ago.
> "Shared librarys" could maybe be compared to DLL:s. There is however a big
> difference between DLL:s and COM components.
> If you preffer hacking perl, python, RPG, PHP or whatever and enjoy
> inventing the wheel for the millionth time, please feel free to do so, but
> learn about COM before you enter the discsson.
> The thing is that Microsoft offers high end functionality, wrapped in
> easy-to-use products.I find COM and everything sprung out of it to be one
of
> the greatest software accievments the latest 10 years. No other platform
> offers a component model and the tools that come with it that can compare
to
> COM/Devstudio.
Good points. It also surprises me how eager he is to criticise technologies
he doesn't understand. I don't mean any offense by that Michael, and I
don't want to start a slagging match. But to anyone who knows these
technologies it is clear you know "of them" but not enough to know their
benefits or how to use them.
Michael D. Kersey
You omitted the first part of my post: what's your definition of
scalability? Please provide a definition in measurable terms.
Adrian Forbes
performance. FWIW scalability is the ability to add more users to a system
without adversely affecting the performance.
Michael D. Kersey <mdke...@hal-pc.org> wrote in message
news:3A27E310...@hal-pc.org...
Michael D. Kersey
>
> Although I appriciate that people are taking interest in the discussion, I
> connot help beeing surprised how eager some are to critisize just about
> everything Microsoft does. Arguments like " X has been around on mainframes
> or UNIX systems for years" is is just pointless.
No, it's simply pointing out that things are sometimes easier if you
don't ascribe magical properties to acronyms, especially Microsoft's
acronyms. In general, you have two choices as a programmer:
1. Learn the discipline of programming with various languages, various
algorithms, and tools,
2. Trust that the next toolkit from the acronym-vendor will solve your
problem.
Choose 1 and your skills will increase throughout your career. Choose 2
and your skills will be rendered defunct in every marketing cycle, when
each the new set of acronyms is released. A good example is how
Microsoft is discarding VBScript and Visual Basic in ASP+.
> One could say that all you
> really need is a few mnemonics, and you could do just about anything, even
> 25 years ago.
That's precisely the idea that acronym marketing encourages: "If we only
had Microsoft's XYZ we could solve this problem... If we only ran our
components in ABC we could solve that problem..."
whereas the true solution lies in thinking about the problem and solving
it with programming tools and techniques that have been around for
years.
> "Shared librarys" could maybe be compared to DLL:s. There is however a big
> difference between DLL:s and COM components.
I'm well aware of that. You apparently missed my point entirely: "shared
librarys" have been used by high throughput transaction processing
systems for computer eons. They work extremely well and are time-tested
technology. They're in use today and will be in use in 20 years. DLLs
were a technology for use in Windows for sharing code. They were not
well-designed for the platform: they are legacy technology. COM was a
hack from the beginning: it is now so difficult to market and support
that Microsoft is discarding it. It is already a legacy technology.
> If you preffer hacking perl, python, RPG, PHP or whatever and
I *am* partial to Perl!-)
> enjoy inventing the wheel for the millionth time,
This would be a useful analogy if it were indeed "analogous".
Unfortunately Microsoft has time and time again designed "wheels" that
are square, octagonal, triangular, but for some reason, never round.
This uncanny capability to "snatch defeat from the jaws of victory"
eventually takes a toll on the customer population. Consumers may have a
herd mentality, but they are not idiots.
> please feel free to do so, but
> learn about COM before you enter the discsson.
Argumentum ad hominem.
And I am unfortunately *intimately* familiar (read "been screwed by")
with COM, in it's various incarnations.
> The thing is that Microsoft offers high end functionality, wrapped in
> easy-to-use products.
This is simple marketing speak.
> I find COM and everything sprung out of it to be one of
> the greatest software accievments the latest 10 years.
I guess that's why Microsoft is abandoning COM.
BTW where's your spelling checker component?-))
Michael D. Kersey
> Define b. I know you can create COM objects from VBS, but if that is what
> you are suggesting then you're changing your argument.
more of a "scripting" solution, so I tend to prefer it.
> > Again, never noticed a problem with this:
>
> It can be a problem if you're using interfaces to version your code. Things
> like ADO etc never use custom interfaces. Custom Interfaces are a great
> tool, but you can't use them if you're using script languages like VBS. The
> reason you've never seen a problem is because you are being locked out of
> using the feature all together. A bad thing.
Again, never noticed a problem with this!-))
> Also I see you are very keen to gloss over the performance hit you get from
> using IDispatch over early binding. Selective perception?
I didn't gloss over it, in fact I believe was the first to make
reference to it.
The total time involved in such operations is usually much less than the
time it takes to *load* a component. When you add up
a. creation of component,
b. destruction/freeing of component,
c. marshalling of data to/from component
the overhead of using components is far, far greater than the time lost
in late binding. Oops! Time again for my favorite quote:
> "Rule of thumb: unless there are at least 100 lines of script and some
> big loops in that script, it's probably not worth thinking about
> translating that page into a component."
> Alex Homer, Dave Sussman, Brian Francis
> page 1042,
> "Active Server Pages 3.0"
> (Wrox Press Ltd., 1999)
> Look at this code;
> while not objRS.EOF
> for each objField in objRS.Fields
> response.write objField.Name & " = " & objField.Value
> next
> objRS.MoveNext
> wend
> Now you count up all those calls, ouch! If that code was in a COM object it
> would have much less work to do.
Your argument is similar to a Greek paradox, which, in one form, claims
that it is impossible to cross a room. The reasoning is as follows:
Before you can cover the whole distance, you must first cover the first
half (1/2) of it. Then you must cover the first half of the remaining
distance (1/2 plus 1/4, i.e. 3/4) and so on. In other words, you must
first walk one-half, then an additional one-fourth, then an additional
one-eighth, etc, always remaining short of your goal. Hence you can
never reach it!
So don't count, benchmark instead! That will show the relative
significance of late-binding vs component
creation/destruction/marshalling of data.
> > Using components in MTS renders the
> > overhead almost physically perceptible. Using MTS on a separate server I
> > find myself, like Lawrence Welk, saying "And a one, and a two, and a
> > three... ahhh! The component finally executed!"
>
> Again I see you steer the arguments constantly onto performance again
> despite the fact that this is not an issue. We are talking about
> scalability. Do you actually understand what that is and why it is good?
In the interest of discourse, I have asked you and others to provide an
operational definition, but you have provided none.
Note that, contrary to your statements, any measure of scalability
*must* include performance as a parameter. The reason is that unless you
specify an acceptable level of performance, then even a system that has
*no* performance whatsoever is infinitely scalable. It's such an obvious
fact that I'm almost embarrassed to point it out. So scalability *might*
be defined as
scalability = "cost per additional user at a given level of
performance." or
"cost per additional server at a glven level of performance." or some
such.
I await your (measurable) operational definition of scalability.
> MTS on the same server has no additional overhead above any other out of
> process call on the same machine.
But if it's unnecessary, why use it? Code should run in-process as much
as possible, which unquestionably creates the least overhead and is most
reliable.
> You are arguing for milliseconds (even
> less) of performance over scalability. Madness.
No, rationality!
And you have not yet presented a definition of scalability. Confusion.
> > Sounds like what mainframes and Unix systems refer to as "shared
> > libraries", a feature that's been around since the beginning of computer
> > time.
>
> Yes but the difference is (again) JITA is scalable.
With shared libraries there is usually only 1 copy. Such an architecture
is eminently scalable. JITA is a late (20-years late) attempt to catch
up.
> > > The advantage with MTS transactions is that you get
> > > them code-free, and they can include not just database updates but LDAP,
> > > ADSI, Exchange, text files, anything that you have a broker for.
"Ah! But therein lies the rub!" In true Microsoft fashion, *you* get to
write the broker!-))
The broker does the real transaction processing, all MTS does is
*supervise* the process. So you're actually inserting an unnecessary
layer (MTS) into an already well-defined process. In the spirit of
rationality, remove the unnecessary layer, which is MTS. Any unnecessary
code decreases the reliability and availability of a system. Do the
math.
> if you do use them then MTS allows you to transact them. Something
> you couldn't otherwise do.
If they(brokers) have transactional capability, then MTS is unnecessary.
> > This is called "batch processing": mainframes and Unix boxes have been
> > doing it for years.
>
> But using a different architecture.
This is a bad thing?
> You say MSMQ is useless,
No, not my words. But I did say it was unnecessary.
> > You don't need a
> > new acronym or a new piece of software to do what MSMQ does. And you can
> > do it on *any* system.
>
> Yes, but MSMQ gives you it FOR FREE. Also I'd like to see you code the kind
> of routing and fault tolerance built into MSMQ, as well as it's
> transactional support. Why code all this yourself when MS are handing it to
> you on a plate? You must like making things hard for yourself.
These features either
a. can be easily coded, or
b. are available already.
MTS is designed primarily to inextricably tie an application to the
vendor's platform.
> What they have to do with this thread? The way you advocate fractions of
> milliseconds of performance over scalability means you don't even know what
> this thread is about.
And I'll say it again: Any measure of "scalability" that does not
include performance is useless.
> performance is not everything.
Here you attempt to turn faults into virtues: below you admit that
you've written poorly-performing systems using MTS and MSMQ. It's as if
one were awarding oneself a medal for climbing a tree backwards with one
arm; most would view the effort as both unnecessary and foolish.
> > 3. Role-based security models have been around for years: you can
> > implement your own or some database vendors provide it as part of their
> > database.
>
> Yes, but what does MTS give it to you for? For free. So why write your
> own?
More to the point, why use something (MTS) that is unnecessary?
Apply Occam's razor: "Entities should not be multiplied unnecessarily."
The statement applies to complex systems (components, subsystems) today
as well as it did in the 14th century:
http://math.ucr.edu/home/baez/physics/occam.html
> > Be certain, noble reader, that every day across millions of locations
> > the internet runs without Microsoft, without MTS, without ADSI, without
> > Exchange, without Outlook, without COM, without COM+, without iDispatch,
> > without JITA, without MSMQ and that their disappearance from the face of
> > the earth would have no effect whatsoever on that network other than to
> > increase the information content of the medium.
>
> And I run those sites and they run very well.
Thank you for confirming my views.
> However I also run sites
> where, quite frankly, the user can wait that extra 1 second, I don't
> care....but those sites have to be available 24/7 and they have to scale cos
> they get hammered.
Thank you for confirming my views.
And, I almost forgot, here's an electronic Cracker Jack prize for
writing systems that suck and bragging on it.
> Maybe YOU don't do sites that needs those things but others do. And if your
> site needs to scale then you should look into them.
Yes: please do look into Unix, Apache, mod_Perl, et al.
Michael D. Kersey
>
> What's the point? Everything you say has no relevance to scalability, only
> performance. FWIW scalability is the ability to add more users to a system
> without adversely affecting the performance.
Good start! Now with this first attempt to define scalability, you can
see that performance is part of the definition - a necessary part, I
might add.
But it's not quite complete, because we need an *operational*
definition: a definition that makes scalability *measurable*. Possibly
you can arrive at one by factoring in certain candidate parameters. Such
parameters might include cost, number(of systems or users) and their
differentials (additional cost, additional number of users, etc.).
Given such a definition, it is then possible to analyze a system and
make estimates of the newly-defined term "scalability" for that system.
BTW this is something usually done *before* writing a system!-))
Björn Ekberg
still make use of JITA, COM+ etc. Unless you don't have any constructive
angles to it, please post your pseudo intellectual thoughts somewhere else.
BTW, spellcheck this: Sug min kuk! -))
"Michael D. Kersey" <mdke...@hal-pc.org> wrote in message
news:3A27EBF9...@hal-pc.org...
> "Björn Ekberg" wrote:
> >
> > Although I appriciate that people are taking interest in the discussion,
I
> > connot help beeing surprised how eager some are to critisize just about
> > everything Microsoft does. Arguments like " X has been around on
mainframes
> > or UNIX systems for years" is is just pointless.
>
> No, it's simply pointing out that things are sometimes easier if you
> don't ascribe magical properties to acronyms, especially Microsoft's
> acronyms. In general, you have two choices as a programmer:
> 1. Learn the discipline of programming with various languages, various
> algorithms, and tools,
> 2. Trust that the next toolkit from the acronym-vendor will solve your
> problem.
>
> Choose 1 and your skills will increase throughout your career. Choose 2
> and your skills will be rendered defunct in every marketing cycle, when
> each the new set of acronyms is released. A good example is how
> Microsoft is discarding VBScript and Visual Basic in ASP+.
>
> > One could say that all you
> > really need is a few mnemonics, and you could do just about anything,
even
> > 25 years ago.
>
> That's precisely the idea that acronym marketing encourages: "If we only
> had Microsoft's XYZ we could solve this problem... If we only ran our
> components in ABC we could solve that problem..."
> whereas the true solution lies in thinking about the problem and solving
> it with programming tools and techniques that have been around for
> years.
>
> > "Shared librarys" could maybe be compared to DLL:s. There is however a
big
> > difference between DLL:s and COM components.
>
> I'm well aware of that. You apparently missed my point entirely: "shared
> librarys" have been used by high throughput transaction processing
> systems for computer eons. They work extremely well and are time-tested
> technology. They're in use today and will be in use in 20 years. DLLs
> were a technology for use in Windows for sharing code. They were not
> well-designed for the platform: they are legacy technology. COM was a
> hack from the beginning: it is now so difficult to market and support
> that Microsoft is discarding it. It is already a legacy technology.
>
> > If you preffer hacking perl, python, RPG, PHP or whatever and
> I *am* partial to Perl!-)
>
> > enjoy inventing the wheel for the millionth time,
> This would be a useful analogy if it were indeed "analogous".
> Unfortunately Microsoft has time and time again designed "wheels" that
> are square, octagonal, triangular, but for some reason, never round.
> This uncanny capability to "snatch defeat from the jaws of victory"
> eventually takes a toll on the customer population. Consumers may have a
> herd mentality, but they are not idiots.
>
> > please feel free to do so, but
> > learn about COM before you enter the discsson.
>
> Argumentum ad hominem.
> And I am unfortunately *intimately* familiar (read "been screwed by")
> with COM, in it's various incarnations.
>
> > The thing is that Microsoft offers high end functionality, wrapped in
> > easy-to-use products.
>
> This is simple marketing speak.
>
> > I find COM and everything sprung out of it to be one of
> > the greatest software accievments the latest 10 years.
>
Michael D. Kersey
>
> This discussion is about how to obtain an OO design in a DNA project and
> still make use of JITA, COM+ etc. Unless you don't have any constructive
> angles to it, please post your pseudo intellectual thoughts somewhere else.
This post is a simple argumentum ad hominem: see
http://www.intrepidsoftware.com/fallacy/attack.htm for some interesting
information on this common form of fallacious argument.
Note that in all software development:
a. You should not use technologies whose implications you do not
understand,
b. A firm understanding of basic principles that you *do* understand
will serve you much better than a list of acronyms that you do not.
> BTW, spellcheck this: Sug min kuk! -))
No, thank you. For starters, Norton rejected it because it has several
viruses on it!-))
English readers can look up this common Swedish phrase at
http://www.geocities.com/Athens/Forum/3580/swed.htm
The meaning comes right through, however, thanks to the common roots of
our Anglo-Saxon heritage.
Luckily Bjorn Ekberg' post here does not represent Swedish developers or
Swedes in general: my experience has been that the Swedish are among the
most gracious, reserved and intelligent of people.
Michael D. Kersey
> If you are not your own ISP, or don't have the possibility of registrering
> components on your server then we are definately talking a small website
> compared to the ones that I am talking about. Perhaps that is the whole key
> to our different oppinions ?
This is a problem that has been mentioned many times on these
newsgroups. There is no need to make assumptions about me.
> I agree that the programming possibilities in ASP includes are in most
> instances the same as coding COM+ components. There are a few things that
> you need components for in ASP though (emails, HTTP gets, News get and post,
> and they are also good for uploads even though you can do it with pure ASP).
Certainly. I've always supported use of components when necessary to add
functionality to ASP. Although you can do all that and more with
PerlScript, which is certainly easier and cheaper than purchasing and
installing components.
> Well, when you have a large system, with many developers (let's say 10-20)
> there are lots of problems arising from the typelessness of VBScript.
The largest and most complex systems extant today are still running on
(largely IBM) mainframes. The coding practices and techniques used on
those platforms are essentially
1. a language,
2. an INCLUDE facility,
3. a database,
4. a transaction processing (OLTP) system.
Software for such systems have been successfully built with teams of
*hundreds* of developers working in concert.
So how could teams of such size successfully complete projects? What is
the difference between that and web development?
IMO this dichotomy arises mostly from a lack of development
infrastructure and discipline today. Over the last 20 or so years the
rise of client/server development relegated mainframe development to the
back burner. Those technologies were not helped by the fact that they
were *so* reliable and transparent to users that they rarely needed
fixing. Retirement of knowledgeable personnel who developed such massive
systems has reduced the knowledge pool further.
IOW we've, as a developmental community, "forgotten" how to do complex
systems development. And now we rely on developers raised using PCs to
write software for the entire world community.
> Unexpected side effects are a very common thing in pure VBScript code.
Certainly no more than in VB!
> > Gee, just what we needed: a return to classic client/server
> > event-oriented programming where, on an object with N events, each
> > associated with a segment of event code, N x N possible sequences of two
> > events can occur(we aren't even counting the possibility of 3, 4, or
> > more events). Add global/shared variables to this witches' brew and we
> > have a situation that is *impossible* to debug, since now we don't have
> > the time/ability to actually test these possible interactions.
>
> No, but events can be usefull on a few occasions, I'm simply pointing out
> that they are not an option when coding pure ASP. (are you allways this
> hostile to the people who wave a different view than you ?)
You apparently missed the point of the paragraph: it gives a strong
mathematical explanation of why it is difficult to write high-quality
software in an event-oriented framework. In it are the seeds of the
ideas for how one could possibly write *good* event-oriented software
(e.g., partitioning, elimination of global objects, etc.).
Again, there is no need to make assumptions about me.
> Well if you want to build a scaleable website it helps to use JITA
> components. JITA components improve scalebility.
These are just blanket statements with no supporting arguments(IOW just
parroting of the M$ party line).
> The fact that you can remove transaction considerations from your ASP code
> is in my experience a great plus, that whay you can have different people
> working on the buisness-logic and the web-presentation part of the
> application. I don't know if this is true or not, but it seems that you do
> all the coding yourself and have a total control of the entire application,
> in that case it doesn't make any difference if you have your transaction
> considerations coded directly into your ASP. But, and there definattely is a
> but, when building larger websites (ie. a portal) the size of the
> development project requires a bit more robust method. Splitting the work
> and encapsulation is a very good tool, you do your transaction
> considerations once and pack them up in your components.
> Things like advanced statistics and error logs on other servers spring to
> mind, no need to hold on to the HTTP request untill they have been handled.
> Even if everything else is in pure ASP. Again these things are nice to have
> encapsuled.
A well-organized set of subroutines/functions and INCLUDE files would do
the same thing. You can encapsulate functionality with those as well as
components, especially given the environment: stateless components,
which are in fact only collections of functions.
> > > 7) your security isn't as tight (again encapsulation)
> > The same security is available with Windows Script Encoder.
>
> Can you make sure that all ASP developers and designers don't have the
> login-access to your highly sensitive database ?
Here you're introducing something that we've all been familiar with
since the dawn of the computer age. This is more a people problem than
anything and is beyond the scope of this thread. But here are some
notes:
1. If you can't trust your developers, then you're lost,
2. You can enhance data security many ways. One is to limit database
updates to stored procedures: the stored procedures have access to the
data but users and developers don't.
> And how hard is the Windows Script Encoder to hack ?
> Is it 128 bit encryption ?
I might reply, "Does the VB compiler produce 128 bit encrypted code?",
but both your question and my supposed reply are rather silly in this
context. All you've done here is unnecessarily introduce a term, "128
bit encryption", heretofore not part of the discussion. By doing so,
you're either intentionally or unintentionally confusing issues.
FWIW remember that compilation is merely translation(from source code to
machine code), it is *not* encryption. Compiling a VB program to machine
code does not encrypt the code. At least Microsoft's WSE is *designed*
to hide code. If it doesn't work adequately and someone steals your
code, you can always sue Microsoft and gain redress. But if the compiler
doesn't encrypt your code (and of course it doesn't because it is not
*designed* to do so - it is a translator), then it is not clear that you
would have legal grounds to sue Microsoft if someone reverse compiles
your code.
In such an instance you might however have a strong legal argument
because Microsoft claims that compiled components somehow provide more
security than script. So you might possibly have some recourse because
of this marketing "oversight" on their part.
> > Components won't overcome bad design. Spaghetti code can be written in
> > either VB or ASP.
>
> True
>
> > However the VB spaghetti code will be less reliable,
> > contain more lines of code, be more difficult to develop and maintain,
> > and be less portable from one Windows system to another.
>
> You are right that people who write spaghetti code often have more success
> coding pure ASP applications.
Of course this isn't what I said above!-)
> I'm talking about the following situation:
> - A large website, with lot's of applications that iterate through roughly
> 1-2 month development cycles (and not in the same frequency :-)
> - millions of visitors
> - 10-20 developers
> - best practices and good coding conventions have been established and
> educated to the developers
> - they produce well structured code, or the spaghetti gets caught by
> reviewing the code before staging.
> - some parts of the database are so sensitive that only a few developers
> should have access to it.
>
> In this scenario and in my experience, pure ASP applications give a lot more
> pitfalls for bad design and spaghetti-code, the lack of encapsulation, the
> typlessness, the magnitude of include files that are included across
> applications (common functions), the weak security, they all contribute to
> making a big mess of things. Not to mention that scaleability is a problem.
> Plus the developers who work on the sensitive application all have access to
> the sensitive database.
Simply because your experienced failure doesn't mean that it's
impossible. Remember that it's been done before, and the code's still
running. Every time you make an airline reservation, you're using it,
for example.
As I mentioned earlier we, as a development community, have "forgotten"
how to develop large-scale software. Presented with systems that are
similar to those our fathers developed, most don't know what to do.
> > > 9) limited UML modelling possibilities
> > Read up on both UML and Microsoft's DNA architecture(I recommend
> > starting with the former, so as to not waste time). Microsoft's entire
> > component methodology is at cross-purposes with UML, which was designed
> > for *object-oriented* systems development, not for component-oriented
> > development. Also, AFAIK there is no generally-accepted UML
> > model/pattern for the web, although there are proposed models/patterns
> > (all designed for non-Microsoft architectures, I might add).
>
> Hmm, again the hostility, when someone has a different view than you they
> mus need to "Read up on both UML and Microsoft's DNA architecture", forgive
> me for asking, but quite frankly, don't you think that's rather arrogant ?
Again, no reason to get personal or make assumptions about me. What I
said was pointed out earlier by Bjorn noted in the initial post of this
thread (asterisks * mine) :
news://msnews.microsoft.com/OE3kYHVVAHA.60%40cppssbbsa02.microsoft.com
Bjorn> This may improve scaleability a whole lot, but *it also makes
Bjorn> it virtually impossible to keep an object oriented design for
Bjorn> the application. Components/Objects are now reduced to simply
Bjorn> be containers of functions, to be used totally independant from
Bjorn> each other.* Right? Sure, you could find examples where you
Bjorn> could store som kind of general data, but in reality this
Bjorn> totally detroys any OO attempts. Does anyone have any opinion
Bjorn> about how you still could keep som OO approach
Bjorn> for building scaleable DNA applications?
and as ASP pointed out in the second post of this thread (again,
asterisks * mine) :
news://msnews.microsoft.com/974990198.3a1d2b76061c6%40webmail.cotse.com
ASP> in a nutshell you are correct. *MTS objects should
ASP> not hold state so your OO concepts should be put on a
ASP> back burner.* Instead you should write your objects
ASP> as services, not as an OO heirarchy ...
So why you chose to note my statements as "hostile" but not theirs
escapes me.
Thank you to both Bjorn and ASP for their eminently rational
statements!-))
> For example Rational Rose 2000e is good for modelling components for Windows
> DNA, it has forward and reverse engeneering for components, this is what
> speeds up the documentation and development of the buisness logic.
> There is no way to forward or reverse engeneer a method/function/sub in ASP,
> this is my point.
Another bolt out of the blue, or possibly a SPAM pitch for Rational!-)
So possibly, for you, the substance of this discussion is dross?
Is the real reason you use VB components: simply because you use
Rational Rose to generate VB?
Is this not a case of "the tail wagging the dog"? More precisely, are
you not trying to use RR to solve a problem it was not designed to
solve?
> As for how generally-accepted and usefull their entire model for Windows DNA
> applications is in general, I'm sure it will change a lot before it's
> finished.
> I hope we can have a more constructive discussion, I would really like to
> know what makes you so convinced that COM+ is "the work of the devil" :-)
COM is probably not "the work of the devil", but it might be "the work
of Bill Gates"!-))
No, COM was once to me like a beautiful dark-haired Spanish dancer: When
I first looked into her eyes, aglow in the firelight, my heart was swept
away, I could not breathe without seeing her again. The smell of her
hair, her warmth against me was all I ever wanted or needed: I was in
love. We danced the night away; I wished the music would never end. In
the morning I woke up in a roadside ditch with a raging headache, a lump
on my head, my wallet and keys gone.
jre
my marghuerita. Sorry Bjorn.
Björn Ekberg <bjorn....@enspiro.se> wrote in message
news:#aSo2ZVXAHA.204@cppssbbsa03...
> This discussion is about how to obtain an OO design in a DNA project and
> still make use of JITA, COM+ etc. Unless you don't have any constructive
> angles to it, please post your pseudo intellectual thoughts somewhere else.
>
> BTW, spellcheck this: Sug min kuk! -))
>
>
> "Michael D. Kersey" <mdke...@hal-pc.org> wrote in message
> news:3A27EBF9...@hal-pc.org...
> > "Björn Ekberg" wrote:
> > >
> > > Although I appriciate that people are taking interest in the discussion,
> I
> > > connot help beeing surprised how eager some are to critisize just about
> > > everything Microsoft does. Arguments like " X has been around on
> mainframes
> > > or UNIX systems for years" is is just pointless.
> >
> > No, it's simply pointing out that things are sometimes easier if you
> > don't ascribe magical properties to acronyms, especially Microsoft's
> > acronyms. In general, you have two choices as a programmer:
> > 1. Learn the discipline of programming with various languages, various
> > algorithms, and tools,
> > 2. Trust that the next toolkit from the acronym-vendor will solve your
> > problem.
> >
> > Choose 1 and your skills will increase throughout your career. Choose 2
> > and your skills will be rendered defunct in every marketing cycle, when
> > each the new set of acronyms is released. A good example is how
> > Microsoft is discarding VBScript and Visual Basic in ASP+.
> >
> > > One could say that all you
> > > really need is a few mnemonics, and you could do just about anything,
> even
> > > 25 years ago.
> >
> > That's precisely the idea that acronym marketing encourages: "If we only
> > had Microsoft's XYZ we could solve this problem... If we only ran our
> > components in ABC we could solve that problem..."
> > whereas the true solution lies in thinking about the problem and solving
> > it with programming tools and techniques that have been around for
> > years.
> >
> > > "Shared librarys" could maybe be compared to DLL:s. There is however a
> big
> > > difference between DLL:s and COM components.
> >
> > I'm well aware of that. You apparently missed my point entirely: "shared
> > librarys" have been used by high throughput transaction processing
> > systems for computer eons. They work extremely well and are time-tested
> > technology. They're in use today and will be in use in 20 years. DLLs
> > were a technology for use in Windows for sharing code. They were not
> > well-designed for the platform: they are legacy technology. COM was a
> > hack from the beginning: it is now so difficult to market and support
> > that Microsoft is discarding it. It is already a legacy technology.
> >
> > > If you preffer hacking perl, python, RPG, PHP or whatever and
> > I *am* partial to Perl!-)
> >
> > > enjoy inventing the wheel for the millionth time,
> > This would be a useful analogy if it were indeed "analogous".
> > Unfortunately Microsoft has time and time again designed "wheels" that
> > are square, octagonal, triangular, but for some reason, never round.
> > This uncanny capability to "snatch defeat from the jaws of victory"
> > eventually takes a toll on the customer population. Consumers may have a
> > herd mentality, but they are not idiots.
> >
> > > please feel free to do so, but
> > > learn about COM before you enter the discsson.
> >
> > Argumentum ad hominem.
> > And I am unfortunately *intimately* familiar (read "been screwed by")
> > with COM, in it's various incarnations.
> >
> > > The thing is that Microsoft offers high end functionality, wrapped in
> > > easy-to-use products.
> >
> > This is simple marketing speak.
> >
> > > I find COM and everything sprung out of it to be one of
> > > the greatest software accievments the latest 10 years.
> >
Adrian Forbes
focuses on semantics.
Michael D. Kersey <mdke...@hal-pc.org> wrote in message
news:3A285845...@hal-pc.org...
Adrian Forbes
> *must* include performance as a parameter.
I agree, but you argue that performance *is* scalability. Not directly but
you imply it. For example you state that it is better to run in-process
than use MTS; such an argument ignores scalability in favour of performance.
> But if it's unnecessary, why use it?
If it is unnecessary then you shouldn't use it.
> Code should run in-process as much as possible, which unquestionably
> creates the least overhead and is most reliable.
Yes, but for reasons of scalability sometimes you *have* to run out of
process. You also state that it is the most reliable, I'd have to disagree.
If my ASP page uses out of process DLLs and they crash then my system is
still stable. If it uses in-process DLLs and they crash then my whole site
comes down.
> With shared libraries there is usually only 1 copy. Such an architecture
> is eminently scalable. JITA is a late (20-years late) attempt to catch
> up.
There is only one copy of the code (for want of a better word) but there are
multiple instances of the state, one for each user. There is no relation
between this and JITA, again I feel you do not fully understand what you are
talking about.
> > > > The advantage with MTS transactions is that you get
> > > > them code-free, and they can include not just database updates but
LDAP,
> > > > ADSI, Exchange, text files, anything that you have a broker for.
>
> "Ah! But therein lies the rub!" In true Microsoft fashion, *you* get to
> write the broker!-))
Not at all, the ability to write your own is only there if you need it.
Brokers exist for all the most used applications such as queing, databases,
LDAP etc. In this respect the architecture is similar to ODBC. All common
databases and info stores have an ODBC driver, but you can still write your
own if you want to. Such an open architecture is good, IMHO.
> The broker does the real transaction processing, all MTS does is
> *supervise* the process. So you're actually inserting an unnecessary
> layer (MTS) into an already well-defined process. In the spirit of
> rationality, remove the unnecessary layer, which is MTS. Any unnecessary
> code decreases the reliability and availability of a system. Do the
> math.
Yes, MTS is a layered system. However the issue is whether or not the
benefits of MTS outweigh the cons. You'll have to decide these things for
every technology choice you make, MTS is no different. As for extra code,
again you demonstrate a fundamental lack of practical knowledge and
understanding. MTS requires NO extra code, you seem to be missing my point
about getting transactions FOR FREE. Why write your code when someone else
has done it all for you? That's what *I* call unneccesary.
> If they(brokers) have transactional capability, then MTS is unnecessary.
No. Using MTS you can enlist separate stores in the same transaction.
Something you can only do with a DTC. MTS is not the *only* DTC, but you
are rubbishing the whole concept, not MTS particularly.
> This is a bad thing?
Not nessecarily. If the architecture is worse then it is a bad thing.
> No, not my words. But I did say it was unnecessary.
*sigh*
> These features either
> a. can be easily coded, or
Easily coded? Hardly. However, why write *any* code is MSMQ gives it to
you for free?
> b. are available already.
Yes, and MSMQ is one of those packages. Being based on COM means it works
well with other MS technologies.
> MTS is designed primarily to inextricably tie an application to the
> vendor's platform.
No, as long as other platforms have the support they can use MTS. However
if you are wanting to mix platforms then MTS wouldn't be your best bet.
> And I'll say it again: Any measure of "scalability" that does not
> include performance is useless.
But your arguments aren't about "including an element of performance", to
you scalability *is* performance.
> Here you attempt to turn faults into virtues: below you admit that
> you've written poorly-performing systems using MTS and MSMQ.
Mmmm...don't think so. Please do not put words into my mouth.
> > > Be certain, noble reader, that every day across millions of locations
> > > the internet runs without Microsoft, without MTS, without ADSI,
without
> > > Exchange, without Outlook, without COM, without COM+, without
iDispatch,
> > > without JITA, without MSMQ and that their disappearance from the face
of
> > > the earth would have no effect whatsoever on that network other than
to
> > > increase the information content of the medium.
> >
> > And I run those sites and they run very well.
>
> Thank you for confirming my views.
I have never denied that there is a place for simple web sites.
> > However I also run sites
> > where, quite frankly, the user can wait that extra 1 second, I don't
> > care....but those sites have to be available 24/7 and they have to scale
cos
> > they get hammered.
>
> Thank you for confirming my views.
Un, so you do agree with me then? Good to see you are coming to your senses
at last.
> And, I almost forgot, here's an electronic Cracker Jack prize for
> writing systems that suck and bragging on it.
You define a system that gets used 24/7 365 days a week with no down time
and constant heavy load as one that sucks? Is this all you can do? Falsly
apply negative attributes then, without confirmation that those attributes
are true, use then against me? Sad.
Michael D. Kersey
>
> Wow, there's a surprise. MDK ignores all the technical arguments in instead
> focuses on semantics.
"You can take a horse to water, but you can't make him drink."
- Old Texas saying.
I was hoping to walk with Adrian through a dialogue about scalability,
but it turns out that, due to the limitations of the internet, I was
once again unwittingly speaking to the wrong end of the horse!-(
IMO a reasonable definition of scalability for a given platform P and
application A is
S(A,P) = R(A,P) / C(A,P)
where
R = Maximum number of requests processed per second by application A on
platform P,
C = Cost of hardware and software to develop and support application A
on platform P.
I've assumed 100% availability for the purposes of this discussion.
Availability could be added as an input to the definition if desired.
This term displays the expected behavior shown by common usage of the
term "scalability":
1. As throughput R increases, scalability increases,
2. As cost C increases, scalability decreases,
3. Different platforms and different software may be compared using this
definition,
4. You can use this definition to estimate costs of a proposed system,
given an anticipated user load.
5. Both R and C can be estimated using known techniques.
So using this definition, scalability's dimensions would be "requests
processed per second per dollar". Given the following known values for a
single application Z:
running on platform X:
R(Z) = 1000 requests/second,
C(Z) = $40,000
S(Z) = 1000 requests/second / $40,000 = 0.025
running on not-so-fast but less expensive platform Y:
R(Z) = 500 requests/second,
C(Z) = $10,000
S(Z) = 500 requests/second / $10,000 = 0.05
While platform Y's throughput (performance) is much less than that of
platform Y, Y is much more scalable than (in fact is twice as scalable
as) platform X when running application Z.
This definition can also be used to estimate the utility of using
various software methodologies. For example, heavy use of components or
object technology may or may not change each factor in the definition:
the degree to which each is changed determines whether the resultant
system is more or less scalable.
Adrian Forbes
> I was hoping to walk with Adrian through a dialogue about scalability,
> but it turns out that, due to the limitations of the internet, I was
> once again unwittingly speaking to the wrong end of the horse!-(
I only got this far in your post. If you are so intelligent (or claim to
be) why do you have to resort to insult? I'm not interested in playground
tactics and if that's how you argue technical discussions then I don't
really want to know what you have to say.
Allan Ebdrup
[cut]
> As I mentioned earlier we, as a development community, have "forgotten"
> how to develop large-scale software. Presented with systems that are
> similar to those our fathers developed, most don't know what to do.
Hmm, only a fraction of those systems had to handle the heavy workload and
and fast development cycles that the web development deals with today - I
don't think anything has been "forgotten", the development workload is
simply so big that the apprentice has been made magician. And this makes
development in the average enviroment a different ballgame than it was for
20 years ago. The budgets are smaller, the deadlines are shorter and the
workforce is generally not as well educated (meaning that not everyone on
the development team has done a Ph.D on how to build scaleable systems as in
the good old days)
If you are so hooked on "the good old days" then you are back in waterfall
development cycles of years. Things go hand in hand, bringing up "the good
old days" has a lot of implications that I don't care to discuss as it is
mildly put pointless.
I still fail to see why building web applications using COM+ and MTS is a
bad thing when the fact is that you get scaleable, robuste, fault tolerant,
systems. I can recommend it ahead of pure ASP any day - but then again my
development teams probably differ a lot from yours.
Again it's all about picking the right tool for the job and getting the job
done - nothing you have said arguments that COM+ is a bad solution:
Let me use one of your own useless qoutes: "Simply because your experienced
failure doesn't mean that it's impossible. Remember that it's been done
before."
Kind Regards,
Allan Ebdrup
Michael D. Kersey
>
> "Michael D. Kersey" <mdke...@hal-pc.org> wrote in message
> news:3A2ACEC3...@hal-pc.org...
> [cut]
> > As I mentioned earlier we, as a development community, have "forgotten"
> > how to develop large-scale software. Presented with systems that are
> > similar to those our fathers developed, most don't know what to do.
> [cut]
>
> Hmm, only a fraction of those systems had to handle the heavy workload and
> and fast development cycles that the web development deals with today - I
> don't think anything has been "forgotten", the development workload is
> simply so big that the apprentice has been made magician. And this makes
> development in the average enviroment a different ballgame than it was for
> 20 years ago. The budgets are smaller, the deadlines are shorter and the
> workforce is generally not as well educated (meaning that not everyone on
> the development team has done a Ph.D on how to build scaleable systems as in
> the good old days)
I think you're on point about this: the knowledge may be there, but it's
"diluted" - more people working in IT on more projects. To boot, user
expectations are very high.
> If you are so hooked on "the good old days" then you are back in waterfall
> development cycles of years. Things go hand in hand, bringing up "the good
> old days" has a lot of implications that I don't care to discuss as it is
> mildly put pointless.
Reminiscing is pointless, but the lessons of what you term the "good old
days" are still valid. And IMO the web environment is much more similar
to a mainframe environment than to a client/server environment.
> I still fail to see why building web applications using COM+ and MTS is a
> bad thing when the fact is that you get scaleable, robuste, fault tolerant,
> systems. I can recommend it ahead of pure ASP any day - but then again my
> development teams probably differ a lot from yours.
>
> Again it's all about picking the right tool for the job and getting the job
> done - nothing you have said arguments that COM+ is a bad solution:
> Let me use one of your own useless qoutes: "Simply because your experienced
> failure doesn't mean that it's impossible. Remember that it's been done
> before."
Glad you found that quote useful!-))
> Kind Regards,
> Allan Ebdrup
An interesting analysis and set of graphs is available at the Microsoft
Nile.com site
http://msdn.microsoft.com/library/techart/Docu2kbench.htm#docu2kbench_topic5
wherein the application was converted from VB COM to VBScript classes
with no any attempt to optimize the code for script. On Windows 2000
VBScript code consistently outperforms the VB COM implmentation when the
system has more than 500 users.
They also state that:
MSFT> Of course, the all-ASP version cannot benefit
MSFT> from features of COM+ like the security
MSFT> model, component queuing, and dynamic load balancing.
^^^^^^^^^^^^^^^^^^^^^^^^^^
but later admit that:
> In the recent application server wars, a feature called
> dynamic load balancing was given a lot of airtime by most
> application server vendors, and hence by press and analysts.
> Ironically, dynamic load balancing is a feature that is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> used in very few large-scale Web sites. Rather, the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the dominant way in which most large scale sites achieve
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> scale out is to use a more simplistic network-level
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> load balancing.
^^^^^^^^^^^^^^^
Allan Ebdrup
> An interesting analysis and set of graphs is available at the Microsoft
> Nile.com site
>
http://msdn.microsoft.com/library/techart/Docu2kbench.htm#docu2kbench_topic5
>
> wherein the application was converted from VB COM to VBScript classes
> with no any attempt to optimize the code for script. On Windows 2000
> VBScript code consistently outperforms the VB COM implmentation when the
> system has more than 500 users.
I would say that the performance is comparable. "outperforms" is pretty
harsh without having done the tests yourself under your own configuration
and the difference is in the 10% range. Still thought provoking though.
here is a qoute from the comments at MSDN:
- Michael D. Long wrote on 08 Dec 2000:
> As to your theory that COM objects perform more better when the task is
more
> complex, this holds true based on results of benchmarks I have conducted.
> In order to realize a benefit, the amount of work must exceed the latency
of
> invoking the object + a percentage of the time the script takes to
execute.
> They also state that:
> MSFT> Of course, the all-ASP version cannot benefit
> MSFT> from features of COM+ like the security
> MSFT> model, component queuing, and dynamic load balancing.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> but later admit that:
> > In the recent application server wars, a feature called
> > dynamic load balancing was given a lot of airtime by most
> > application server vendors, and hence by press and analysts.
> > Ironically, dynamic load balancing is a feature that is
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > used in very few large-scale Web sites. Rather, the
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > the dominant way in which most large scale sites achieve
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > scale out is to use a more simplistic network-level
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > load balancing.
> ^^^^^^^^^^^^^^^
Of corse, but doesn't say anything about queued components beeing bad. The
technology is so new that you can't judge if it will be used - but even if
it should get phased out (i doubt it anytime soon) you've lost allmost
nothing, because queueing you components hardly has any changes to your
code.
You forgot one important qoute:
> Also, by placing logic in COM+ components, developers
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> tend to better avoid the exploding spaghetti-code nature
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> of very long/complex ASP pages
^^^^^^^^^^^^^^^^^^^^^^^^^^
Who cares if you can build scaleabe web applications with ASP if you
developers are writing spaghetti-code and unmaintainable systemes that are
impossible to develop. Seems others than myself has come to this conclusion.
As you can see from the conclusion it states nothing about using pure ASP.
As I wrote in my last post:
> > I still fail to see why building web applications using COM+ and MTS is
a
> > bad thing when the fact is that you get scaleable, robuste, fault
tolerant,
> > systems. I can recommend it ahead of pure ASP any day - but then again
my
> > development teams probably differ a lot from yours.
> >
> > Again it's all about picking the right tool for the job and getting the
job
> > done - nothing you have said arguments that COM+ is a bad solution:
If you are having success with building pure ASP applications, then all the
best of luck to you.
Building systems the sizes I've mentioned before (millions of usere, many
applications, fast development iterations) I would never buy a system
developed in pure ASP (not even from you ;-).
Kind Regards,
Allan Ebdrup
Michael D. Kersey
> You forgot one important qoute:
>
> > Also, by placing logic in COM+ components, developers
>
> developers are writing spaghetti-code and unmaintainable systemes that are
> impossible to develop. Seems others than myself has come to this conclusion.
> As you can see from the conclusion it states nothing about using pure ASP.
I will quickly dismiss the "red herring" argument that scripting
languages result in the production of so-called "spaghetti code".
SPAGHETTI CODE DEFINED
======================
First we'll start with a definition of what "spaghetti code" is, taken
from the "New Hacker's dictionary" (we will later discuss the validity
of this definition in today's context):
spaghetti code /n./ - Code with a complex and tangled control structure,
esp. one using many GOTOs, exceptions, or other `unstructured' branching
constructs. Pejorative. The synonym `kangaroo code' has been reported,
doubtless because such code has so many jumps in it.
This usage goes back to the days when COBOL and FORTRAN were in common
use. Both those languages have a number of variants of the GO TO:
FORTRAN:
a. simple GO TO statement,
b. computed GO TO statement,
c. ASSIGNED GO TO,
COBOL:
a. simple GO TO statement,
b. GO TO DEPENDING statement,
c. ALTER statement, which alters the target of a branch,
d. PERFORM, PERFORM THROUGH, PERFORM THROUGH UNTIL statements (which
may or may not be a member of this genre).
Visual Basic has several "dangerous" forms of the GO TO statement
mentioned above:
a. simple GOTO statement,
b. GOSUB statement,
c. ON ERROR GOTO nnnnn (see Note, below).
Visual Basic is therefore, along with COBOL and FORTRAN, a *full-fledged
member of the family of spaghetti code languages* because of it's
inclusion of these language constructs, especially the first two. (Note:
I do not consider the "ON ERROR GOTO nnn" construct to be any detriment
to VB because it is an error handling construct and is invoked only for
exception handling. I have included it here for completeness only.)
Unlike Visual Basic, VBScript has *no* true GO TO statement whatsoever.
This renders it *impossible* to write spaghetti code in VBScript!
The misguided might construe the error handling construct:
ON ERROR GOTO 0; On ERROR RESUME NEXT
as a GO TO, but it is *not in fact a branching statement at all*, but
merely a mechanism that sets a flag for exception handling.
Thus not only it is *impossible* to write spaghetti code in VBScript,
but it is *very easy* to write sphaghetti code in VB!
DISCUSSION OF THE DEFINITION'S VALIDITY TODAY
=============================================
Now, as Bill Clinton might say, all of this depends on the definition of
"spaghetti code", and this term is changing over time. Many persons
unfamiliar with programming in several languages and with the older
usage of the term will use "spaghetti code" to indicate what (to them)
is merely *an unduly long sequence of code*.
But long sequences of code are are often necessary regardless of
language. So this usage of "spaghetti code" as a pejorative term is
questionable at best.
A most curious phenomenon can be noted in a post at
http://faqchest.dynhost.com/prgm/perlu-l/perl-98/perl-9807/perl-980703/perl98072215_11575.html
wherein the following question and answer are posted:
> >Bonus: What is the OPPOSITE of spaghetti code?
>
> Straight code. Let me explain: spaghetti code jumps from here to there
> and anywhere. The opposite is no jumps at all, not even subroutine
> calls. The code statements are simply executed in the same order as they
> are in the source.
> Bart.
So now you can see the change in usage:
1. the original term as defined above,
2. one modern usage, meaning a "long sequence of concatenated code", and
3. another modern usage to define it's supposed opposite: code with "no
jumps at all"; IOW, "concatenated code"!
For this reason, I believe the term, while originally useful and
informative, has now become for all practical purposes simply a
pejorative expression of the NIH ("Not Invented Here") Syndrome so
prevalent among programmers(indeed among most people and peoples). IOW
it's only truly meaningful usage is under the older definition.
FURTHER SUPPORT
===============
One need only go to any common search engine and type in the phrase
"spaghetti code VB" or "spaghetti code Visual Basic" to find that the
term has often been used to describe VB. Indeed any language that
provides the developer with the GO TO construct falls prey to the charge
that it encourages spaghetti coding.
SUMMARY
=======
It is impossible to write spaghetti code (as defined in the original
sense) using VBScript, but it is possible and even easy to write it
using VB. If you wish to ensure that your developers *cannot* write
spaghetti code then give them a language, VBScript, that does not allow
them to do so.
But don't confuse "spaghetti code" with "lots of code" or "long
sequences of code" - they simply aren't the same thing. And be wary of
criticizing developers who write long sequences of code - often it is
necessary. Such code is usually simple, easy to read and to debug, and
it almost always executes as fast if not faster than heavily nested
subroutine/function calls. Of course it is certainly acceptable and
sometimes suggested practice to heavily use subroutines/function in
either VB or VBScript.
Footnote
========
Visit the Nile.com report at
http://msdn.microsoft.com/library/techart/Docu2kbench.htm
where unoptimized VBScript is shown to execute faster than optimized VB
and COM components on Windows 2000. See in particular Figure 9 where
VBScript outruns VB&COM by 7-10% when the number of users rises above
500.
Allan Ebdrup
> Allan Ebdrup wrote:
> > You forgot one important qoute:
> >
> > > Also, by placing logic in COM+ components, developers
> > > tend to better avoid the exploding spaghetti-code nature
> > > of very long/complex ASP pages
> >
> > Who cares if you can build scaleabe web applications with ASP if you
> > developers are writing spaghetti-code and unmaintainable systemes that
are
> > impossible to develop. Seems others than myself has come to this
conclusion.
> > As you can see from the conclusion it states nothing about using pure
ASP.
>
> I will quickly dismiss the "red herring" argument that scripting
> languages result in the production of so-called "spaghetti code".
> SPAGHETTI CODE DEFINED
> ======================
Who cares what you and the hachers dictionary call it I'm sure everyone but
you understands what I mean - do a search and replace on my post and replace
"spaghetti" with "unmaintainable".
> FURTHER SUPPORT
> ===============
> One need only go to any common search engine and type in the phrase
> "spaghetti code VB" or "spaghetti code Visual Basic" to find that the
> term has often been used to describe VB. Indeed any language that
> provides the developer with the GO TO construct falls prey to the charge
> that it encourages spaghetti coding.
[CUT]
Who cares about Goto's everyone stopped using them 10-20 years ago.
> Footnote
> ========
> Visit the Nile.com report at
> http://msdn.microsoft.com/library/techart/Docu2kbench.htm
> where unoptimized VBScript is shown to execute faster than optimized VB
> and COM components on Windows 2000. See in particular Figure 9 where
> VBScript outruns VB&COM by 7-10% when the number of users rises above
> 500.
Read my original message again and you will see that have visited that site.
I must say that if there was a price for the amounts of pointless- /
off-the-point- information someone gave in a posting - you would have my
vote :-)
Kind Regards,
Allan Ebdrup
Michael D. Kersey
> Who cares what you and the hachers dictionary call it I'm sure everyone but
> you understands what I mean - do a search and replace on my post and replace
> "spaghetti" with "unmaintainable".
Your post is sadly devoid of any but misleading information. And it has
unwarranted ad hominem attacks.
You refused to accept a useful definition for the term "spaghetti code",
a definition in common usage for decades. Now you argue that
"unmaintainable" code is something? - what precisely is unknown, since
you say precisely nothing!
Possibly you meant to say that "unmaintainable code is unmaintainable"?
This can be questioned on two points at least:
a. the argument is a tautology (circular argument),
b. the term "unmaintainable" now begs for definition just as "spaghetti
code" did earlier. So let's analyze the term:
DEFINITION OF "UNMAINTAINABLE"
==============================
"Unmaintainable", when used in reference to code, is a relative term.
Code unmaintainable by Joe (who did not write it) may be eminently
maintainable by Fred(who wrote it). So what criteria are we to use to
determine whether code is "unmaintainable" or "maintainable"?
While there is code that is "difficult to maintain by most programmers"
or that is "difficult to maintain by Allan or Mike" or such, there is no
such thing as *unmaintainable code*. The only proper usage of the term
"unmaintainable" is as a predicate with at least two arguments:
unmaintainable(ProgramX, JoeBob)
which can be interpreted to state that "ProgramX is not maintainable by
JoeBob". Further, even this omits the possibility that JoeBob might
later actually read the documentation for ProgramX and *learn* what
ProgramX does, thereby learning how to maintain it. So the predicate
should be further modified to state conditions:
unmaintainable(ProgramX, JoeBob, Conditions)
where conditions = "Until JoeBob reads ProgramX's documentation."
So as you earlier used the term "spaghetti code" without defining it and
indeed, apparently without even knowing what it meant, so now you use
the term "unmaintainable" in a meaningless sense. This is below your
ability.
> Who cares about Goto's everyone stopped using them 10-20 years ago.
That's part of the point, poor fellow! If one does not use such
constructs as GO TO's, then one cannot write "spaghetti code". You can
write "complex code" or "code that is difficult to understand" or "long
sequences of boring code" , but it is not "spaghetti code" and it is not
"unmaintainable code". Secondly, the "unmaintainable" nature of code
disappears once one understands what the code does and how it works.
In this sense the only possibly "unmaintainable" code on the planet is
the genetic code, which now (nearly) lies open before our eyes, but
which we do not fully understand. AFAIK there is no documentation for
that code, so it may never be fully "maintainable". OTOH that does not
prevent us from "hacking" it, i.e., manipulating it to see what happens.
Finally, GO TO's are still in use. They have their place surprisingly.
But not in VBScript, since VBScript has no branching form of GOTO and as
I stated in my earlier post it is therefore impossible to write
spaghetti code in VBScript. In contrast, Visual Basic allows the user to
write "spaghetti code" very easily. "Spaghetti code" as defined in the
classic sense is considered to be more difficult to maintain.
> > Footnote
> > ========
> > Visit the Nile.com report at
> > http://msdn.microsoft.com/library/techart/Docu2kbench.htm
> > where unoptimized VBScript is shown to execute faster than optimized VB
> > and COM components on Windows 2000. See in particular Figure 9 where
> > VBScript outruns VB&COM by 7-10% when the number of users rises above
> > 500.
> Read my original message again and you will see that have visited that site.
The footnote, reproduced yet again above, is not for you, who seem
impervious to enlightenment even though stricken to the ground and
blinded by the light, but is instead for others, who may have a more
open mind and who actively seek knowledge.
> I must say that if there was a price for the amounts of pointless- /
> off-the-point- information someone gave in a posting - you would have my
> vote :-)
Your arguments are too weak to push a stylus through a Florida state
ballot: your vote would be thrown out. But thanks for the "dimple",
anyway!-))
Allan Ebdrup
> Allan Ebdrup wrote:
> > Who cares what you and the hachers dictionary call it I'm sure everyone
but
> > you understands what I mean - do a search and replace on my post and
replace
> > "spaghetti" with "unmaintainable".
>
> Your post is sadly devoid of any but misleading information. And it has
> unwarranted ad hominem attacks.
>
> You refused to accept a useful definition for the term "spaghetti code",
> a definition in common usage for decades.
You are the one stuck on semantics when everyone else gets on with the real
and interesting discussion. And might I add that your source introduced the
term, I merely qouted and followed up on your source.
I mean all of the above each to some degree.
> > Who cares about Goto's everyone stopped using them 10-20 years ago.
>
> That's part of the point, poor fellow! If one does not use such
> constructs as GO TO's, then one cannot write "spaghetti code". You can
> write "complex code" or "code that is difficult to understand" or "long
> sequences of boring code" , but it is not "spaghetti code" and it is not
> "unmaintainable code". Secondly, the "unmaintainable" nature of code
> disappears once one understands what the code does and how it works.
I fail to se a relevant point in this. although it is not uncorrect.
I used the term "Unmaintainability" from a practical viewpoint. If you code
is so messy that it takes longer to write a new application than to make
changes in the old one, then the code is for all practial conserns
unmaintainable - as anyone paying for the development will have you throw
the code away never to be seen again thus never to be maintained again.
If my choice of words leaves a reader puzzeled, the answer might lie in the
fact that English is not my native language (as mentioned earlier), or a
lack of willingness to discuss what is being said, or even a extreme
inability to abstract from typos and bad phrasing.
> In this sense the only possibly "unmaintainable" code on the planet is
> the genetic code, which now (nearly) lies open before our eyes, but
> which we do not fully understand. AFAIK there is no documentation for
> that code, so it may never be fully "maintainable". OTOH that does not
> prevent us from "hacking" it, i.e., manipulating it to see what happens.
I fail to se a relevant point in you bringing up this information. although
it is not uncorrect.
> Finally, GO TO's are still in use. They have their place surprisingly.
> But not in VBScript, since VBScript has no branching form of GOTO and as
> I stated in my earlier post it is therefore impossible to write
> spaghetti code in VBScript. In contrast, Visual Basic allows the user to
> write "spaghetti code" very easily. "Spaghetti code" as defined in the
> classic sense is considered to be more difficult to maintain.
Here you have a chance to add some valuable information. In the context of
our discussion (ASP vs. COM+ in building scaleable, robust, maintainable web
applications - in case you forgot) where do you find GOTOs ? and what is
their place ? Neither I nor any of developers use them - is there something
we have missed ? If so I would like to know. Or is this more off-the-point
and hence useless information ?
> > > Footnote
> > > ========
> > > Visit the Nile.com report at
> > > http://msdn.microsoft.com/library/techart/Docu2kbench.htm
> > > where unoptimized VBScript is shown to execute faster than optimized
VB
> > > and COM components on Windows 2000. See in particular Figure 9 where
> > > VBScript outruns VB&COM by 7-10% when the number of users rises above
> > > 500.
> > Read my original message again and you will see that have visited that
site.
>
> The footnote, reproduced yet again above, is not for you, who seem
> impervious to enlightenment even though stricken to the ground and
> blinded by the light, but is instead for others, who may have a more
> open mind and who actively seek knowledge.
There is no need to make assumptions about me, as I strive not to do about
you, since you asked me not to.
You posted the footnote again in a reply to me, after having given it in the
post I replied to, so you can see why I would think you wrote it for me, the
only logic explanation. One that escaped you though.
> > I must say that if there was a price for the amounts of pointless- /
> > off-the-point- information someone gave in a posting - you would have my
> > vote :-)
>
> Your arguments are too weak to push a stylus through a Florida state
> ballot: your vote would be thrown out. But thanks for the "dimple",
> anyway!-))
Well at least my arguments are on the subject at hand, you get yet another
vote for the price for
"Vast amounts of pointless- / off-the-point- information in a posting" and
you are clearly in the lead now. With more votes than any other contender,
and looking in great shape.
This discussion is going nowhere (except for your price :-), you should read
what I wote in my earlier posts if you wish to continue this, otherwise it
would serve us best to consider it EOD.
To bad, I was hoping we could agree to disagree on something meaningfull.
Kind Regards,
Allan Ebdrup.
Adrian Forbes
real
> and interesting discussion. And might I add that your source introduced
the
> term, I merely qouted and followed up on your source.
> Well at least my arguments are on the subject at hand, you get yet another
> vote for the price for
> "Vast amounts of pointless- / off-the-point- information in a posting" and
> you are clearly in the lead now. With more votes than any other contender,
> and looking in great shape.
Ah good, so it's not just me who thinks this :)