[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Web Services Review

• To: 'Mike Champion' <mc@x...>, xml-dev@l...
• Subject: RE: Web Services Review
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Thu, 30 May 2002 11:44:43 -0500

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@x...]


Hmmm ... if I had to pick one from my bookmarks, I'd say
http://www.zapthink.com/reports/ProsConsWS-ZTR-WS102.pdf

• Prev by Date: RE: SAX survey: expected local name for non-namespace qualified elements
• Next by Date: Re: XML IDE: What are the top 3 and why?
• Previous by thread: RE: Web Services Review
• Next by thread: RE: Different Validation in XML Spy 4.2, 4.3 and 4.4
• Index(es):
  • Date
  • Thread