On CBS MoneyWatch: 5 Holiday Shopping Tips
BNET Business Network:
BNET
TechRepublic
ZDNet
TalkBack 5 of 19:
Next »
« Previous
Declaritive programing big part of this stuff
As I understand it, in SOA we access everything over API's. I have worked with systems that try and encapsulate everything on top of a database in classes and I must say the result is an inflexible, unmanageable disaster.

Its always a trade-off of structure vs. flexibility. The downside of flexibility is life side management costs and needless complexibility. The downside of structure is increased learning time and sometimes less than optimal solutions. SOA to me is a design concept implementable using just about any technology but it basically says define the service each black box provides then optimize it for that service. Lack of the ability to control the product's configuration in the field kills that effort from the start.

Basically you throw away the whole flexibility of the relational approach in favour of a procedural, parameter driven approach where every time you change the database structure you have to change and recompile huge chunks of the application too.

Well, remember these companies have 40 year old investments in technology on which they run their business. Nobody wants to flash cut such system to a new paradygm in one step (they have been burnt earlier in their career and learned better). Middleware promises to decouple the consumer from the supplier ... sure work has to happen when things need to change but at least you can localize the impact of changes to a particular tier.

Declaritive programing concepts are a big part of the J2EE stack and help abit with this type of "maged change" problem. XML defines the data, configuration files customize the stack. Sure its complex as all get out to learn (is that a forest or just a bunch of trees?) but it works better than a one size fits all concept on the big "enterprise" type applications.

Even in a single company they will have different departmental solutions to need to interface the backe end stuff to. The promise of encapsulating the legacy, providing a generic serive to all consumers, then building dedicated consumer "servers" for each presentation layer is a powerful concept which add structure to the enterprise migration and greatly reduces risk to management.
Posted by: oldskool   Posted on: 04/02/04 You are currently: a Guest | Members login | Terms of Use

Alert moderator to an offensive message

Subscribe to this discussion via Email or RSS

Services support  Enterprise Analyst | 04/01/04
Why SOA is the wrong approach  jorwell | 04/01/04
SOA is encapsulation not data replication  oldskool | 04/01/04
SOA, deeply inflexible too  jorwell | 04/01/04
Declaritive programing big part of this stuff  oldskool | 04/02/04
I still don't get it  jorwell | 04/02/04
Doesn't relational belong in the DB tier?  oldskool | 04/02/04
too broad  jhayzee | 08/11/05
Another "new" bandwagon folks. All aboard!!!  No_Ax_to_Grind | 04/01/04
no kidding - no pay to play for me thanks  V Sanders | 04/01/04
No Ax your getting old, time to retire to that  BXLE | 08/13/04
Another PR spin  KeithRisler | 04/01/04
millions of dollars  V Sanders | 04/01/04
lets not be too hasty  V Sanders | 04/01/04
Totally the wrong priorities  jorwell | 04/02/04
Totally the wrong priorities  jorwell | 04/02/04
First step to replace is decouple  oldskool | 04/02/04
SOA is a natural progression  bykerk | 04/23/04
Same old Client Server Architecture - ReBaked  aesjr44 | 09/08/04

What do you think?

SponsoredWhite Papers, Webcasts, and Downloads

advertisement
advertisement

Meet Doc