Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / General / September 2007

Tip: Looking for answers? Try searching our database.

What am I missing?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
BJ - 22 Sep 2007 10:06 GMT
I just started this week on a new project.  The existing project uses
BEA Tuxedo as a second layer service broker.  The clients make calls
to the Tux services which in turn retrieves data from an Oracle DB.

My job is to support the current application and possibly upgrade teh
client app to .Net.  I have a few options:

I can rewrite the client desktop application .in Dot Net (FW3.0)
utilizing the same Tux calls or
Write a new desktop application using straight calls to the DB (make
it a two tier app)
Write a new ASP.Net application using straight calls to the DB
Write either a new Win form app or ASP.Net app utilizing WCF services
as a middle tier
Write a new front end (win form or web form) using BizTalk as a
replacement to Tux

Here are my questions:

Assuming the new application is stand alone, why would I need BizTalk?
If the system isn't stand alone, I could still make calls to the Tux
services, so again would I need BizTalk?
What advantages does do I gain if I do use BizTalk over just WCF?
In the pass all of my calls to Web services were slow; wouldn't my app
gain processing performance with less dependency on services (2 tier
vs 3 tier)?
Again what am I gaining with a 3 tier over a 2 tier?
Is there another solution I'm not seeing?
Just Me - 22 Sep 2007 10:19 GMT
Well, your email is very detailed and paradoxically without much detail. I
do subscribe to the three tier club because it does provide a level of
logical seperation between data access and business logic. Sometimes though
there isnt much in the way of business logic and you end up writing the tier
just because you think you should.

I dont know BizTalk, but in truth you dont really hear much about it anyway.
I agree with you about web services as being typically slow. I only tend to
use them if I dont have an alternative for internal design.

Im sure someone will shoot me down for my opinion, but there it is, warts
and all !

;-D

>I just started this week on a new project.  The existing project uses
> BEA Tuxedo as a second layer service broker.  The clients make calls
[quoted text clipped - 24 lines]
> Again what am I gaining with a 3 tier over a 2 tier?
> Is there another solution I'm not seeing?
BJ - 23 Sep 2007 03:35 GMT
> Well, your email is very detailed and paradoxically without much detail. I
> do subscribe to the three tier club because it does provide a level of
[quoted text clipped - 41 lines]
>
> - Show quoted text -

I've had some time to rethink what it is I'm trying to convey.  My
question comes down to the architecture of a new application.  Do I
really need a middle tier solution?  For the purposes of replacing the
just existing application, I can build an ASP.Net site using ASP.AJAX,
JavaScript, and HTML on the Client side; the FileNet APIs, WCF and
ADO.Net on the Server-side.  My short circuit is this solution seems
too easy.  It also appears that by cutting out the middle tier, I will
gain performance.  I'm wondering if there's some major architectural
black hole I'm missing here?  Load balancing maybe?  I don't know
Just Me - 23 Sep 2007 09:38 GMT
Well I dont think so really. You could argue that if you only provide a data
layer and that in asp.net you already have the other two layers in the form
and its code behind that you have a sort of 2.5 layer anyway.

I personally think it depends how complex your middle layer is likely to be.
For example, if you were dealing with a business which had hundreds or
protocols regarding how it did business then a business layer is definately
worth doing but if we are only talking about a few then why bother one could
argue.

The purists will advocate multi teir and will even argue that the tiered
must be firewalled using web services to prevent such terrible erroneous
measures being carried out but errant developers. But thats a purist for
you.  The advantage of taking such and approach is that you then have a
structured way to ewvolve your middle layer.

For me, its horses for courses, if it looks like I need to handle a complex
situation, then I'd better have a very formal method of doing so, if its
simple, why complicate it. And if its simple, abut has been designed in a
complex way, then is it easuer to add to the existing complexity or should I
simplify it, and in doing so where is the business case for it. ?

HTH

>> Well, your email is very detailed and paradoxically without much detail.
>> I
[quoted text clipped - 56 lines]
> gain performance.  I'm wondering if there's some major architectural
> black hole I'm missing here?  Load balancing maybe?  I don't know
BJ - 24 Sep 2007 07:47 GMT
> Well I don't think so really.
Which question?

> I personally think it depends how complex your middle layer is likely to be.
> For example, if you were dealing with a business which had hundreds or
> protocols regarding how it did business then a business layer is definitely
> worth doing but if we are only talking about a few then why bother one could
> argue.

