What am I missing?

Discussion in 'ASP .Net' started by BJ, Sep 22, 2007.

  1. BJ

    BJ Guest

    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?
    BJ, Sep 22, 2007
    #1
    1. Advertising

  2. BJ

    Just Me Guest

    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:...
    >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, Sep 22, 2007
    #2
    1. Advertising

  3. BJ

    BJ Guest

    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" <> wrote in message
    >
    > news:...
    >
    >
    >
    > >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
    BJ, Sep 23, 2007
    #3
  4. BJ

    Just Me Guest

    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:...
    > 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" <> wrote in message
    >>
    >> news:...
    >>
    >>
    >>
    >> >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
    >
    Just Me, Sep 23, 2007
    #4
  5. BJ

    BJ Guest

    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.
    BJ, Sep 24, 2007
    #5
  6. BJ

    Just Me Guest

    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:...
    > 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.
    >
    >
    Just Me, Sep 24, 2007
    #6
  7. BJ

    BJ Guest

    Thank you!!! I too subscribe to K.I.S.S. Have a great day
    BJ, Sep 24, 2007
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul Fox
    Replies:
    0
    Views:
    739
    Paul Fox
    Mar 5, 2004
  2. Mark Newby
    Replies:
    1
    Views:
    1,686
  3. CodeMonkey
    Replies:
    0
    Views:
    402
    CodeMonkey
    Oct 11, 2005
  4. Acceed See
    Replies:
    1
    Views:
    516
    Carl W.
    Apr 22, 2005
  5. Gary Herron
    Replies:
    2
    Views:
    654
    Bruno Desthuilliers
    Jul 4, 2006
Loading...

Share This Page