[
Lists Home |
Date Index |
Thread Index
]
http://www.zapthink.com/reports/ProsConsWS-ZTR-WS102.pdf
Overall, that is a good article, Mike. Some points worth
bringing here:
"... in many ways, standards are both a blessing and a curse.
Clearly standards facilitate the growth of business ... However,
in many cases, standards bodies lose sight of the fact that facilitating
business is the fundamental goal of all standards development."
Agree. This is better understood in context of comments made
later about the requirements for growth of understanding and
skills needed to create web services.
"In the medium term (2004-2005) participants... will need to agree
beforehand on a common set of semantics. Upgrades will need to take
place in the context of the common semantic understanding in order to
achieve the automatic upgradability....
EDI is a relatively arcane technology that requires a substantial overhead
on the part of the participants and also requires a clear understanding of
the semantics of the messages exchanged...."
There is no free lunch. Neither XML nor WS solve the problems of
apriori contracting. The article explains the issues with regards
to business processes later. Simply note that XML doesn't fix this
and neither does an application of XML. They are simply facilitating
technologies.
"... once the desired Service is identified, the consumer can bind to and
invoke the service at runtime."
The article goes on to explain that even where this is technically
doable, it is not practical.
"Since web services represent an approach rather than a specific technology,
the main learning curve is the time it takes to learn how to appropriately
created components that exhibit the characteristics of
Service oriented architectures. Learning this new skill could possibly
be just as challenging, if not more so, than learning a new programming
language. In fact, implementing an SOA requiers developers to evolve
from being simple programmers to becoming true software engineers."
Unless the developers understand business and specific business processes,
they can't do this work well. It becomes increasingly important, despite
comments made in this forum to the contrary, for the programmers to
evolve into "true software engineers" capable of analyzing requirements
based on business needs, and not just how to make technology work.
"Market awareness should neve be underestimated when it comes to technology
adoption..... Buy in comes from a justifiable business case that validates
how, when and why a particular technology should be used."
The common home web surfer and the business application user are not
the same market. We have to understand that and quit treating them
as if they were. That leads to tool-inappropriateness. A web site
based on access "anytime anywhere by anyone" needs laissez-faire,
HTML processing, and if it fails or is ugly, ya gets what ya pays for.
On the other hand, a business service has high reliability requirements
which can include the topic of current TAG concern, error handling.
"The Web Services model.. is one of small focused web services that can
be used on the fly without a pre-existing business relationship with the
provider."
As the article goes on to explain, that is wishful thinking for the
most part.
len
From: Mike Champion [mailto:mc@xegesis.org]
Hmmm ... if I had to pick one from my bookmarks, I'd say
http://www.zapthink.com/reports/ProsConsWS-ZTR-WS102.pdf
|
