| Deyan Petrov |
Hi guys,
I have been wondering for a long time about something very important - how
can MS offer the .NET Framework for Enterprise developement, when they have
no managed application server?!
I am sure at this point all of you will start saying - how so, there is the
EnterpriseServices namespace, and there is the .NET Server coming.
However both statements have nothing to do with a MANAGED APP Server, which
should be provided for serious enterprise development in .NET. The
EnterpriseServices in .NET use the old COM+ through COM Interop (big
performance issue), while the .NET Server comes with a new version of COM+,
but still unmanaged.
Moreover, some key features are still missing from COM+.
How can .NET match then the J2EE, where a bunch of app servers already
exists??? How are we supposed to develop scalable distributed apps in
.NET??? Using the old and insufficient COM+?? I am really thinking of
developing a framework myself, which will supply some important services to
my application ... But it's a lot of hard work, which is already done in the
J2EE world. So there are "managed" Java app servers, written in Java,
supplying a lot of extra features like Persistence, Caching of data etc, and
there is only the unmanaged good old COM+?
Please tell me what you think about this serious problem!
Regards,
Deyan Petrov
|
|
| |
| |
| Mitch Denny |
Deyan,
What a can of worms! I'm glad you raised this point since I think
the obvious lack of a seperate application server product is one
of the major selling points of the .NET and Windows platform. Its
a sad fact that many of the operating systems out there don't
provide compelling application services without the addition of
third-party software like WebSphere and WebLogic.
Market Comparison:
Vendors that ship J2EE and UNIX variants are beginning to realise
that customers want an integrated platform and are starting to
release offerings with their product sets bundled together. The
funny thing is that Microsoft has been moving in this direction
for quite some time, MTS was certainly available on Windows NT 4.0
although it was truely integrated with the arrival of Windows 2000
Server and Component Services (COM+).
COM+ Issues:
You like many developers (including myself) has issues with many
of the COM+ service offerings. But, put it into perspective, they
are just application services which you may or may not what, in
this case we are talking about distributed and declaritive
transaction support, object pooling and security.
Now, of these I think the one that most developers will avail
themselves of (when they need it) is declaritive transaction
support, but it is not always required. Think of the marshalling
perf hit as the cost of getting a atomic distributed transaction.
Alternative Approach to App Server Hosting:
When we talk about application servers we are talking about
middle-tier components which are made available to other
applications across process and network boundaries. Nothing in
that definition is hard to do, in fact its as simple as building
a Windows service:
using System;
using System.ServiceProcess;
public class MyService : ServiceBase
{
public static void Main()
{
ServiceBase.Run(new MyService());
}
}
And providing a remoting configuration file:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.runtime.remoting>
...
</system.runtime.remoting>
</configuration>
In order to get the scalability required in the middle tier it
is usually advisable to implement a singleton pattern, but it
isn't mandatory. You can scale the above out quite easily using
NLB or a dedicated hardware load balancer.
Other Architectures:
Of course, here I outline only one of the possible architectures,
quite often (if not the majority of cases) it is acceptable not
to physically seperate your application components (with the
exception of the database server). Applications like IBuySpy
get great performance simply by running the presentation and
business tiers in the same process space, this is perfectly
valid and advisable if security doesn't demand physical
seperation of components (there is a hybrid mix where you have
robot processes working on the back-end which should run on
your front-end farm).
Persistence:
On the subject of persistence, I guess you are specifically
refering to CMP (Container Managed Persistence for those who
haven't worked with J2EE/EJB before). While CMP is a nice feature
quite often it can be a liability and can be just plain painful
to get it to map correctly to your underlying schema.
BMP is a more practical model at the moment, but I am open
to advancements in the ORM space because I really do like
to think object orientated.
Caching:
Caching? What is a cache? Its just a memory storage facility
with a time-decay (usually) facility, ASP.NET has formalised
the mechanism with its Cache intrinsic, but the functionality
is easily emulated in Windows services etc.
Summary:
I guess the bottom line is that I don't see a serious problem
here at all, its quite simple to build enterprise grade applications
in .NET right now and I would be willing to back the Windows
solution on a price/performance basis over your commerical
J2EE platforms. FWIW, I understand that Fujitsu is working on
something in the .NET App Server space, closely aligned with
their existing Interstage product and I am sure Microsoft is
doing something here as well.
Lets get specific! What challenges do you have right now which
you are hitting a wall with .NET on?
----------------------------------------
- Mitch Denny
- Technical Specialist
- Click here to reveal e-mail address
- http://www.monash.net
- +61 (414) 610-141
-
-----Original Message-----
From: Deyan Petrov [mailto:Click here to reveal e-mail address]
Sent: Monday, 29 July 2002 5:45 PM
To: aspngarchitecture
Subject: [aspngarchitecture] MS have no managed Application server??
Hi guys,
I have been wondering for a long time about something very important -
how can MS offer the .NET Framework for Enterprise developement, when
they have no managed application server?! I am sure at this point all of
you will start saying - how so, there is the EnterpriseServices
namespace, and there is the .NET Server coming. However both statements
have nothing to do with a MANAGED APP Server, which should be provided
for serious enterprise development in .NET. The EnterpriseServices in
.NET use the old COM+ through COM Interop (big performance issue), while
the .NET Server comes with a new version of COM+, but still unmanaged.
Moreover, some key features are still missing from COM+. How can .NET
match then the J2EE, where a bunch of app servers already exists??? How
are we supposed to develop scalable distributed apps in .NET??? Using
the old and insufficient COM+?? I am really thinking of developing a
framework myself, which will supply some important services to my
application ... But it's a lot of hard work, which is already done in
the J2EE world. So there are "managed" Java app servers, written in
Java, supplying a lot of extra features like Persistence, Caching of
data etc, and there is only the unmanaged good old COM+?
Please tell me what you think about this serious problem!
Regards,
Deyan Petrov
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Deyan Petrov |
Hi Mitch,
10x for your reply. I like your overview of the general problem, but the
specific problems are more important ;)
The situation now is:
If I want to build an enterprise distributed application I don't have an
appropriate application server to use.
COM+ used in .NET has a number of problems:
1) It requires COM Interop Services to be used, which impedes heavily the
performance.
2) It's an old technology, which has some problems - it allows transaction
attributes only at the class level (not at the method level), in the .NET
Server it will allow to specify isolation level, but now it doesn't. Also
the role-based security means that I have to hardcode the roles in my app,
which I don't want, I want to be able to configure the access permissions of
the roles from the client.
3) It is not easy enough to register your managed components with it.
I need a managed app server, or just a framework of services, which will
allow me to:
1) concentrate on the pure business logic
2) transparent transaction handling, security, logging using the concept of
Interception
3) other scalability/failover services, which at this point are not so
important to me, as I can load balance the interface entry points (the web
servers).
4) persistence management - some form of ORM.
5) transparently distribute even physically my components (for example I
want all the payments to be directed to 2 payment servers in my web farm
using remoting). I will have the presentation and business logic on the same
physical machine, because I fully agree that the cost of
marshalling/unmarshalling is too big.
I intend to use the Facade design pattern, ContextBoundObjects for my Facade
classes with interception, which will add message sinks which will handle
transparently the transaction handling, security and logging. It's too much
work, though. Also I still am not sure what's the best approach to
persistence of my business objects ....
Regards,
Deyan Petrov
"Mitch Denny" <Click here to reveal e-mail address> wrote in message
news:690159@aspngarchitecture...
[Original message clipped]
|
|
| |
|
| |
| Damon Allison |
[Original message clipped]
You're joking, right? While it is possible to use COM+ services, there is
much room for improvement. I'll give you one concrete example.
I am in the process of making an object available via remoting, so I create
a remoting host (like the service approach you suggest). Unfortunately
there is more to hosting a remoting object than saying "Service.Run". For
starters, I want to incorporate Windows security. Second, I want the host
to be multi-threaded to handle multiple requests simultaneously.
I've been told to host my remoting objects in IIS, which provides both
security and performance improvements. Again, this is a joke, right? Try
telling the network team we want IIS on a middle tier machine. Thier
response: no way, we don't want the potential security breaches nor do we
want to patch another IIS server with the rest of our IIS boxes. IIS is not
meant to host middle tier components, its meant to host web sites. Using
IIS in the middle tier is overkill.
Lets also assume that we create another remoting host without using IIS. We
end up either rewriting much of the same functionality or enhancing our
current remoting host to host multiple objects simultaneously. What we end
up doing is creating our own application server. Every company (like
Deyan's) that deploys remoting will be creating their own hosts with common
functionality, a definite candidate for a 'server' solution product. Our
company doesn't have the time nor the resources to create our own
application server.
I would like to see an "Application Center" like managed application server
from MS in the next year to not only host remoting objects, but provide the
other concerns Deyan proposed such as managed transactions, etc.
Damon
----- Original Message -----
From: "Mitch Denny" <Click here to reveal e-mail address>
To: "aspngarchitecture" <Click here to reveal e-mail address>
Sent: Monday, July 29, 2002 5:54 AM
Subject: [aspngarchitecture] RE: MS have no managed Application server??
[Original message clipped]
|
|
| |
|
| |
| James Yang |
hmm I don't get what you are complaining about. What's wrong with creating
distributed apps with remoting? or even creating windows service with .NET
??? Why do you "need" to use COM+ ?
Ive deployed a distributed app with .NET using remoting. for failover and
load balancing ive used application center and works fine!
sorry if i sound stupid.. but to me its quiet obvious to use remoting and
app center for distributed app..maybe cuz i don't get the big picture (???)
James Yang
----- Original Message -----
From: "Deyan Petrov" <Click here to reveal e-mail address>
Newsgroups: aspngarchitecture
To: "aspngarchitecture" <Click here to reveal e-mail address>
Sent: Monday, July 29, 2002 10:16 PM
Subject: [aspngarchitecture] Re: MS have no managed Application server??
[Original message clipped]
|
|
| |
|
| |
| Damon Allison |
The limitation (complaint is too strong a word :-) with remoting in
particular is for every remoting application you create you need to write a
host or use a prebuilt host like IIS. Using IIS is overkill in some
respects and writing multiple hosts to perform multi-threading and security
is repetitive and time consuming.
The key point in your statement was the fact that you use application center
to host your applications. Application center could be enhanced to provide
managed features like acting as a configurable remoting host.
The performance associated with crossing the COM/NET border is unnecessary
and can be avoided with a managed transaction manager. COM relies on old
technology, much of which I don't understand, and seems to be a limiting
factor in managed applications. I'd sure be interested to hear someone
versed in COM give an explanation as to the implications (if any) the
underlying com architecture imposes on managed applications.
Just .02 :-)
Thanks! Damon
----- Original Message -----
From: "James Yang" <Click here to reveal e-mail address>
To: "aspngarchitecture" <Click here to reveal e-mail address>
Sent: Monday, July 29, 2002 7:43 AM
Subject: [aspngarchitecture] Re: MS have no managed Application server??
[Original message clipped]
|
|
| |
|
| |
| James Yang |
Just note.. i know very little about COM+ ... so the purpose of that mail
was to see what COM+ can do... not criticise him for using COM+ in any way..
James
----- Original Message -----
From: "James Yang" <Click here to reveal e-mail address>
To: "aspngarchitecture" <Click here to reveal e-mail address>
Sent: Monday, July 29, 2002 10:43 PM
Subject: [aspngarchitecture] Re: MS have no managed Application server??
[Original message clipped]
|
|
| |
|
| |
| Brian Espey |
in what particular respects do you think using IIS is
overkill?
Brian
--- Damon Allison <Click here to reveal e-mail address> wrote:
[Original message clipped]
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
|
|
| |
|
| |
| Ben Hyrman |
sorry for the long-windedness....but hey, hopefully it touches on some points.
With the advent of COM, Microsoft introduced the Service Control Manager (SCM) to act as the middleman in instantiating objects. You pass the SCM a ProgID, or a class ID, and it handles all of the work of locating and loading the corresponding DLL or out-of-process EXE.
With the introduction of DCOM, the SCM was updated to allow for instantiating objects on remote servers. This helped with building distributed COM applications, but it still wasn't great. DCOM still had some nasty problems that limited scalability and reliability. DCOM would pin requests to a single server. If you went through a load balancer, DCOM would pin to the physical server on the other side. So if a' is the load balancer for a and b, and the request is answered by b, then b has the request for the life of the object. If server b crashes, then the object waits a very long time before timing out...there is a hack to reduce the wait time by modifying the SCM, but it's a hack.
As I understand it, COM+ integrates many one-off solutions into a single package. MTS is now built right in.
It should be noted that COM+ is not COM and .NET does not replace COM+, only COM. Thus, at this point, there is still an interop layer in place....but only at this point.
Application Center introduced Component Load Balancing (CLB). CLB extended the SCM yet again. Where DCOM allowed for remote COM invocation, CLB allowed for dynamic remove COM invocation. Instead of relying on one machine to process all requests, CLB distributes the load across an entire server farm. Application Center constantly monitors the servers in the cluster and distributes work accordingly. App Center does many other wonderful things, but I think it's main worth is in it's CLB abilities.
However, Application Center is a software solution. I do not believe it solves the problems that DCOM had with hardware solutions such as F5's Big/IP load balancer or Cisco's load balancer. With App Center, Microsoft went a far way towards achieving better COM+ scalability. However, I don't think we're there yet.
Notice a trend though, a technology is introduced and then made core to the product. MTS was introduced (anyone remember all the joys and fun of MTS 0.9?) and was eventually bundled in with COM as a solid, and easily managed, offering.
In my opinion, what is missing from .NET that I foresee being bundled into an App Center .NET 2003 Server (or however they're naming things now):
Single deployment to a cluster: Xcopy is great, but it's not fully Microsoft-ized yet. We're spoiled by GUIs and double-clicks. I'd expect to see the ability to deploy to a server cluster, which is what App Center does very well with COM+ today.
Managed component load balancing: A native .NET solution that extends the App Center COM+ support
A remoting server: The two current options, roll your own or use IIS, are not acceptable. I would foresee either a solid standalone remoting server or a stripped down version of IIS 6 that extends the IIS concepts of sites to remoting, but doesn't bring along the need to run a web server.
Things I'd like to see bot expect would come from another vendor: object-relational mapping (good article on C# Today a few weeks ago..and Martin Fowler actually makes this one of the pillars of his upcoming book), tie-in with LDAP for role-based security.
Things I think have come a long way and are at least the building blocks for enterprise development: ASP.NET caching, libraries for thread pooling, ADO.NET connection pooling, better security models.
Ben
---------- Original Message ----------------------------------
From: "James Yang" <Click here to reveal e-mail address>
Reply-To: "aspngarchitecture" <Click here to reveal e-mail address>
Date: Mon, 29 Jul 2002 23:56:45 +1000
[Original message clipped]
|
|
| |
|
| |
| Ben Hyrman |
In the respect that it is a full web server. It is also a full web server that sees a fair number of security bulletins. At least here, the IIS boxes go in the dirty trunks of the network. I would be beaten rather severely if I asked for IIS on an app server.
I see this as a temporary hack to get us through until a solid solution is delivered. A web server that is tuned for I/O and stateless requests should not be forced to play the part of remoting server.
---------- Original Message ----------------------------------
From: Brian Espey <Click here to reveal e-mail address>
Reply-To: "aspngarchitecture" <Click here to reveal e-mail address>
Date: Mon, 29 Jul 2002 08:07:13 -0700 (PDT)
[Original message clipped]
|
|
| |
|
| |
| Damon Allison |
[Original message clipped]
I got it! .NET+ Application Center 2003 XP Server :-)
Only kidding,
Damon
----- Original Message -----
From: "Ben Hyrman" <Click here to reveal e-mail address>
To: "aspngarchitecture" <Click here to reveal e-mail address>
Sent: Monday, July 29, 2002 10:26 AM
Subject: [aspngarchitecture] Re: MS have no managed Application server??
> sorry for the long-windedness....but hey, hopefully it touches on some
points.
[Original message clipped]
ProgID, or a class ID, and it handles all of the work of locating and
loading the corresponding DLL or out-of-process EXE.
[Original message clipped]
distributed COM applications, but it still wasn't great. DCOM still had some
nasty problems that limited scalability and reliability. DCOM would pin
requests to a single server. If you went through a load balancer, DCOM would
pin to the physical server on the other side. So if a' is the load balancer
for a and b, and the request is answered by b, then b has the request for
the life of the object. If server b crashes, then the object waits a very
long time before timing out...there is a hack to reduce the wait time by
modifying the SCM, but it's a hack.
[Original message clipped]
place....but only at this point.
[Original message clipped]
for dynamic remove COM invocation. Instead of relying on one machine to
process all requests, CLB distributes the load across an entire server farm.
Application Center constantly monitors the servers in the cluster and
distributes work accordingly. App Center does many other wonderful things,
but I think it's main worth is in it's CLB abilities.
[Original message clipped]
Big/IP load balancer or Cisco's load balancer. With App Center, Microsoft
went a far way towards achieving better COM+ scalability. However, I don't
think we're there yet.
[Original message clipped]
0.9?) and was eventually bundled in with COM as a solid, and easily managed,
offering.
[Original message clipped]
see the ability to deploy to a server cluster, which is what App Center does
very well with COM+ today.
[Original message clipped]
a stripped down version of IIS 6 that extends the IIS concepts of sites to
remoting, but doesn't bring along the need to run a web server.
[Original message clipped]
Martin Fowler actually makes this one of the pillars of his upcoming book),
tie-in with LDAP for role-based security.
[Original message clipped]
ADO.NET connection pooling, better security models.
[Original message clipped]
|
|
| |
|
| |
| Russ McClelland |
V2VsbCwgbW9zdCBhcHBsaWNhdGlvbnMgZG8gbm90IG5lZWQgYXBwbGljYXRpb24gc2VydmVycy4g
IEFwcCBTZXJ2ZXJzDQphcmUgb25seSBnb29kIGlmIHlvdSBuZWVkIGRpc3RyaWJ1dGVkIHRyYW5z
YWN0aW9ucyhtb3N0IGRvbid0IG5lZWQgdGhpcw0Kb3ZlcmhlYWQgc28ganVzdCB1c2UgbG9jYWwg
dHJhbnNhY3Rpb25zIGF0IHRoZSBEQiBsZXZlbCksIG9iamVjdCBwb29saW5nDQooZGViYXRhYmxl
KSwgc2VjdXJpdHkuICBXaGF0IGZlYXR1cmVzIGFyZSB5b3UgbWlzc2luZyBpbiBDT00rIHRoYXQg
eW91DQp0aGluayBhcmUgYXZhaWxhYmxlIGluIEoyRUU/ICBQZXJzaXN0ZW5jZT8gIA0KIA0KUGVy
c2lzdGVuY2UgKGVpdGhlciB0eXBlKSBpbiBKMkVFIGlzIGEgam9rZS4gIE1QIGluIEoyRUUgaXMg
cHJlZGljYXRlZA0Kb24gdGhlIG5vdGlvbiB0aGF0IHRoZSBhcHAgc2VydmVyIHdpbGwgY2FjaGUg
YSBiZWFuIHdpdGggdGhlICJsYXRlc3QiDQp2ZXJzaW9uIG9mIHRoZSBkYXRhIGluIG1lbW9yeS4g
IFRoaXMgcmVxdWlyZXMgdHdvIHRoaW5nczoNCiANCjEuICBUaGUgZmFsc2UgYXNzdW1wdGlvbiB0
aGF0IHlvdSBjYW4gaGF2ZSB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgZGF0YQ0KZnJvbSBhIGRhdGFi
YXNlIGluIG1lbW9yeSBvbiBhIG1hY2hpbmUgb3RoZXIgdGhhbiB0aGUgREIgc2VydmVyIGl0c2Vs
Zi4NClNheSBJIGhhdmUgMSBtaWxsaW9uIGJlYW5zIGNhY2hlZCBpbiBtZW1vcnkgb24gYXBwIHNl
cnZlcnMgaW4gdGhlDQplbnRlcnByaXNlLiAgTm93IGEgc2NlbmFyaW8gc3VjaCBhcyB0aGlzIG9j
Y3VyczogIGV2ZXJ5b25lIGluIHRoZQ0KZm9sbG93aW5nIFpJUCBjb2RlcyBhcmUgaGF2aW5nIHRo
ZSBhcmVhIGNvZGVzIG9mIHRoZWlyIHBob25lIG51bWJlcnMNCmNoYW5nZSBmcm9tIDIxNCB0byA5
NzIuICBBbSBJIGdvaW5nIHRvIHdyaXRlIGEgamF2YSBhcHAgdG8gY2hhbmdlIHRob3NlDQpwaG9u
ZSBudW1iZXJzIGFuZCB0b3VjaCB0aGUgb25lIG1pbGxpb24gYmVhbnMgdGhhdCBhcmUgYWZmZWN0
ZWQgb3IgYW0gSQ0KZ29pbmcgdG8gc3BlbmQgMzAgc2Vjb25kcyB3cml0aW5nIGEgU1FMIHF1ZXJ5
IHRvIHVwZGF0ZSB0aGUgZGF0YS4gIE5vdw0KYWxsIHlvdXIgY2FjaGVkIGJlYW5zIGFyZSBpbnZh
bGlkIGFuZCBoYXZlIHRvIGJlIHJlLXJlYWQuDQogDQoyLiAgVGhlIGFwcCBzZXJ2ZXIgd2lsbCBk
byBhIGJldHRlciBqb2IgY2FjaGluZyBkYXRhIHRoYW4gdGhlIERCIHNlcnZlci4NClNvLCB5b3Ug
Y2hvaWNlcyBhcmU6IGR1bWIgYSB0b24gb2YgbW9uZXkgYnV5aW5nIG1lbW9yeSBmb3IgZG96ZW5z
IG9mIGFwcA0Kc2VydmVycywgb3IgcHV0IG1vcmUgbWVtb3J5IG9uIHRoZSBEQiBzZXJ2ZXIuICBU
aGUgREIgc2VydmVyIGlzIGFscmVhZHkNCmNhY2hpbmcgYXMgbXVjaCBvZiB0aGUgdGFibGVzIGFu
ZCBpbmRpY2VzIGFzIHBvc3NpYmxlLCBzbyB0aHJvdWdocHV0DQpzaG91bGRuJ3QgYmUgYW4gaXNz
dWUgdW5sZXNzIHlvdSBnZXQgdG8gbWFzc2l2ZWx5IHNjYWxhYmxlIHN5c3RlbXMNCih3aGljaCBt
b3N0IHBlb3BsZSBkb24ndCBuZWVkKS4gIElmIHlvdSBkbyBuZWVkIHRoZSBtYXNzaXZlbHkgc2Nh
bGVkDQpzeXN0ZW0sIHJlZmVyIHRvIHBvaW50ICMxIGFib3V0IGhvdyBpbiB0aGUgaGVjayB5b3Ug
cGxhbiB0byBrZWVwIGRhdGENCmNhY2hlZCB3aGVuIHRoZSBkYXRhIGNoYW5nZXMgYW5kIHRoZXJl
IGFyZSBubyBtZWNoYW5pc21zIHRvIHJlZnJlc2ggdGhlDQpkYXRhIG90aGVyIHRoYW4gaGF2aW5n
IHRoZSBiZWFuIGNoZWNrIGVhY2ggdGltZS4NCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
IA0KCUZyb206IERleWFuIFBldHJvdiANCglTZW50OiBNb24gNy8yOS8yMDAyIDI6NDQgQU0gDQoJ
VG86IGFzcG5nYXJjaGl0ZWN0dXJlIA0KCUNjOiANCglTdWJqZWN0OiBbYXNwbmdhcmNoaXRlY3R1
cmVdIE1TIGhhdmUgbm8gbWFuYWdlZCBBcHBsaWNhdGlvbg0Kc2VydmVyPz8NCgkNCgkNCg0KCUhp
IGd1eXMsDQoJDQoJSSBoYXZlIGJlZW4gd29uZGVyaW5nIGZvciBhIGxvbmcgdGltZSBhYm91dCBz
b21ldGhpbmcgdmVyeQ0KaW1wb3J0YW50IC0gaG93DQoJY2FuIE1TIG9mZmVyIHRoZSAuTkVUIEZy
YW1ld29yayBmb3IgRW50ZXJwcmlzZSBkZXZlbG9wZW1lbnQsDQp3aGVuIHRoZXkgaGF2ZQ0KCW5v
IG1hbmFnZWQgYXBwbGljYXRpb24gc2VydmVyPyENCglJIGFtIHN1cmUgYXQgdGhpcyBwb2ludCBh
bGwgb2YgeW91IHdpbGwgc3RhcnQgc2F5aW5nIC0gaG93IHNvLA0KdGhlcmUgaXMgdGhlDQoJRW50
ZXJwcmlzZVNlcnZpY2VzIG5hbWVzcGFjZSwgYW5kIHRoZXJlIGlzIHRoZSAuTkVUIFNlcnZlcg0K
Y29taW5nLg0KCUhvd2V2ZXIgYm90aCBzdGF0ZW1lbnRzIGhhdmUgbm90aGluZyB0byBkbyB3aXRo
IGEgTUFOQUdFRCBBUFANClNlcnZlciwgd2hpY2gNCglzaG91bGQgYmUgcHJvdmlkZWQgZm9yIHNl
cmlvdXMgZW50ZXJwcmlzZSBkZXZlbG9wbWVudCBpbiAuTkVULg0KVGhlDQoJRW50ZXJwcmlzZVNl
cnZpY2VzIGluIC5ORVQgdXNlIHRoZSBvbGQgQ09NKyB0aHJvdWdoIENPTSBJbnRlcm9wDQooYmln
DQoJcGVyZm9ybWFuY2UgaXNzdWUpLCB3aGlsZSB0aGUgLk5FVCBTZXJ2ZXIgY29tZXMgd2l0aCBh
IG5ldw0KdmVyc2lvbiBvZiBDT00rLA0KCWJ1dCBzdGlsbCB1bm1hbmFnZWQuDQoJTW9yZW92ZXIs
IHNvbWUga2V5IGZlYXR1cmVzIGFyZSBzdGlsbCBtaXNzaW5nIGZyb20gQ09NKy4NCglIb3cgY2Fu
IC5ORVQgbWF0Y2ggdGhlbiB0aGUgSjJFRSwgd2hlcmUgYSBidW5jaCBvZiBhcHAgc2VydmVycw0K
YWxyZWFkeQ0KCWV4aXN0cz8/PyBIb3cgYXJlIHdlIHN1cHBvc2VkIHRvIGRldmVsb3Agc2NhbGFi
bGUgZGlzdHJpYnV0ZWQNCmFwcHMgaW4NCgkuTkVUPz8/IFVzaW5nIHRoZSBvbGQgYW5kIGluc3Vm
ZmljaWVudCBDT00rPz8gSSBhbSByZWFsbHkNCnRoaW5raW5nIG9mDQoJZGV2ZWxvcGluZyBhIGZy
YW1ld29yayBteXNlbGYsIHdoaWNoIHdpbGwgc3VwcGx5IHNvbWUgaW1wb3J0YW50DQpzZXJ2aWNl
cyB0bw0KCW15IGFwcGxpY2F0aW9uIC4uLiBCdXQgaXQncyBhIGxvdCBvZiBoYXJkIHdvcmssIHdo
aWNoIGlzIGFscmVhZHkNCmRvbmUgaW4gdGhlDQoJSjJFRSB3b3JsZC4gU28gdGhlcmUgYXJlICJt
YW5hZ2VkIiBKYXZhIGFwcCBzZXJ2ZXJzLCB3cml0dGVuIGluDQpKYXZhLA0KCXN1cHBseWluZyBh
IGxvdCBvZiBleHRyYSBmZWF0dXJlcyBsaWtlIFBlcnNpc3RlbmNlLCBDYWNoaW5nIG9mDQpkYXRh
IGV0YywgYW5kDQoJdGhlcmUgaXMgb25seSB0aGUgdW5tYW5hZ2VkIGdvb2Qgb2xkIENPTSs/DQoJ
DQoJUGxlYXNlIHRlbGwgbWUgd2hhdCB5b3UgdGhpbmsgYWJvdXQgdGhpcyBzZXJpb3VzIHByb2Js
ZW0hDQoJDQoJUmVnYXJkcywNCglEZXlhbiBQZXRyb3YNCgkNCgkNCgkNCgkNCgkNCgl8IFthc3Bu
Z2FyY2hpdGVjdHVyZV0gbWVtYmVyIHJ1c3MubWNjbGVsbGFuZEBzbWFydG9ianguY29tID0NCllP
VVIgSUQNCgl8IGh0dHA6Ly93d3cuYXNwbGlzdHMuY29tL2FzcGxpc3RzL2FzcG5nYXJjaGl0ZWN0
dXJlLmFzcCA9DQpKT0lOL1FVSVQNCgl8IGh0dHA6Ly93d3cuYXNwbGlzdHMuY29tL3NlYXJjaCA9
IFNFQVJDSCBBcmNoaXZlcw0KCQ0KCQ0KDQo
|
|
| |
|
| |
| Ben Hyrman |
I guess I haven't seen many deployments where an application had millions of
beans...much less needing all of those beans to be invalidated at the same
time. Nor have I seen many architectures where a call through a firewall to
a database and back has been faster than a local object call.
I definiately agree with you that most people don't need massively scalable
systems. Heck, most people could probably use Access for all of their needs.
However, many businesses, especially the larger enterprises that Microsoft
has started getting serious about targeting, appear to need scalable
systems. There's a reason that Windows 2000 Datacenter can scale to 32
processors, Cisco still insists on making load balancers, and companies like
Best Buy and Sony are deploying on ATG Dynamo.
As far as how do you keep things in sync...the more elegant solutions I have
seen allow for updates in two ways.
"Small" updates are made through an application API that will write to the
database and invalidate only the objects that need to be reloaded
"Large" updates are made directly against the database and then the
application API is called to invalidate the entire cache for that particular
object
Ben
----- Original Message -----
From: "Russ McClelland" <Click here to reveal e-mail address>
To: "aspngarchitecture" <Click here to reveal e-mail address>
Sent: Monday, July 29, 2002 5:22 PM
Subject: [aspngarchitecture] RE: MS have no managed Application server??
[Original message clipped]
----------------------------------------------------------------------------
----
[Original message clipped]
|
|
| |
|
| |
| Deyan Petrov |
Hi,
You guys must be definitely kidding. I was refering to building ENTERPRISE
DISTRIBUTED applications, and statements that "most" applications don't need
an app server are hilarious. I don't care about "applications" consisting of
1 winform, or apps written with the business logic in the sprocs in the
database etc. I am talking about apps which have a well defined object
design, consisting of encapsulated in classes business logic, which should
be very scalable.
Persistence in J2EE is not a joke. If you are really well acquainted with
the EJBs you will know that they try to hide the persistence stuff from the
programmer of business objects. So persistence/transaction/security etc.
logic is not sprinkled everywhere in your code, but is HIDDEN and applied
using interception, which leaves your business code clean and pure, i.e.
easy to maintain.
Data caching on the app server is a good thing. If you rely on your
database, then you'll end up unable to scale your application any more
sooner or later. The statements which are made in relation to this point
make me understand, that you really haven't programmed large enterprise
systems.
The functions of an app server are numerous and I don't want to go into
detail. Please reread my second email in this thread, where I specify my
concrete requirements, which are only a very small subset of an app server
functionality.
I am really sorry that so far I haven't heard the opinions of people who
have really dealt with problems specific to the distributed enterprise
application development. Once again I want to state, that the emphasis is
not so much on distributed, as I refer more to a logical distribution and a
physical one, although the latter should be possible. A framework should
make simple things simpler and complex things possible ...
Regards,
Deyan Petrov
"Russ McClelland" <Click here to reveal e-mail address> wrote in message
news:690643@aspngarchitecture...
[Original message clipped]
|
|
| |
|
| |
| Wolfgang Baeck |
Deyan,
I've been following this for a while and still don't have the time to devote
to it as much as it needs to so that you get an idea of where I'm coming
from. But, here is a short history.
I've, together with a team, designed and architected a large enterprise
system for mortgage and refinance applications for a large bank. The system
needed to get information from about 6 major data sources (FDR Omaha
Nebraska, Altell NJ, 4 internal database systems such as savings, checkings,
fraud, etc).
The system was designed fully OO and rule based, implemented in Smalltalk
and is in operation for 6 years now.
The data access was completely intercepted and hidden from the business
object developer, cached where necessary. It was an off the shelf first
class system that was originally developed commercially in Smalltalk is now
available for Java.
The database grew by about 2 GB per week, everything was versioned and we
had to be able to show data as it was on a certain date in the past due to
auditing reasons. No address of an individual, no information was ever
overwritten, we always had to create an new version of everything.
Impressions:
The hidden, automatic intercepted dealing with the data store was a pain. In
order to accomplish that, one has to have the "Schema" at least in two
places. First, in the data base, and second, in the data access components.
Since it was hidden, every newcomer to the project broke it in some fashion.
Either the new programmer did something to the business object that wasn't
represented in the db schema, or vice versa, or they did something to the BO
and the DB and forgot the "Hidden" layer.
The performance requirements where such that the hidden and caching layer
needed tons of help. We couldn't rely on it to suck certain information
asynchronously in because sometimes that was much to slow for the user who
had a customer on the phone and needed within 7 seconds to have basic
information from all systems up on his window. So we had to write special
stored procs that sucked in just text strings that got thrown onto the
window for immediate feedback while the system built the business objects in
a separate thread.
As a side note, we had our leading designers sit with the user through
customer service calls to see how their beloved system "sucked" from the
user's perspective because when you have a customer on the phone, seconds
count.
I could go on for a long time but I'm not sure what value it would provide
other than saying: I have worked on more than one LARGE ENTERPRISE system
with 300 to 3000 LAN and WAN users and have NEVER found the silver bullet.
All of them needed special treatment and I'm not sure that I keep on looking
for THE solution. I personally have gone from the business object extreme
with all data access hidden to the stateless object extreme just to see it
working.
So, while I agree that many things need to be done and in some respects the
advances of the hardware will make things possible in the future that are a
drag right now, I object to the tenor of your posts that seems to imply that
J2EE and EJB has all that that is missing everywhere else and seems to
belittle some of the people here who may have a bit less OO experience but
are nice to give it a try and post their understanding and experience.
With my many years of OO Experience in Smalltalk and Object Prolog were we
designed systems for IDS Financial (American Express), Fidelity of Boston,
USAA Federal Savings Bank, NationsBank now Wells Fargo that were the core
systems for their business, we wouldn't have touched Java to accomplish some
of the things that we did.
Wolfgang
-----Original Message-----
From: Deyan Petrov [mailto:Click here to reveal e-mail address]
Sent: Tuesday, July 30, 2002 1:42 AM
To: aspngarchitecture
Subject: [aspngarchitecture] Re: MS have no managed Application server??
Hi,
You guys must be definitely kidding. I was refering to building ENTERPRISE
DISTRIBUTED applications, and statements that "most" applications don't need
an app server are hilarious. I don't care about "applications" consisting of
1 winform, or apps written with the business logic in the sprocs in the
database etc. I am talking about apps which have a well defined object
design, consisting of encapsulated in classes business logic, which should
be very scalable.
Persistence in J2EE is not a joke. If you are really well acquainted with
the EJBs you will know that they try to hide the persistence stuff from the
programmer of business objects. So persistence/transaction/security etc.
logic is not sprinkled everywhere in your code, but is HIDDEN and applied
using interception, which leaves your business code clean and pure, i.e.
easy to maintain.
Data caching on the app server is a good thing. If you rely on your
database, then you'll end up unable to scale your application any more
sooner or later. The statements which are made in relation to this point
make me understand, that you really haven't programmed large enterprise
systems.
The functions of an app server are numerous and I don't want to go into
detail. Please reread my second email in this thread, where I specify my
concrete requirements, which are only a very small subset of an app server
functionality.
I am really sorry that so far I haven't heard the opinions of people who
have really dealt with problems specific to the distributed enterprise
application development. Once again I want to state, that the emphasis is
not so much on distributed, as I refer more to a logical distribution and a
physical one, although the latter should be possible. A framework should
make simple things simpler and complex things possible ...
Regards,
Deyan Petrov
"Russ McClelland" <Click here to reveal e-mail address> wrote in message
news:690643@aspngarchitecture...
[Original message clipped]
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Mark Feinholz |
On the topics of data/object state caching and scalability...
Web Application: I've always had a very hard time coming up with a
scenario where a physically separated application layer makes any sense.
Does anyone have an example of a system that is designed with the
application layer physically separated from the web server - and why
they architected it that way? When it comes time to scale it always
seems to make sense to just add more servers to the web farm. There are
application processes I suppose though that are better suited to be
shipped off to a farm of application servers that are configured to meet
the specific processing needs of the application better. But if adding
a new server to the web farm is the scaling solution, then it seems that
Asp.Net's caching functionality takes care of the caching needs. It is
certainly not automatic though - you need to design your system around
this approach - including coming up with a way to invalidate the cache
when "mostly static" info in the db is changed.
WinForm applications: It is much easier for me to come up with
scenarios where application servers - separated from the client machine
would be useful. It seems that the .Net answer to this is remoting -
and I agree that the lack of an application server to help out here
seems like a missing piece of the architecture. I have to build my own
multi-threaded server to host the remote process? And where is the
caching? It doesn't feel right (at least not yet - maybe I just need
time to be convinced) for a web server to be the answer to this need.
On the topic of distributed transactions:
I am very concerned that this is not available without resorting to
com+. I keep hearing comments like: "no one hardly ever needs
distributed transactions". I consistently architect applications that
talk to 2 or more databases - purposely separating some tables in the db
to a separate db. For example I just built a report archiving component
that pounds gigs upon gigs of report images out to a sql server db - a
separate db from the apps main db because it has different back up
needs, can be put on a separate server to not overburden the transaction
oriented primary db, etc. I'm amazed that MS didn't implement cross db
transactions in .Net - at least for 2 or more SQL Servers right away.
If a stored proc can do it via a linked server, why can't ADO.Net do it?
Mark.
-----Original Message-----
From: Deyan Petrov [mailto:Click here to reveal e-mail address]
Sent: Tuesday, July 30, 2002 12:42 AM
To: aspngarchitecture
Subject: [aspngarchitecture] Re: MS have no managed Application server??
Hi,
You guys must be definitely kidding. I was refering to building
ENTERPRISE
DISTRIBUTED applications, and statements that "most" applications don't
need
an app server are hilarious. I don't care about "applications"
consisting of
1 winform, or apps written with the business logic in the sprocs in the
database etc. I am talking about apps which have a well defined object
design, consisting of encapsulated in classes business logic, which
should
be very scalable.
Persistence in J2EE is not a joke. If you are really well acquainted
with
the EJBs you will know that they try to hide the persistence stuff from
the
programmer of business objects. So persistence/transaction/security etc.
logic is not sprinkled everywhere in your code, but is HIDDEN and
applied
using interception, which leaves your business code clean and pure, i.e.
easy to maintain.
Data caching on the app server is a good thing. If you rely on your
database, then you'll end up unable to scale your application any more
sooner or later. The statements which are made in relation to this point
make me understand, that you really haven't programmed large enterprise
systems.
The functions of an app server are numerous and I don't want to go into
detail. Please reread my second email in this thread, where I specify my
concrete requirements, which are only a very small subset of an app
server
functionality.
I am really sorry that so far I haven't heard the opinions of people who
have really dealt with problems specific to the distributed enterprise
application development. Once again I want to state, that the emphasis
is
not so much on distributed, as I refer more to a logical distribution
and a
physical one, although the latter should be possible. A framework should
make simple things simpler and complex things possible ...
Regards,
Deyan Petrov
"Russ McClelland" <Click here to reveal e-mail address> wrote in message
news:690643@aspngarchitecture...
[Original message clipped]
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Ben Hyrman |
Tell us what you're after Deyan,
You posted asking about building enterprise systems with .NET, and talked a
bit about COM+. You got plenty of replies talking about the issues with the
current solution from Microsoft. If you're looking for a .NET managed app
server, then I think the answer is that there isn't one, at least from
Microsoft, at this point. If you're looking for enterprise development
frameworks in .NET, I'm not aware of any robust frameworks in mass use at
this point. If you're asking people on this list about building these
frameworks, I think you can tell by the lack of replies that those people
are too busy building the frameworks to bother writing about them at this
point ;-)
So, before belittling the subset of people that are trying to help out, or
at least willing to reply to your posts, maybe tell us exactly what it is
you're looking for.
I can't personally speak to "ENTERPRISE DISTRIBUTED applications" with
regards to .NET as my company has not started any .NET development. When we
do, I can assure you that enterprise solutions will not be our first focus
;-) Currently, we utilize a few specialized frameworks that have a focused
solution for a specific domain. These frameworks reside on top of a J2EE app
server. Lighter load apps do not take advantage of the framework and simply
use the J2EE app server.
I agree with you completely, a framework should make simple things simpler
and complex things possible. However, I suppose we might differ here. I
think that the .NET 1.0 framework has done exactly this. All I feel that is
missing is a solid application server to extend the usefulness of the
existing framework. While no one who can speak without breaking an NDA knows
the hand of Microsoft, I'm guessing you'll see the full featureset you're
looking for fairly soon. You seem to forget that J2EE wasn't released until
1999, 3 years after JDK 1.0 was available for download.
If you're upset that Microsoft named a product "Visual Studio Enterprise
Developer", well, consider it a naming scheme that paves the way for future
products.
Regards,
Ben
----- Original Message -----
From: "Deyan Petrov" <Click here to reveal e-mail address>
Newsgroups: aspngarchitecture
To: "aspngarchitecture" <Click here to reveal e-mail address>
Sent: Tuesday, July 30, 2002 2:41 AM
Subject: [aspngarchitecture] Re: MS have no managed Application server??
[Original message clipped]
|
|
| |
|
| |
| Jonathan Green |
I have a problem not seeing Deyan as a Java troll, personally.
I really don't see the difficulty here, regarding Enterprise
development, and I think we put the cart before the horse by forgetting
that what makes Enterprise systems fly is proper Architecture, much more
than which Framework used.
Put me down on the side that sees no merit in a physically separate
Application Server. I believe that Business Logic performs best as
storedprocs on the data layer, not residing on some app server. Towards
that end, I think that .NET does wonders with the new DataSet paradigm
compared to the old ADO.
I get a little sick of all these Framework wars, where we seem to forget
that whether J2EE or .NET, they are TOOLS, not SOLUTIONS. I see any area
where either falls short, as an opportunity to use a little creativity
and imagination, instead of so much whining about what isn't getting
solved for me right out of the box.
I think a framework should make cool things possible. Whether it makes
things easier or not depends on how prepared we are for the strengths or
weaknesses of the platform we choose. I don't think there are too many
things impossible on either platform, personally.
Maybe instead of focusing so much on what's missing in the available
frameworks, we might consider what is lacking in our own skill and
imagination?
</rant>
Jonathan
-----Original Message-----
From: Ben Hyrman [mailto:Click here to reveal e-mail address]
Sent: Tuesday, July 30, 2002 2:40 PM
To: aspngarchitecture
Subject: [aspngarchitecture] Re: MS have no managed Application server??
Tell us what you're after Deyan,
You posted asking about building enterprise systems with .NET, and
talked a
bit about COM+. You got plenty of replies talking about the issues with
the
current solution from Microsoft. If you're looking for a .NET managed
app
server, then I think the answer is that there isn't one, at least from
Microsoft, at this point. If you're looking for enterprise development
frameworks in .NET, I'm not aware of any robust frameworks in mass use
at
this point. If you're asking people on this list about building these
frameworks, I think you can tell by the lack of replies that those
people
are too busy building the frameworks to bother writing about them at
this
point ;-)
So, before belittling the subset of people that are trying to help out,
or
at least willing to reply to your posts, maybe tell us exactly what it
is
you're looking for.
I can't personally speak to "ENTERPRISE DISTRIBUTED applications" with
regards to .NET as my company has not started any .NET development. When
we
do, I can assure you that enterprise solutions will not be our first
focus
;-) Currently, we utilize a few specialized frameworks that have a
focused
solution for a specific domain. These frameworks reside on top of a J2EE
app
server. Lighter load apps do not take advantage of the framework and
simply
use the J2EE app server.
I agree with you completely, a framework should make simple things
simpler
and complex things possible. However, I suppose we might differ here. I
think that the .NET 1.0 framework has done exactly this. All I feel that
is
missing is a solid application server to extend the usefulness of the
existing framework. While no one who can speak without breaking an NDA
knows
the hand of Microsoft, I'm guessing you'll see the full featureset
you're
looking for fairly soon. You seem to forget that J2EE wasn't released
until
1999, 3 years after JDK 1.0 was available for download.
If you're upset that Microsoft named a product "Visual Studio Enterprise
Developer", well, consider it a naming scheme that paves the way for
future
products.
Regards,
Ben
----- Original Message -----
From: "Deyan Petrov" <Click here to reveal e-mail address>
Newsgroups: aspngarchitecture
To: "aspngarchitecture" <Click here to reveal e-mail address>
Sent: Tuesday, July 30, 2002 2:41 AM
Subject: [aspngarchitecture] Re: MS have no managed Application server??
> I am really sorry that so far I haven't heard the opinions of people
who
[Original message clipped]
a
> physical one, although the latter should be possible. A framework
should
[Original message clipped]
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Damon Allison |
[Original message clipped]
I work with an insurance company right now and we are rolling out an
application layer to be accessed via remoting. The middle tier is
responsible for retrieving data (via ODBC) from an AS400 and retrieving text
files from the filesystem to display online.
The reason we designed this as an application server piece is because the
DMZ where are web servers are stored does not have permissions to read the
internal network's filesystem, nor do we want to open up a link between our
DMZ and AS400 systems. For us, physical separation made sense for security
reasons.
Damon
|
|
| |
|
| |
| Mitch Denny |
Mark,
I tend to agree with you regarding physical partitioning, although
it has been made abundantly clear to me on more than one occasion
that physical seperation increases the perception of tighter
security. Whether the slight security enhancement is worth the
perf hit will be debated through the ages.
Sometimes physical application partitioning is dictated by
security teams. Recently I was in a meeting with the security
manager though and he told me that he was more concerned about
the crypto applied to inter node communications in the
distributed application that I was working on. This was at
one of Australia's major financial institutions.
Microsoft still may do something in the distributed database
transaction space. The architecture of ADO.NET doesn't rule
it out below the DataAdapter line.
When most people talk about little need for distributed
transactions (or rather a unified approach to it), is because
most people understand that ultimately the data needs to be
persisted to a database or some form of message queue.
----------------------------------------
- Mitch Denny
- Technical Specialist
- Click here to reveal e-mail address
- http://www.monash.net
- +61 (414) 610-141
-
-----Original Message-----
From: Mark Feinholz [mailto:Click here to reveal e-mail address]
Sent: Wednesday, 31 July 2002 3:13 AM
To: aspngarchitecture
Subject: [aspngarchitecture] Re: MS have no managed Application server??
On the topics of data/object state caching and scalability...
Web Application: I've always had a very hard time coming up with a
scenario where a physically separated application layer makes any sense.
Does anyone have an example of a system that is designed with the
application layer physically separated from the web server - and why
they architected it that way? When it comes time to scale it always
seems to make sense to just add more servers to the web farm. There are
application processes I suppose though that are better suited to be
shipped off to a farm of application servers that are configured to meet
the specific processing needs of the application better. But if adding
a new server to the web farm is the scaling solution, then it seems that
Asp.Net's caching functionality takes care of the caching needs. It is
certainly not automatic though - you need to design your system around
this approach - including coming up with a way to invalidate the cache
when "mostly static" info in the db is changed.
WinForm applications: It is much easier for me to come up with
scenarios where application servers - separated from the client machine
would be useful. It seems that the .Net answer to this is remoting -
and I agree that the lack of an application server to help out here
seems like a missing piece of the architecture. I have to build my own
multi-threaded server to host the remote process? And where is the
caching? It doesn't feel right (at least not yet - maybe I just need
time to be convinced) for a web server to be the answer to this need.
On the topic of distributed transactions:
I am very concerned that this is not available without resorting to
com+. I keep hearing comments like: "no one hardly ever needs
distributed transactions". I consistently architect applications that
talk to 2 or more databases - purposely separating some tables in the db
to a separate db. For example I just built a report archiving component
that pounds gigs upon gigs of report images out to a sql server db - a
separate db from the apps main db because it has different back up
needs, can be put on a separate server to not overburden the transaction
oriented primary db, etc. I'm amazed that MS didn't implement cross db
transactions in .Net - at least for 2 or more SQL Servers right away. If
a stored proc can do it via a linked server, why can't ADO.Net do it?
Mark.
-----Original Message-----
From: Deyan Petrov [mailto:Click here to reveal e-mail address]
Sent: Tuesday, July 30, 2002 12:42 AM
To: aspngarchitecture
Subject: [aspngarchitecture] Re: MS have no managed Application server??
Hi,
You guys must be definitely kidding. I was refering to building
ENTERPRISE DISTRIBUTED applications, and statements that "most"
applications don't need an app server are hilarious. I don't care about
"applications" consisting of 1 winform, or apps written with the
business logic in the sprocs in the database etc. I am talking about
apps which have a well defined object design, consisting of encapsulated
in classes business logic, which should be very scalable.
Persistence in J2EE is not a joke. If you are really well acquainted
with the EJBs you will know that they try to hide the persistence stuff
from the programmer of business objects. So
persistence/transaction/security etc. logic is not sprinkled everywhere
in your code, but is HIDDEN and applied using interception, which leaves
your business code clean and pure, i.e. easy to maintain.
Data caching on the app server is a good thing. If you rely on your
database, then you'll end up unable to scale your application any more
sooner or later. The statements which are made in relation to this point
make me understand, that you really haven't programmed large enterprise
systems.
The functions of an app server are numerous and I don't want to go into
detail. Please reread my second email in this thread, where I specify my
concrete requirements, which are only a very small subset of an app
server functionality.
I am really sorry that so far I haven't heard the opinions of people who
have really dealt with problems specific to the distributed enterprise
application development. Once again I want to state, that the emphasis
is not so much on distributed, as I refer more to a logical distribution
and a physical one, although the latter should be possible. A framework
should make simple things simpler and complex things possible ...
Regards,
Deyan Petrov
"Russ McClelland" <Click here to reveal e-mail address> wrote in message
news:690643@aspngarchitecture...
[Original message clipped]
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Mitch Denny |
Deyan,
DP> The statements which are made in relation to this point make me
DP> understand, that you really haven't programmed large enterprise
DP> systems.
Sounds like a pretty big assumption, and somewhat insulting. Anyway,
lets proceed with the discussion. Can you give us some metrics on the
sort of load that you application is required to handle?
Nothing that has been said about application architecture thus far
has indicated to me that it will perform less admirably than in a
theorhetical managed application server. Try grading the archtiecture
on the following grounds:
Security
Maintainability
Useability
Scalability
Performance
Managability
Extensibility
Reliability
(no particular order)
In fact it would be interesting to see how you graded the above
priority wise given your current requirements.
----------------------------------------
- Mitch Denny
- Technical Specialist
- Click here to reveal e-mail address
- http://www.monash.net
- +61 (414) 610-141
-
-----Original Message-----
From: Deyan Petrov [mailto:Click here to reveal e-mail address]
Sent: Tuesday, 30 July 2002 5:42 PM
To: aspngarchitecture
Subject: [aspngarchitecture] Re: MS have no managed Application server??
Hi,
You guys must be definitely kidding. I was refering to building
ENTERPRISE
DISTRIBUTED applications, and statements that "most" applications don't
need
an app server are hilarious. I don't care about "applications"
consisting of
1 winform, or apps written with the business logic in the sprocs in the
database etc. I am talking about apps which have a well defined object
design, consisting of encapsulated in classes business logic, which
should
be very scalable.
Persistence in J2EE is not a joke. If you are really well acquainted
with
the EJBs you will know that they try to hide the persistence stuff from
the
programmer of business objects. So persistence/transaction/security etc.
logic is not sprinkled everywhere in your code, but is HIDDEN and
applied
using interception, which leaves your business code clean and pure, i.e.
easy to maintain.
Data caching on the app server is a good thing. If you rely on your
database, then you'll end up unable to scale your application any more
sooner or later. The statements which are made in relation to this point
make me understand, that you really haven't programmed large enterprise
systems.
The functions of an app server are numerous and I don't want to go into
detail. Please reread my second email in this thread, where I specify my
concrete requirements, which are only a very small subset of an app
server
functionality.
I am really sorry that so far I haven't heard the opinions of people who
have really dealt with problems specific to the distributed enterprise
application development. Once again I want to state, that the emphasis
is
not so much on distributed, as I refer more to a logical distribution
and a
physical one, although the latter should be possible. A framework should
make simple things simpler and complex things possible ...
Regards,
Deyan Petrov
"Russ McClelland" <Click here to reveal e-mail address> wrote in message
news:690643@aspngarchitecture...
[Original message clipped]
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Mitch Denny |
Deyan,
DP> I need a managed app server, or just a framework of services,
DP> which will allow me to:
Excellent! Here we are making progress, you have identified
that an app server is just some services.
DP> 1) concentrate on the pure business logic
Its generally not wise to possible implications on a system
level when implementing business logic, and while it is nice
to abstract away as much of the plumbing as possible the
current state of technology dictates that we deal with our
supporting infrastructure at some point. My point? At some
point you are going to have to deal with technology.
DP> 2) transparent transaction handling, security, logging using
DP> the concept of Interception
This is what COM+ provides at a cost, anything you do here
will likely involve a performance hit of some kind. Depending
on the true nature of your problem you might be able to design
around this. Most of the time we are after short-lived transactions
on the database or some kind of a message queue, so why not
talk to those services directly? For longer running transactions
you generally have to look at some kind of work-flow enabled tool.
Assuming I haven't been living in a parallel universe for
the last twelve months, in most cases you can avail yourself
of system services such as Event Logging, either wired up
through tracing functionality (nice) or directly.
Look, its not all there yet the way you want it, but its
coming and realistic and architecturally sound alternatives
exist today which you can implement. Remember that there
is not a 1 to 1 mapping between J2EE and .NET.
DP> 3) other scalability/failover services, which at this point
DP> are not so important to me, as I can load balance the
DP> interface entry points (the web servers).
You can load balance with remoting using NLB, binary formatters
over a TCP channel. No worries.
DP> 4) persistence management - some form of ORM.
Still need some convincing that this is a good idea, there
are certainly instances where it is useful but once you get
over a certain scale concurrency and other tuning issues
make it so that it is not feasible. Its much easier to scale
with a database upgrade and putting a few more app blades
in a rack then managing ORM persistence issues.
If you still want it then it might be worth looking into
the ObjectSpaces project that Microsoft was working on, I'm
not sure what stage they are at, the last I heard was that
they had taken the work back in house and were working on
a polished product. If you search the newsgroups and the
archives here at ASPFriends you will probably find some
references to other efforts that people have made in
this space. The problem you are likely to find is that
many people abandon this sort of work because of the hard
to solve scalability issues.
Alot of people that I talk to are actually working
with DataSets for relational data and they find that
in most cases they do the job very nicely. If you have
business rules then you can configure the business
rules to work with DataRows representing the business
entities, its a very .NET design :)
This gives you the added benefit that DataSets and
DataTables are very easy to persist to the database
and they are already in a disconnected model.
DP> 5) transparently distribute even physically my components (for
DP> example I want all the payments to be directed to 2 payment
DP> servers in my web farm using remoting). I will have the
DP> presentation and business logic on the same physical machine,
DP> because I fully agree that the cost of marshalling/unmarshalling
DP> is too big.
This is a requirements decision, but .NET out of the box will
support both approaches very well. Just configure your remoting
servers behind a NLB setup and away you go. For many expensive
operations it can be cheaper to push them to a backend server
to avoid the processing impacting concurrent requests on the
front end presentation and app servers.
I hope I answered your questions. Let me know if you strike
a business requirement that you can't map to .NET technology.
----------------------------------------
- Mitch Denny
- Technical Specialist
- Click here to reveal e-mail address
- http://www.monash.net
- +61 (414) 610-141
-
-----Original Message-----
From: Deyan Petrov [mailto:Click here to reveal e-mail address]
Sent: Monday, 29 July 2002 10:16 PM
To: aspngarchitecture
Subject: [aspngarchitecture] Re: MS have no managed Application server??
Hi Mitch,
10x for your reply. I like your overview of the general problem, but the
specific problems are more important ;)
The situation now is:
If I want to build an enterprise distributed application I don't have an
appropriate application server to use.
COM+ used in .NET has a number of problems:
1) It requires COM Interop Services to be used, which impedes heavily
the performance.
2) It's an old technology, which has some problems - it allows
transaction attributes only at the class level (not at the method
level), in the .NET Server it will allow to specify isolation level, but
now it doesn't. Also the role-based security means that I have to
hardcode the roles in my app, which I don't want, I want to be able to
configure the access permissions of the roles from the client.
3) It is not easy enough to register your managed components with it.
I need a managed app server, or just a framework of services, which will
allow me to:
1) concentrate on the pure business logic
2) transparent transaction handling, security, logging using the concept
of Interception
3) other scalability/failover services, which at this point are not so
important to me, as I can load balance the interface entry points (the
web servers).
4) persistence management - some form of ORM.
5) transparently distribute even physically my components (for example I
want all the payments to be directed to 2 payment servers in my web farm
using remoting). I will have the presentation and business logic on the
same physical machine, because I fully agree that the cost of
marshalling/unmarshalling is too big.
I intend to use the Facade design pattern, ContextBoundObjects for my
Facade classes with interception, which will add message sinks which
will handle transparently the transaction handling, security and
logging. It's too much work, though. Also I still am not sure what's the
best approach to persistence of my business objects ....
Regards,
Deyan Petrov
"Mitch Denny" <Click here to reveal e-mail address> wrote in message
news:690159@aspngarchitecture...
[Original message clipped]
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Mitch Denny |
Damon,
Absolutely! Everything can be improved, but it definately can't
be characterised as a show stopper. The point I was trying make
was it depends on what is more important to you. Staying clear
of COM+ or getting declaritive/distributed transactions for free.
Remoting and Security:
Are you having trouble passing the principal in a remoting
channel? Have you looked at ILogicalThreadAffinative as a
mechanism for doing that. One point that was raised in a mailing
list post somewhere was that .NET Security is independent of
Windows Security which is nice considering the cross platform
implications of that design decision.
Remoting and Threading:
Anyway, look at the above interface as a way of getting around
those sorts of issues. As for handling multiple requests simultaneously,
as I understand it, threads for remoting requests are allocated
from the threadpool which means requests at peak times are queued
up, why is this not sufficient? How many concurrent requests are you
sending through and in what time frame do they need to be responded
to, how long does the average request take?
Windows Service Hosting:
It pretty much is a matter of calling ServiceBase.Run(...) with
the exception of the issues above. In fact you could probably
template the code. I'm assuming that you have done a bit of J2EE
programming before and can appreciate that sometimes deploying
an EJB can become quite involved and quite complex. I think that
the .NET solution is quite elegant myself.
Candidate for an App Server:
For sure! But its not necessary, I'm sorry, but its not, people
were able to build extremely scalable solutions before applications
servers (as we know them today), in many cases they simply out
perform our current technology set still!
I'm not going to say no to an application server where I can just
drop an assembly into and walk away, but programmers still need
to be programmers and understand the technology platform that
they are working with. Occasionally that means doing something
slightly technical as well.
Anyway, I hope that you can use the existing technology
offering to get the job done and hope that when Microsoft
and other vendors come to market with .NET app servers that
it is everything that you hoped for.
----------------------------------------
- Mitch Denny
- Technical Specialist
- Click here to reveal e-mail address
- http://www.monash.net
- +61 (414) 610-141
-
-----Original Message-----
From: Damon Allison [mailto:Click here to reveal e-mail address]
Sent: Monday, 29 July 2002 10:13 PM
To: aspngarchitecture
Subject: [aspngarchitecture] RE: MS have no managed Application server??
[Original message clipped]
You're joking, right? While it is possible to use COM+ services, there
is much room for improvement. I'll give you one concrete example.
I am in the process of making an object available via remoting, so I
create a remoting host (like the service approach you suggest).
Unfortunately there is more to hosting a remoting object than saying
"Service.Run". For starters, I want to incorporate Windows security.
Second, I want the host to be multi-threaded to handle multiple requests
simultaneously.
I've been told to host my remoting objects in IIS, which provides both
security and performance improvements. Again, this is a joke, right?
Try telling the network team we want IIS on a middle tier machine.
Thier
response: no way, we don't want the potential security breaches nor do
we want to patch another IIS server with the rest of our IIS boxes. IIS
is not meant to host middle tier components, its meant to host web
sites. Using IIS in the middle tier is overkill.
Lets also assume that we create another remoting host without using IIS.
We end up either rewriting much of the same functionality or enhancing
our current remoting host to host multiple objects simultaneously. What
we end up doing is creating our own application server. Every company
(like
Deyan's) that deploys remoting will be creating their own hosts with
common functionality, a definite candidate for a 'server' solution
product. Our company doesn't have the time nor the resources to create
our own application server.
I would like to see an "Application Center" like managed application
server from MS in the next year to not only host remoting objects, but
provide the other concerns Deyan proposed such as managed transactions,
etc.
Damon
----- Original Message -----
From: "Mitch Denny" <Click here to reveal e-mail address>
To: "aspngarchitecture" <Click here to reveal e-mail address>
Sent: Monday, July 29, 2002 5:54 AM
Subject: [aspngarchitecture] RE: MS have no managed Application server??
[Original message clipped]
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Mitch Denny |
Ben,
The reaction to IIS is typical at the moment, perhaps with IIS 6.0
around the corner Microsoft can win back some faith, perhaps, perhaps
not. I generally think of applications as free standing entities
isolated from the rest of the network by firewalls with fairly strick
rules, sometimes even stateful inspect of of packets via hardware
devices.
In a web-services architecture IIS plays an interesting role because
it is certainly one of the easiest ways to deploy a web-service. Using
an arrangement of IIS servers can result in an extremely loosely
coupled design. Whether it is practical depends on your requirements.
----------------------------------------
- Mitch Denny
- Technical Specialist
- Click here to reveal e-mail address
- http://www.monash.net
- +61 (414) 610-141
-
-----Original Message-----
From: Ben Hyrman [mailto:Click here to reveal e-mail address]
Sent: Tuesday, 30 July 2002 1:51 AM
To: aspngarchitecture
Subject: [aspngarchitecture] Re: MS have no managed Application server??
In the respect that it is a full web server. It is also a full web
server that sees a fair number of security bulletins. At least here, the
IIS boxes go in the dirty trunks of the network. I would be beaten
rather severely if I asked for IIS on an app server.
I see this as a temporary hack to get us through until a solid solution
is delivered. A web server that is tuned for I/O and stateless requests
should not be forced to play the part of remoting server.
---------- Original Message ----------------------------------
From: Brian Espey <Click here to reveal e-mail address>
Reply-To: "aspngarchitecture" <Click here to reveal e-mail address>
Date: Mon, 29 Jul 2002 08:07:13 -0700 (PDT)
[Original message clipped]
| [aspngarchitecture] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Russ McClelland |
What difference does it make if you go from:=20
1. server1 with a web server/app server combination to server2 with a
DB server
2. server1 with web to server2 with app server to server3 with DB
server
You still have to have a port open between a DMZ server and your DB
server. If someone hacks your web server to access your 400 as in
solution 1, its not much different than if they hack the app server in
solution 2...
-----Original Message-----
From: Damon Allison [mailto:Click here to reveal e-mail address]=20
Sent: Tuesday, July 30, 2002 8:53 PM
To: aspngarchitecture
Subject: [aspngarchitecture] Re: MS have no managed Application server??
[Original message clipped]
I work with an insurance company right now and we are rolling out an
application layer to be accessed via remoting. The middle tier is
responsible for retrieving data (via ODBC) from an AS400 and retrieving
text files from the filesystem to display online.
The reason we designed this as an application server piece is because
the DMZ where are web servers are stored does not have permissions to
read the internal network's filesystem, nor do we want to open up a link
between our DMZ and AS400 systems. For us, physical separation made
sense for security reasons.
Damon
| [aspngarchitecture] member Click here to reveal e-mail address =3D YOUR ID=20
| http://www.asplists.com/asplists/aspngarchitecture.asp =3D JOIN/QUIT=20
| http://www.asplists.com/search =3D SEARCH Archives
|
|
| |
|
| |
| Ben Hyrman |
If I were a betting man, well, I'd be broke by now. But that's beside the
point. Looking at Microsoft's track record, I can foresee something just
after IIS 6.0 that starts to take on a more "enterprise" role. I'm not sure
what enterprise is, but it's certainly more than just a web server.
I think we're getting there, just not quite yet. I have read many articles
that the app tier is dead and no longer needed with .net. I disagree, I
don't think the app tier is dead. I think the app tier will become IIS with
a few more additions...maybe IIS+? The app tier then becomes a logical
combination with the presentation tier. For companies that demand it, the
two are simply deployed on separate physical boxes.
Damon pointed out to me that, many years ago, Sun said that the network was
the computer. Microsoft resisted, for a long time. Microsoft came back in
spades. We have SOAP (yes, I know they didn't create the standard, but damn
did they back it). We have web services. We have what seems to be an
adequate solution for many scenarios. All we need now is a standard for web
services to be able to participate in an XA transaction and we're done.
I'm not sure what environments will look like in a few years. The bulk of
web services, at least for internal applications, still seem to be a good
amount of hype. From an application to application perspective, I am getting
fewer features than I could have had with Corba. However, industry momentum
and even the lightweightness of web services are leading towards rapid
adoption.
I'm working as the integration architect on a "large" project right now.
Even for our integration needs between Java applications, , we're finding
XML calls over HTTP from a Java client to a servlet to be preferrable even
to RMI or RMI/IIOP integration. The impact is lighter, I can secure things
with SSL on the server and SSL certs on the client, and it fits well with
our existing firewall policies.
I foresee IIS moving to offer more of this same type of integration in a
GUIed environment. After all, it's not Microsoft until I have a wizard to
walk me through set up. In summary (not that you really can summarize a
ramble like that), IIS will become more of an app server. I would bet on
ISV's and other third-party vendors to be first to market with frameworks to
support a more enterprise scope, and Microsoft to start folding parts of
these frameworks into their app server services....and you'll need to use
Passport for all of it!
Ben
----- Original Message -----
From: "Mitch Denny" <Click here to reveal e-mail address>
To: "aspngarchitecture" <Click here to reveal e-mail address>
Sent: Tuesday, July 30, 2002 7:06 PM
Subject: [aspngarchitecture] Re: MS have no managed Application server??
[Original message clipped]
|
|
| |
|
| |
| Deyan Petrov |
Hi Ben,
I want to apologise to all of you, who feel offended by my last post. What I
wanted to do was merely to provoke you and get response on the problems
which I am dealing with currently (with 12 new posts over the night I might
have succeeded ;).
For 2 years now I have been delving in the .NET Framework (since Beta 1). I
am not a Java troll (like Luke, asj, Cameron Purdy etc ;). I am too
technically oriented to be a such, however for the last several months I
have been reading the java specs/books/blueprints etc., so that I know where
the competition is ... The company I am currently working for has started to
wonder what platform to use for the next version of its software - J2EE or
.NET.
What I am after? Well, my ultimate goal is to make you, guys, share with me
your ideas about an application framework in .NET. I want to know exactly
how you (plan to) write your transaction/security/logging and most
importantly persistence code.
One way is to make several classes with static methods and call them in all
your business methods. This will result however in sprinkled service code
all over your business logic.
Another way is to hide this service layer and keep it away from your
business logic as much as possible. This is the pattern used in Java app
servers, as well as COM+. I like this approach.
SO ...
Please, guys, write about your "best" way of writing apps in .NET ... way,
framework, app server, all of these sound interchangeable to me ... I am
talking about these four services - how will you incorporate them in your
.NET app:
1) transactions, spanning several business methods of several classes. It
should be possible that the business methods can be executed in different
order and still take advantage of transactions, without explicitely coding
to a connection etc (as it's in COM+). As you know, these are the so-called
declarative transactions. I don't want them necessarily distributed ;), but
they should be able to span several databases ;)
2) Security - I want to secure my business components, so that they can be
called only by authorized users. I will use my custom security, where each
action will be made available to different roles, in which different users
are involved.
3) Logging - I want to log the users actions in a table in the DB or
somewhere else.
4) Persistence - I want to find the best approach here. I can write the
persistence logic in the business classes themselves, I can delegate it to
persistence classes, called from the business classes or I can externalize
it, so that the business classes know nothing about it. I am familiar with
the approach used in ObjectSpaces and CMP 2.0, where the properties, which
should be persisted are made abstract, and then at run time (objectspaces)
or when deployed (J2ee app servers) another class is generated, inheriting
from the business class and providing implementation (persistence) of the
abstract properties according to some form of persistence descriptor.
I hope that I receive a lot of comments on the above technical points,
Thanks in advance,
Deyan Petrov
"Ben Hyrman" <Click here to reveal e-mail address> wrote in message
news:691275@aspngarchitecture...
[Original message clipped]
|
|
| |
|
| |
| Deyan Petrov |
Hi Jonathan,
Well, I am NOT a Java troll ;) Unlike luke, asj etc. in the
microsoft.public.dotnet.* newsgroups I don't quote news articles all the
time and compare job results ;))) I apologize for offending you (if I have),
I only wanted to provoke the newslist ;)
For the last 2 years I've been playing with the .NET Framework, and for the
last several months with J2EE in parallel.
If I mention J2EE, it's only from a technical point of view, where I want to
illustrate some of my points with ready examples. I am sure you'll agree
with me, that there are some nice features in J2EE, as well as in .NET, so I
want to combine them somehow ;)
So you have experience with both extremes - with a too OO enterprise
architecture and with a completely stateless one. So pls share your insights
on the problems of transactions/security/logging/persistence, which I point
out, in greater detail.
10x in advance,
Deyan Petrov
"Jonathan Green" <Click here to reveal e-mail address> wrote in message
news:691325@aspngarchitecture...
[Original message clipped]
|
|
| |
|
| |
| Deyan Petrov |
Hi Mitch,
I can't really grade those grounds ... I doubt if anyone can do that
precisely. I think that all of us want all of them ;) Without performance
and scalability, of course reliability you are dead, your clients will kill
you ;) Without maintainability, extensibility, managability whatever, you
are again dead, because you will not be able to easily (without month long
development efforts per new feature) extend/maintain your app later...
I target the load of "my" application to be 1000 concurrent users.
Regards,
Deyan Petrov
"Mitch Denny" <Click here to reveal e-mail address> wrote in message
news:691328@aspngarchitecture...
[Original message clipped]
|
|
| |
|
| |
| Deyan Petrov |
Hi Mitch,
What is the balance, Mitch, between incorporating all the services
(transactions/security/logging/persistence) in yout business classes and
externalizing them completely?
As for ObjectSpaces, I have spent some time reading the
microsoft.public.objectspaces newsgroup, as well read some stuff on EJB CMP
2.0 ... I am aware of the approach they both are using, in slightly
different ways, of course.
DataSets etc are good things, if you use them appropriately, and not basing
all your design on them, to server as business classes etc., in my opinion,
So I rule them out of the discussion about the class design of a big
application ...
Regards,
Deyan Petrov
"Mitch Denny" <Click here to reveal e-mail address> wrote in message
news:691329@aspngarchitecture...
[Original message clipped]
|
|
| |
|
| |
| Ben Hyrman |
From: "Jonathan Green" <Click here to reveal e-mail address>
[Original message clipped]
Overall, I agree with the sentiment in your email, but this gave me
indigestion. =)
Long winded reply:
I will try and provide a few academic, but hopefully useful, counters to
this statement.
There are two things that seem to be constant sources of philosophical
debate among programmers. Stateful versus stateless business objects; and
stored procedures versus prepared SQL. Oh, there is one more contentious
debate, Star Wars versus Star Trek, but that discussion calls for arm
waving and beer.
Here's my first argument against business logic in stored
procedures...operational cost.
Let's say my user base grows. This probably means my application is handling
more requests and transactions. I will likely reach a point where I need
more hardware. Let's just pretend there is no physical app server...there is
just a web server and a database server.
If I placed all of my business logic and validation on the web server, even
if it is in business objects on the web server, then I can easily scale
simply by adding more web servers. If I'm using Windows 2000 and a hardware
load balancer, I can get away with just adding another server....for a total
cost of ~$5000. If I'm using Network Load Balancing, then I need Windows
2000 Advanced Server, but my entry cost is still fairly low.
If I placed all of my business logic and validation in the database server,
then I need to worry about getting a new database server and getting it in
to the clustered, load-balanced environment with the other solutions.
Frankly, I'm not sure how well SQL Server 2000 and Datacenter handles this,
although I'm assuming it's fairly straightforward. However, not every
front-end will be accessing SQL Server, and I can attest to the joys of
anything clustered on Oracle before 9i RAC. Typically, these costs are not
in the $5000 range, either.
Secondly, support costs:
At my company, let's say my production DBAs make $90,000 a year. My
application support people make $43,000 a year. If business rules change, it
would need to take the application team at least twice as long to implement
the changes for it to be cheaper to use the DBA. Plus, in order to test, the
DBA still needs to involve the application support team, which will cost
money, while the app support team can likely handle testing without the DBA.
Of course, we could save even more if some business logic could be
abstracted out of the business objects and placed in a format that a
business user could readily update.
Third:
What are you really gaining from this approach? Network traffic is slightly
reduced. What are you losing? No integration to SNMP for monitoring, no
automated paging or notification when applying the business rules fails. Of
course, you can put hacks into the database to accomplish this, and I have
in the past, but then you are placing an even greater load on the database
server..the need for beefier hardware then zeros out the benefit of the
reduced network load.
Now, an analogy...or allegory...or parable, I'm not sure which...but let's
say that it's a true story, but the names have been changed to protect the
stupid.
Let's say a company purchased a product that was built on Oracle 8i. The
foundation for the product was a solid one. However, the vendor made a
crucial mistake, they embedded business logic into stored procs. The
solution had clients for presentation and everything else was in stored
procs. Now, this wasn't a cheap solution that they sold either.
Like all packaged solutions, the application needed to be extended. So, the
consulting company that the customer brought in got right to work on
tailoring the application. Of course, the stored procs housed all of the
business logic, so these were customized right away. T | | |
