× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Joe!

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


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

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.
SOA zealots claim that SOA is the 'best practices' of everything we have been doing. SOA is not claiming "new" - that is the sales machine of certain vendors we know and love. Don't learn SOA from a sales pitch, would be good advice.

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.
SOA is designed to DO this, given the past failures of such approaches. This is one of the reasons for SOA. You are exactly right, except for the last sentence.

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.
UDDI.com being closed down is not an abject failure. The concept of UDDI is very important - what happened was that it evolved. Companies did not want to publish their web service information to a global catalog. UDDI now works in 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 business partners 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 they allow us to use. If you think with your programmer cap, this concept can scare you. If you think about working with trusted business partners to leverage 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. The same thing is happening with ESB - Enterprise Service Bus. There is no single 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 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?
Look at web services. Now we have a way to call a program somewhere else in the world and not care what language, what software, what hardware is used. A globally agreed upon standard which was instrumental in forming the core of 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 private corporate information with anyone but trusted partners. This would be thinking 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 inherent problems. Picking on web services and SOAP are easy targets. Did you realize that SOA does not advocate that web services have to be used for your transactions? Why would I use it for large volume intra-company data translation and transformation? SOA requires only that there is a standard in place. Your SOA Architect will build that into the architecture. Becoming interoperable outside your organization might be a place where you transmit less 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 us to 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 has opened 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 as a
service, and that isn't going to happen anytime soon.
SOA brings all the best practices together. It does seem that you are hearing a narrow perspective of what SOA is and what it can do. And that is sad.

Trevor


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.