 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
mamcx
Guest
|
 Posted: Mon Dec 01, 2003 9:46 pm Post subject: System-based development: how??? |
 |
|
So exist a "new" way to develop programs: system based, using messages,
can be deploy anywhere, can have logic+interface+data, are
self-contained, etc... So look good but complex too. For build a ERP
system have sense folow this?
P.D. Please a example of code, i don't see how implement a service... so
the idea is use for example web-services but also i know that a
service-system is diferent to a component but anyway i don't code
diferent..so how??
|
|
| Back to top |
|
 |
Marc Rohloff
Guest
|
| Posted: Mon Dec 01, 2003 10:27 pm Post subject: Re: System-based development: how??? |
|
|
In article <3FCBB6C7.9060805 (AT) notexist (DOT) com>, [email]this (AT) notexist (DOT) com[/email] says...
| Quote: | So exist a "new" way to develop programs: system based, using messages,
can be deploy anywhere, can have logic+interface+data, are
self-contained, etc... So look good but complex too. For build a ERP
system have sense folow this?
P.D. Please a example of code, i don't see how implement a service... so
the idea is use for example web-services but also i know that a
service-system is diferent to a component but anyway i don't code
diferent..so how??
|
I think you need to explain in a bit more depth what you are attempting
to achieve. Also break it up into smaller goals. Developing a huge
system in one go is not usually sane.
Marc
marc rohloff at bigfoot dot com
|
|
| Back to top |
|
|
Franz-Leo Chomse
Guest
|
| Posted: Tue Dec 02, 2003 10:59 am Post subject: Re: System-based development: how??? |
|
|
On Mon, 01 Dec 2003 16:46:47 -0500, mamcx <this (AT) notexist (DOT) com> wrote:
| Quote: | So exist a "new" way to develop programs: system based, using messages,
can be deploy anywhere, can have logic+interface+data, are
self-contained, etc... So look good but complex too. For build a ERP
system have sense folow this?
|
I assume that you mean SERVICE based programs. But that's just the
new
term for distributed programming, with SOAP used on the connection
level.
Regards from Germany
Franz-Leo
|
|
| Back to top |
|
|
mamcx
Guest
|
| Posted: Tue Dec 02, 2003 6:47 pm Post subject: Re: System-based development: how??? |
|
|
| Quote: | I assume that you mean SERVICE based programs. But that's just the
new
term for distributed programming, with SOAP used on the connection
level.
|
Ups, that its.. service based.
But from the high level SOAP is only a way to solve the comunication
side...i want to use something like Remobjects or MsgConnect because
SOAP is tooo slow for a ERP system if all is based in SOAP/XML...
I wanna do something like:
ContactModule
Then reuse it in
Customer/Company/Etc...Module
I think in using Bold but i still no figure how build a complete system
like contact, reuse it then connect to SalesModule or AccountingModule..
i imagine that a service based can help in solve it..but exist other way???
|
|
| Back to top |
|
|
paul
Guest
|
| Posted: Tue Dec 02, 2003 9:26 pm Post subject: Re: System-based development: how??? |
|
|
"mamcx" <this (AT) notexist (DOT) com> wrote
| Quote: | Ups, that its.. service based.
But from the high level SOAP is only a way to solve the comunication
side...i want to use something like Remobjects or MsgConnect because
SOAP is tooo slow for a ERP system if all is based in SOAP/XML...
I wanna do something like:
ContactModule
Then reuse it in
Customer/Company/Etc...Module
I think in using Bold but i still no figure how build a complete system
like contact, reuse it then connect to SalesModule or AccountingModule..
i imagine that a service based can help in solve it..but exist other
way???
|
May I suggest that you take a look a the Patterns of Enterprise Application
Architecture (PEAA) book by Martin Fowler. This is an excellent reference
for n-tier systems development. Also if you do not have it the Design
Patterns (DP) book.
By the sounds of it you wish to have domain logic sitting on the server so
that multiple clients (by that I mean different application, not multiple
instances of the same application) can access the same logic.
This is probably the most complex that a business based systems get. I
personally would seriously way up whether this is absolutely needed. Can
you get away with the system being two tier and have your Domain logic layer
and presentation layer compiled into the client. It may not be classed as
the sexiest way to go but it reduces so much complexity that if you can go
that way do.
I am just in the closing stages of a project an building an architecture
that does domain logic on the server. Here are the main things that I would
be concerned about
1. Transaction handling in the domain layer.
2. Error propagation from the server to the client.
3. User Authentication on the domain layer.
4. Cross network method calls.
To build this architecture here were the objective that I used for all my
design trade offs -
1. Minimize Cross network method Calls.
2. Minimize Transaction Time.
3. Stateless Object on the Server.
4. Domain objects to provide data validation and intraObject processing.
The architecture has a Domain Model (PEAA) on the server and remote facade's
(PEAA) on the clients. The Domain Model is made up of what we call Domain
entities these are object that map to a table in the existing relational
database. The entities can have references to each other we use lazy
instantiation for this. The entities are all held in managers which is how
they are loaded/unloaded. On the client we use a remote facade to the
entities on the server but on the client the entities do not have the links
to the other entities. The reason for this is that we have a lot of
different application and we do not wish to have to compile the entire
Domain Model into every client application. This structure also allows us
to provided some validation in the client and the more complex validation on
the server although client validation is always repeated on the server as we
can not guarantee where the entity state has come from. We use a Data
Transfer Object (PEAA) to transfer the state information between the server
and client.
For transaction handling we use COM+
So the structure is something like
Server
Manager - responsible for getting entity state/persisting entities
to/from the data layer.
Entity - All validation and rules held in these
Server object are stateless in that they only live to get the data for a
client request or to perform full validation on the entities state from the
client before it is persisted.
Client
Manager - Same as server manager except that instead of getting entity
state/persisting entities to/from the data layer it does it to the server
managers.
Entity - Provides validation that can be applied on the client.
Cross Network
Data Transfer Object (DTO)- Each entity can write it state to a DTO and
load from a DTO. The manager will get the DTO for each entity in it's
collection. The DTO can save/load themselves to/from XML which is how it is
transported across the wire. The DTO is also how the information is sent to
the Data Layer. Infact the DTO's are my object of the project as they
basically are a memento(DP) on the client side we implemented an undo
facility in the entities in 1 hour and it worked across all the domain
entities that we had built.
We also have standard error handling system that works consistently through
the architecture and a sort of Independent Data Layer. There is also a
presentation layer architecture that sits on top of it for win32 Clients.
Whether this is the most OO pure or best possible architecture for this type
of system is debatable, well actually no it's not it just is not the best or
OO pure. There are lots of trade off but it does meet the design
objectives, it meets the performance requirements so far although only time
and stress testing will prove that conclusively. It work in such a way that
the developers that use this architecture have a common approach to how
things are developed and spend the main of there time on developing domain
logic rather than pipe work. Sorry for the length of the post, but I hope
that gives you some useful food for thought.
regards
Paul
williampaulmoore at yahoo dot co dot uk
|
|
| Back to top |
|
|
John Shearing
Guest
|
| Posted: Thu Dec 11, 2003 8:45 pm Post subject: Re: System-based development: how??? |
|
|
Hi Mamcx,
| Quote: | can have logic+interface+data, are
self-contained, etc...
|
I have built an ERP generator for MS SQL Server where logic+interface+data
is all contained in the database or in a middle tier if you prefer.
| Quote: | So look good but complex too.
|
I can send you screen shots of the many ways the generated UI can present
itself.
| Quote: | I wanna do something like:
ContactModule
Then reuse it in
Customer/Company/Etc...Module
|
The all data entry screens can be used and reused at different points
throughout the ERP but can appear different ways depending on where in the
ERP they are located or which user is accessing the screen.
Contact me at [email]johnshearing (AT) aol (DOT) com[/email] or 201 665 8906 if you want to know more.
Thanks, John
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
