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]

Reply via email to