RE: Application design & architecture

Trevor,

As Walden put it, we're looking to renovate our applications while we're
living there.  Many of the issues we deal with relate to poor design,
fractured development, poor documentation, loss of technical expertise, and
so forth.  We're looking to proceed with ILE to support a retrofit of our
applications.  At the same time, we want to ensure that the framework we lay
down now will support our goals for the future...

Much of the problem comes from the "baggage" that as400 pros have carried
with them over the years.  The bit about commitment control is just one of
the many elements being denied to the developer simply because 20 years ago
it caused a problem....  

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 10:45 AM
To: Midrange Systems Technical Discussion
Subject: Re: Application design & architecture


Eric,

I think most people are at the same place as you are when it comes to SOA. I

would say that there is no question about which applications are suited for 
SOA 'deployment' - it is ALL of them.

SOA is an architecture for your entire business. It is not something that 
you compare to SQL stored procedures, for example. SQL stored procedures are

one of the technologies that could be used to create SOA - just as ILE is, 
just as RPG is, etc.

Compare this to building a house. Most people hire the builder first - just 
like we are the developers. The builder has tools - hammers, saws, wrenches.

The developer has tools - RPG, SQL, J2ee, .NET. The architect is the 
designer of how the house looks - where things fit together, the standards 
of plumbing, wiring, how rooms fit together, etc. The SOA architect is the 
one who designs how things fit together - modularized, loosely coupled, open

standards, interoperable, etc. Commitment control is a tool for a developer,

not an architect.

Service-Oriented Architecture does not dictate the tools you use. SOA 
provides the foundation, the framework, the standards for how the 'house' 
will be built.


Trevor


----- Original Message ----- 
From: "DeLong, Eric"
Subject: 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