Re: My Enterprise Architecture - your thoughts?
From: Mark Nicholls (Nicholls.Mark_at_mtvne.com)
Date: 06/24/04
- Previous message: Mark Nicholls: "Re: LSP and Equal()......"
- In reply to: Tim Smith: "Re: My Enterprise Architecture - your thoughts?"
- Next in thread: JXStern: "Re: My Enterprise Architecture - your thoughts?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 24 Jun 2004 05:29:42 -0700
> > Is this an "Enterprise Architecture"? I don't think it is, I would
> > refer to things like Zachman for a framework for developing an
> > "Enterprise Architecture".
>
> thanks for the tip
I'm not a fan, so it's not really a tip. Enterprise seems to be a
fashionable word at the moment.
> >
> > I'll read it as a system architecture (note I think Fowlers "Patterns
> > of Enterprise application architecture" is a bit of a misnomer as
> > well, even if it's a very good book along the lines that you are
> > talking).
> >
> > > Logical View has 4 layers
> > >
> > > - Presentation : GUI, views and reports, external system input
> > > - Application : App specific workflow which coordinates business
> > > logic.
> > > Also interface data is mapped and processed here.
> > > - Middleware : Business logic is broken into functional services
> > > Services All database access must be through a service.
> > > - Data : Persistent data access through database stored
> > > procedures
> > >
> > > Process View
> > >
> > > - Each service is a thread, groups of services are a process.
> > > - Services/Applications communicate by passing objects that represent
> > > the domain.
> >
> > I assume tbis is, objects that are members of the domain model? or
> > represent entities in the domain.
> >
>
> Domain model was a new term for me on this project, how it differs
> from an domain entity I am a little fuzzy on. Suffice to say it is an
> object which reflects the real world attributes and relationships
> between objects. This is quite dramatically different to the legacy
> database schema which the service maps the domain object to through an
> adapter.
When talking about domain analysis, I personally talk about entities,
when talking about desing I talk about objects...it's just me...
Personally my database schema is usually pretty close to my domain
model - the zealots don't like it but if you can get away with it it
makes the system much simpler because there is no need for a complex
mapping between database and business logic.
>
> > >
> > > Implementation/Deployment View
> > >
> > > - The services may run on a node ddfferent to the data and
> > > application.
> > > - Service definitions and objects passed between the
> > > application/middleware are deployed on both tiers
> > >
> > > Detailed Design
> > >
> > > An interface example:
> > >
> > > 1) custom data in
> > > external ------> interface (interface app transforms data
> > > system application into a PersonObject)
> > >
> > > 2) PersonObject
> > > interface ------> middleware (PersonObject sent to middleware
> > > application service for processing. Middleware
> > > transforms
> > > into a DatabasePersonObject)
> > >
> > > 3) DatabasePersonObject
> > > middleware ------> database (DatabasePersonObject written to
> > > service layer database.)
> > >
> > > As you can see there is a fair amount of mapping/transforming.
> > > Certainly I can look for some patterns on that. The reason for a
> > > separate PersonObject to DatabasePersonObject is to reduce the impact
> > > of data model changes on the application (only the adapter in the
> > > interface layer need change).
> > >
> > > There is a fair amount of data being transferred and I worry that
> > > there will be scalability issues as many users access the system,
> > > although it is designed so that you can replicate the service tier on
> > > many nodes.
> >
> > You may have absolute performance problems with just 1 user.
>
> Hmm, well I have done a prototype of course running on a low grade PC
> and I saw around 150ms for a general search function which returns
> 10-100 rows back to the screen. So while not as fast as a direct
> database connection/display I would not say it has performance
> problems yet.
Good.
Are you testing it in the same physical deployment that you intend
using i.e. do you intend deploying each tier as a distinct application
or not.
If you are you performance characteristic may change dramatically and
it will have significant impact on the way your layers interact i.e.
they're better stateless.
>
> >
> > Your scalability problems will generally be contention in the
> > database, or bandwidth on your network.
>
> I am banking on being able to ramp up the database, and as many
> servers of services as needed. Network, I have some concerns but I am
> not sure if it will be a bottleneck, perhaps not if I can get 1GB
> ethernet connections to the servers.
If your servers are stateless it easy to ramp them up, networks are
not often a problem unless there is a lot of traffic, databases are
expensive to ramp up.
>
> >
> > There doesn't seem to be anything glaringly out of the ordinary, I
> > would worry about....
> >
> > i) complexity...you may not need all this.
>
> We are looking to this for the base of an information system with a
> large amount of functionality (2 years to build with 30 developers or
> so).
oooo
you may well need it then.
>
> > ii) absolute performance - the more layers you put in and
> > transformations, and passing data by value, you do the slower the
> > response for a single user.
>
> I agree, I do wonder if it will work. My old company did it with a
> home grown middleware but it was written in a lower level language
> than I will use.
Don't get too hung up on middleware technology or language efficiency,
90% (guess) of your efficiency will stem from your design. If you get
it wrong, it wont matter if it's written in assembler on a Cray.
As far as performance is concerned, I personally find text book tiered
systems work well for low volumes of data (and large ammounts of
concurrent users) they handle high volumes poorly, RDB's though
process huge ammounts of data very efficienty...don't box yourself in
and make using things like stored procedures difficult.
>
> > iii) scalability - there is nothing here that makes me especially
> > worried, how many concurrent users are you like to have, accessing how
> > many rows on average on what sort of DB - your logic layer will
> > probably not be the bottleneck.
>
> 20 power users, 50-200 lighter users, interfaces processing a
> transaction a second between them, some reports etc. Trying to reduce
> the number of rows accessed.
If you can limit the ammount of rows that they access in a single
transaction...you can always implement a 'more rows' type
functionality.
Concurrent connections?
Some DB's scale much better than others, so maybe don't get yourself
in a corner about which RDB you use.
>
> >
> > I would refer to
> > Fowlers "Patterns of Enterprise application architecture".
> > and "Enterprise integration patterns" for you "custom data in"
>
> I have been working through that book, though it is a little light in
> some areas (data layer).
"Patterns of Enterprise application architecture" is the best book
around, though personally I find it quite difficult to fathom at
times.
I often don't particularly see that a DA contains very much at all
compared to the BLL.
>
> >
> > If its being done from scratch I would start small, concentrating on a
> > single simple top to bottom functional aspect of the system, develop
> > the architecture and then mitigate your worries by running some
> > performance/scalability tests.
>
> Yep, I have a test interface which will be the prototype.
As I say, make sure it is deployed in the same physical way as you
intend, with different client and server computers and the correct
physical deployment of server.
- Previous message: Mark Nicholls: "Re: LSP and Equal()......"
- In reply to: Tim Smith: "Re: My Enterprise Architecture - your thoughts?"
- Next in thread: JXStern: "Re: My Enterprise Architecture - your thoughts?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
