> That's good news, but much also remains unchanged since 2002. Web
> services still rely on the text-based XML protocol, which means a
> natural language parser is needed to decipher and transform SOAP-based
> messages--a processor-intensive task.
This is great! Stop the presses! The SemWeb folks can all go home,
because XML parsers are natural language parsers. Who needs semantics
and inferencing when the machine "understands" what you're trying to
do. Web services are now "AI complete" where, quoting John Sowa:
> [A.Walker]> ... One can then start to focus on more recent technical issues,
> > such as how to be more ambitious about robust processing of natural
> > language without falling off the "AI-complete" cliff.
>
> It's good that you brought up the term "AI complete". The usual
> definition is that a problem X is AI complete iff X requires that
> every AI problem must be solved before solving X. Full NLP or fully
> automatic computer programming seem to be AI-complete problems.
And, as I mentioned in my earlier post, the scary thing is that people
who don't know any better will now actually *believe* that XML is a
"natural language" in addition to it not being possible to build
performant, scalable Web services (with or without SOAP). Sheesh.
> Those standards provide enough protection to ensure Web services
> security across the Internet. "Security really shouldn't be a major
> issue anymore. It's not hard to make Web services secure," writes Anne
> Thomas Maines, vice president and research director of application
> platform strategies at the Burton Group, in an IM.>>
Anne, I'm surprised you would say this sort of thing. Just because we
have specifications for implementing secure Web services doesn't mean
that the average developer knows how to implement a secure Web service
(or any other type of secure service for that matter). Interoperability
specifications for security only go so far, but the policies will still
need to be encoded within the application by someone who knows what
they're doing. Security will continue to be hard until more people
understand that it's important. It may be important to CXOs (and
there's still a lot of them out there who aren't there yet), but I bet
that message hasn't gotten down into the trenches without a major
organizational initiative.
I'm reminded of a thought from Barry Bohem and Richard Turner when
they're referring to Cockburn's "Three Levels of Software
Understanding":
> A significant consideration here is the unavoidable statistic that
> 49.999 percent of the world's software developers are below average
> (slightly more precisely, below median).
Of course, this makes sense, but when you figure that Bohem and Turner
split Cockburn's levels into the following--his Level 1 has been split
(from Balancing Agility and Discipline):
Level 1: people to be quickly reassigned to someone else's project (in
someone else's company).
Level 1B: people in the "average and below" category, but who are
hard-working and less experienced.
Level 1A: people who do well, but only if there are enough L2's to
provide guidance.
Level 2: people who are generally team leaders and understand how to
apply what they know to problems they recognize. Some can evolve to
L3's and some can't
Level 3: people able to break the rules to fit a new situation
Now, applying these to software architects and developers and given the
number of practitioners in the world, how many level 2's and 3's are in
the "average" organization? How many are in *your* organization?
This situation is the reality we need to face. If you say something
that is patently wrong (XML is a natural language) or out of context
(Security shouldn't be a major issue) to less than a good Level 2,
they'll probably take it at face value, and if they do, you have a
problem. Maybe you don't have one now, but you might in a week, a month
or years after the solution they're building is in production.
How do we turn the tide? I really don't have an answer to this
question.
ast
***************************************************************************************************
The information in this email is confidential and may be legally privileged Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