I just started looking at the existing application, but it seems that
the middle tire is making calls to the data layer and passing it off
to the client.  And yes I do agree that if you have dissimilar systems
trying to access the same data or a massive audit process that
interfaces with multiple systems (IBM 3270 Mainframe, Solaris, Win NT)
then a middle tier does make sense.

> The purists will advocate multi tier and will even argue that the tiered
> must be firewalled using web services to prevent such terrible erroneous
> measures being carried out but errant developers. But that's a purist for
> you.  The advantage of taking such and approach is that you then have a
> structured way to evolve your middle layer.

I can't do things because it's the way a purists says it has to be
done a certain way.  We'd all have dumb terminals and writing programs
in COBOL or Assembler.

> For me, its horses for courses, if it looks like I need to handle a complex
> situation, then I'd better have a very formal method of doing so, if its
> simple, why complicate it. And if it's simple, abut has been designed in a
> complex way, then is it easier to add to the existing complexity or should I
> simplify it, and in doing so where is the business case for it. ?

I think what you are saying is the middle tier simplifies a complex
design?  Please correct me if I understood that wrong.

The application is used in a very specific way, show me an image from
my group of images.  Currently, the client application makes a call to
the service, which in turn utilizes the imaging API's to retrieve the
image.  There are some direct calls to the database by the middle
tier.  The middle tier calls are specific to that application.  I
truly do appreciate your response and I'm not arguing any fact other
than by keeping the middle tier what do I gain?  By losing the middle
tier, what do I lose?

I guess I was hoping for a smack up side my head to say, "hey its 35%
faster to use a middle tier" or "its more secure" or "it's the only
way to support 100, 200, 300, 400+ users".  I'm pretty sure invoking a
middle tier is not faster. Instead of going from point A to Z, the
process is going from A to M to Z utilizing a protocol with a lot of
overhead (SOAP).  One of the developers told me SOAP was the new way
to invoke services and CORBA and RMI was the old school way.  Well, I
can say with certainty that CORBA and RMI are older than SOAP, but
unless the number have changed over the past 7 years the evidence says
SOAP is the slowest of those technologies.  I'll use it but don't tell
me CORBA and RMI have gone the way of the dinos.

As far as security, I don't know.  Is having a middle tier more
secure?  If I make it a web form application or a client win form
application, it will sit on the network behind the corporate
firewall.  Today security is maintained utilizing a security table and
LDAP.  They are slowly moving over to AD.

As far as being able to support a large group of users, I don't know
the answer to that one.  I do know that there is only one BEA domain
and one Database for this application.  If some other application
utilizes access to that Database by way of the middle tier, then leave
it up for them.  I did over hear the supervisor say they were looking
for a more supportable solution.  Today, if a change has to happen in
the middle tier there is one developer for all three BEA domains that
writes those services.  It took us two full days to find a problem in
the VB6 code because we could figure out a Tuxedo error 12.

Again thank you for the reply, but so far for this application, I
really don't see why I would need to maintain a middle tier.
Just Me - 24 Sep 2007 08:02 GMT
From what you have told me, it sounds like you either dont need a middle
layer, or your middle layer needs to be simplified.

It is never going to be faster with a middle layer, you may not easily be
able to prover it slower with impirical data but it nevertheless will be,
even if not in a material sense.

As for security, that depends on what you mean. Its not going to make the
data layer any more secure than its already designed to be, its not going to
make the application more secure either. One thing it will do ( depending on
how you design it ) is to make it tougher for developers to visibly cut
through the middle layer in terms of  calls, but ultimately its not going to
prevent it either unless you start adding certificates to each layer, and
hey who wants to do that. ?

An old developer that I knew used to keep a four letter sign in 96point text
above his screen with the word KISS on it, ( Keep It Simple Stupid ). An
axiom he swore by, and he allways wrote concise readable robust code. Life
is too complex as it is without adding complexity where its not required.

What I am saying is, if you dont need it, and you will instinctively know
this, then dont do it.

HTH

>> Well I don't think so really.
> Which question?
[quoted text clipped - 76 lines]
> Again thank you for the reply, but so far for this application, I
> really don't see why I would need to maintain a middle tier.
BJ - 24 Sep 2007 17:21 GMT
Thank you!!!  I too subscribe to K.I.S.S.  Have a great day

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.