Re: Application design & architecture -- MIDRANGE-L

Joe!

Welcome to the depths of condescension! :-) I thought I was reasonable andnot sarcastic in my explanations.. even if Rob was trying to make me lookbad???

Ironically, your email is more reason why SOA ~will~ work. Let me see how ifI can do it without the smart-ass...

These two are nothing new. Ever since we had the CALL opcode we had thisin
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 claimingsomething
someone else did as their own.

SOA zealots claim that SOA is the 'best practices' of everything we havebeen doing. SOA is not claiming "new" - that is the sales machine of certainvendors we know and love. Don't learn SOA from a sales pitch, would be goodadvice.

How many times have we heard this? We'll be able to simply pull thingsoff

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.

SOA is designed to DO this, given the past failures of such approaches. Thisis one of the reasons for SOA. You are exactly right, except for the lastsentence.

I suggest you take a long look at the abject failure of the UDDI to seehow

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.

UDDI.com being closed down is not an abject failure. The concept of UDDI isvery important - what happened was that it evolved. Companies did not wantto publish their web service information to a global catalog. UDDI now worksin a smaller capacity - where industry groups have their version of a UDDI,companies have internal UDDI in the form of Registry/Repository.And yes, I have the same concern about "code" from someone else's company.However, in the connected world in which we live, leveraging our businesspartners for what they can do best allows us to get on with what we do best.We do not see the partner's code, simply their business process that theyallow us to use. If you think with your programmer cap, this concept canscare you. If you think about working with trusted business partners toleverage what they can do, that is less scary. And the key is the word"trusted".

As SOA evolves, so will the concepts. UDDI has not failed, but evolved. Thesame thing is happening with ESB - Enterprise Service Bus. There is nosingle clear definition of ESB, however the concept is valid and evolving.

Until the world of SOA has globally agreed upon standards for quality of

service, availability, data security, liability and any number of otherreal

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?

Look at web services. Now we have a way to call a program somewhere else inthe world and not care what language, what software, what hardware is used.A globally agreed upon standard which was instrumental in forming the coreof SOA. Building web services requires attention to data security,availability, etc - this is all part of the application you are developing.No one would consider creating a web service to expose your privatecorporate information with anyone but trusted partners. This would bethinking from three or four decades ago, and is no longer an assumption -security is inherent to your web application.

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.

With any standards, there are going to be complexities and inherentproblems. Picking on web services and SOAP are easy targets. Did you realizethat SOA does not advocate that web services have to be used for yourtransactions? Why would I use it for large volume intra-company datatranslation and transformation? SOA requires only that there is a standardin place. Your SOA Architect will build that into the architecture. Becominginteroperable outside your organization might be a place where you transmitless data, and secure web services with SOAP are simple in that case.And, as web services become pervasive, the tools in .NET and WDSc allow usto use these open standards with a lot less complexity.

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.

The only model? I don't understand how you can see this. The internet hasopened our world so much, and so many companies are taking advantage of it.Where does Walmart fit into an "intra-company" model?

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 asa
service, and that isn't going to happen anytime soon.

SOA brings all the best practices together. It does seem that you arehearing a narrow perspective of what SOA is and what it can do. And that issad.


Trevor