RE: Application design & architecture

Trevor,

I believe this is part of the question that's being asked....  In my own
case, I'm hoping to qualify which application designs are better suited for
SOA deployment.  We're looking to establish guidlines for ILE development so
that our runtime modules can be deployed using a variety of methods (SOA,
SQL stored procedure, etc...)

I would assume that n-tier designs, which seperate the presentation logic
from the business logic elements, are preferred for SOA.  However, with my
limited understanding of SOA, it's hard to know whether n-tier is really the
direction I need to take.  So many of the "best practices" that are commonly
in use today are unacceptably out-of-date.  

Take a benign example...  Commitment control.  In all the shops I've worked,
this is one of the "dirty words".  Ask someone WHY they won't consider
commitment control, and you'll hear every excuse imaginable, none of which
is applicable to the modern systems that we work with today.  I've actually
had more luck promoting this concept if I avoid using the AS400 specific
vocabulary.  Call it "Transaction Isolation" and people will at least
listen...

In a general sense, I'd like to devise a strategy to re-engineer our
applications to play a larger role in IT outside of the iSeries.  SOA is
probably the architecture we will adopt, so we need to ensure that our
development standards will support this goal.

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Trevor Perry
Sent: Monday, May 08, 2006 9:24 AM
To: Midrange Systems Technical Discussion
Subject: Re: Application design & architecture


Rob,

It has been done. It is called SOA.

Trevor

----- Original Message ----- 
From: "Rob Dixon" 
Subject: Re: Application design & architecture
> 
> Can we design an architecture that will make us more efficient?
> 
> If enough people are interested, it might be a useful discussion.
> 
> 
> Rob Dixon