Hello Dennis,
The link
http://www.sosnoski.com/jibx-wiki/space/axis2-jibx/soa-for-devs/soa-for-developers.pdf
on this page does not work.
Can you have a look at it?
Thanks
Franz
Dennis Sosnoski schrieb:
Bad specifications are a major part of the issue with interoperability
problems. In the case of SOAP itself, the people who wrote the
specification left too much unspecified and too many options. In the
case of XML Schema, the specification is long, complex, and confusing
- and also provides too many options.
WS-I helped a lot with the basic SOAP features, but didn't address
Schema - and Schema is increasingly where the interoperability
problems originate (both directly, when applications use Schema
constructs that don't work well across frameworks, and indirectly,
when the framework itself has problems - as in this case). I give some
recommendations in this area as part of some of my presentations. I
just posted the slides from my "SOA for Developers" workshop, which
includes a fairly extensive chunk on schema, at
http://www.sosnoski.com/jibx-wiki/space/axis2-jibx/soa-for-devs
There is an effort in progress to come up with a sort of WS-I for
Schema equivalent, through the W3C "XML Schema Patterns for
Databinding Working Group" (http://www.w3.org/2002/ws/databinding/).
It looks like the working group is doing a good job on this. I
especially like the way they're defining patterns that can easily be
tested in Schema instances. Hopefully within a year or so everyone
will be able to use the basic patterns and know that they'll be
handled properly by all the major data binding frameworks (or use some
of the advanced ones, and know that they'll be limiting themselves to
selected frameworks).
- Dennis
DBDavide wrote:
...
<ranting>
Too many interoperability issues in real world... everything works
smootly
only if both end points uses the same product or I'm really really
lucky.
- If I'm implementing both server and client I don't see the
advantage of
using a so complicated technology.
- If I'm implementing just one side, the automagically generated wsdl or
automagically generated client stubs from wsdl it's really a dicer's
oath
:-) 99% of the time you finish digging into wsdl editing or on the wire
analisys...
I was caught in between :-) I'm implementing both sides and I have two
products: Axis on the server side and JBossWS on client side. I wouldn't
wish it upon my worst enemy: time spent on this technology is becoming
nearly the same time spent implementing the real business logic.
I think that sometime we lose sight of our real targets. I think that
WS-*
are what I call a "tool" technology, They are a help for our
applications.
Using a screwdriver shouldn't be harder than building a car. How many
times, deployng and managing an applications into an application
server is far more complicated than application itself? If it's happen,
probably we missed something.
</ranting>
Bye
--
Davide
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
begin:vcard
fn:Dr. Franz Fehringer
n:Fehringer;Franz
org:ISO Software Systeme
adr;quoted-printable:;;Eichendorffstrasse 29;N=C3=BCrnberg;;90491;Deutschland
email;internet:mailto:[EMAIL PROTECTED]
tel;work:+49/(911) - 99594-0
tel;fax:+49/(911) - 99594-580
x-mozilla-html:TRUE
url:http://www.isogmbh.de/
version:2.1
end:vcard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]