RE: Application design & architecture

I've stayed out of this conversation primarily because I think the tone is
smug and condescending, but I feel it necessary to interject just a modicum
of sanity.  Then I shall move on to things that actually are worth the time.

> From: Trevor Perry
> 
> > In what way does SOA help to simplify the processes of development?
> Many ways. Here are five:

> 1) Modularization. Maintenance of modules has proven to be much cheaper
> than
> maintenance of legacy linear programs.
> 2) Re-use. IBM preaches governance, and consider this key to SOA. If you
> know your environment, then you will know when a module can be re-used.
> Instead of traditional subroutine repetition, business processes will be
> built and linked together when needed.

These two are nothing new.  Ever since we had the CALL opcode we had this in
RPG, and those of us who have been doing n-tier design since it was called
"client/server" realize that this is just the SOA zealots claiming something
someone else did as their own.


> 3) New applications. As your business processes are already built, new
> application development will comprise more choreography and orchestration
> than new coding.

How many times have we heard this?  We'll be able to simply pull things off
the shelf, plug them together and we'll have a new application.  It's been
promised for ever and it doesn't work, primarily because the components
don't exist for real businesses; every business is different and thus they
need their own components for the most part.  You may be able to put new
faces on things, but you won't be able to extend your business without
writing new features.  SOA doesn't help with that in the least.


> 4) Leveraging partner development. When you have a business process that
> is
> required in an application, and it has been developed by someone else -
> let's say a customer credit check - your application can consume the
> partners service. You have less coding, and therefore less maintenance. If
> you want to argue about the quality of a partner's code, why would you be
> in business with them if you did not trust that?

I suggest you take a long look at the abject failure of the UDDI to see how
the concept of using someone else's software will work.  It's tough enough
to count on the quality of my own code.  I certainly won't commit my
business to software written by someone else.  And when I need an
enhancement, who is to say my priorities are the same as my partner's?
Every partner now becomes a point of failure for my application.  Show me
one instance where this works in the real world.


> 5) Loosely coupled. When your business needs change, and you partner with
> someone else, switching your web service to consume a credit check from a
> different business partner does not require re-coding. SOA includes open
> standards like web services for this purpose.

Until the world of SOA has globally agreed upon standards for quality of
service, availability, data security, liability and any number of other real
world issues, this simply isn't going to happen.  How many people are you
going to be willing to share your private corporate information with?  How
many real world calculations do you perform that don't need such
information?


Yes, SOA allows reuse of your own code and encapsulation of your data, but
so do quite a number of other techniques which aren't saddled with the
complexities and inherent problems of web services and especially SOAP,
which is the unfortunate current standard of web services
intercommunication.

For intra-company work (the only model that will be feasible in the near
future) you can do the same with a decent queueing mechanism and any of a
number of inter-tier communications protocols.

SOA brings nothing new to the table, and really won't until there is a
complete quantum shift in the availability and reliability of software as a
service, and that isn't going to happen anytime soon.

There, glad I got that off my chest.  We now return you to your regularly
scheduled pontification.


Joe