«

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?

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


"BJ" <> wrote in message
news: oups.com...
>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?
>

On Sep 22, 2:19 am, "Just Me" <news.microsoft.com> wrote:
> 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
>
> "BJ" <julie6232...@yahoo.com> wrote in message
>
> news: oups.com...
>
>
>
> >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?- Hide quoted text -
>
> - 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

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



"BJ" <> wrote in message
news: oups.com...
> On Sep 22, 2:19 am, "Just Me" <news.microsoft.com> wrote:
>> 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
>>
>> "BJ" <julie6232...@yahoo.com> wrote in message
>>
>> news: oups.com...
>>
>>
>>
>> >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?- Hide quoted text -
>>
>> - 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
>

On Sep 23, 1:38 am, "Just Me" <news.microsoft.com> wrote:
> 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.

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



"BJ" <> wrote in message
news: ups.com...
> On Sep 23, 1:38 am, "Just Me" <news.microsoft.com> wrote:
>> 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.
>
>

Thank you!!! I too subscribe to K.I.S.S. Have a great day