Gervas - that is a great question, and unfortunately I do not have a great answer ;-)
I have to admit that I have not looked into this.
Eric
----- Original Message ----
From: Gervas Douglas <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, April 12, 2006 12:40:34 PM
Subject: [service-orientated-architecture] Re: XML Tuple Spaces as Middleware
Thank you, Eric. As CTO of an ESB vendor how useful do you think an
XML Tuple Spaces-based middleware product would be, assuming that we
are not dealing with (dare I suggest??:) an environment which is not
exclusively Java-based?
Gervas
--- In [email protected], Eric Newcomer
<[EMAIL PROTECTED]> wrote:
>
> This is absolutely correct, and fundamentally one of the biggest
problems we have today in the software industry - the fact that Web
services specifications are misunderstood and not implemented
correctly. JAX-RPC is the kind of "poster child" for this. I have
personally told people from Sun that it was a mistake to view SOAP as
an RPC like RMI, and that it was a mistake to view Web services in
general as "external technologies" to J2EE, creating APIs for each
spec as if it were a database, directory, or security service external
to the core. Web services should have been implemented as system
level APIs not application level APIs.
>
> The tendency to want to automatically convert XML data types into
language specific data types is understandable but misguided, and
moreover impractical since it's basically impossible. The mismatch
between binary compiled languages with data types designed as if the
language were the only language to be used and a text based document
markup language is too great to ever be made transparent.
>
> The answer is that you have to do some coding to parse and interpret
the XML correctly. This is extra work for developers but the benefit
is standardization across programming languages, operating systems,
middleware systems, database systems, messaging systems, and packaged
applications.
>
> Eric
>
> ----- Original Message ----
> From: Anne Thomas Manes <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Tuesday, April 11, 2006 9:17:16 AM
> Subject: Re: [service-orientated-architecture] Re: XML Tuple Spaces
as Middleware
>
> The primary difference between RMI and SOAP is that RMI works using
pass by reference, and SOAP works using pass by value. I discussed
these differences lightly in my blog entry, "Web services are not
distributed objects". See
http://atmanes.blogspot.com/2005/03/web-services-are-not-distributed.html.
>
> Someone from the Axis user community provided more specific
information here:
> http://marc.theaimsgroup.com/?l==axis-user&m=4091729003011&w==2
>
> The point is that developers need to recognize that SOAP is not a
distributed object system, and that although the JAX-RPC API provides
a programming model that is very similar to RMI, the communications
system acts more like JMS. In one of the earlier posts in this thread,
Dan Creswell lamented that the automatic seralization systems in most
SOAP frameworks handle only a limited subset of primitive types. In
fact, most frameworks can easily handle all primitive types, and they
can easily handle structures and arrays. They run into trouble when
you start trying to automatically serialize language-specific
collection classes, such as Java Hashmaps and .NET Datasets.
>
> The fact that developers assume that a SOAP toolkit should be able
to automatically handle language-specific collection classes is
indicative of the fact that they view SOAP as equivalent to the native
distributed object system. They are approaching the tools from the
wrong perspective.
>
> Rule #1 in SOAP interoperability -- start with the XML Schema type
system, not with the language type system. If you define your
interface using XML Schema and WSDL rather than trying to generate the
WSDL from a Java class, interoperability works much better. And that's
because SOAP is an XML messaging system, not a distributed object system.
>
> The serialization systems can handle all primitive types, and they
can handle most structures and arrays automatically. Some systems get
a bit challenged when using some of the more complex schema
structures, such as <choice> or <union> groups -- but worst case, it
deserializes these structures into DOM.
>
> Anne
>
>
> On 4/8/06, patrickdlogan <[EMAIL PROTECTED]> wrote:
> > It feels very much like RMI, although it's a document exchange
> > system rather than a distributed object system. Developers should
> be
> > aware of that subtle distinction (although many aren't -- leading
> to
> > a variety of bad practices).
>
> I would be interested in more information about why it "feels like
> RMI" but acts like a "document exchange system".
>
> Why does it feel one way, but act another?
>
> If it feels a certain way, why should developers be aware that it is
> acting some other way?
>
> What has led to this confusion, what bad practices have resulted, and
> what can be done to correct them?
>
> This seems critical knowledge toward success with SOAP. Is it boiled
> down somehwere, or why not, for better results with SOAP?
>
> Thanks,
> Patrick
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
>
> 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.
>
----- Original Message ----
From: Gervas Douglas <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, April 12, 2006 12:40:34 PM
Subject: [service-orientated-architecture] Re: XML Tuple Spaces as Middleware
Thank you, Eric. As CTO of an ESB vendor how useful do you think an
XML Tuple Spaces-based middleware product would be, assuming that we
are not dealing with (dare I suggest??:) an environment which is not
exclusively Java-based?
Gervas
--- In [email protected], Eric Newcomer
<[EMAIL PROTECTED]> wrote:
>
> This is absolutely correct, and fundamentally one of the biggest
problems we have today in the software industry - the fact that Web
services specifications are misunderstood and not implemented
correctly. JAX-RPC is the kind of "poster child" for this. I have
personally told people from Sun that it was a mistake to view SOAP as
an RPC like RMI, and that it was a mistake to view Web services in
general as "external technologies" to J2EE, creating APIs for each
spec as if it were a database, directory, or security service external
to the core. Web services should have been implemented as system
level APIs not application level APIs.
>
> The tendency to want to automatically convert XML data types into
language specific data types is understandable but misguided, and
moreover impractical since it's basically impossible. The mismatch
between binary compiled languages with data types designed as if the
language were the only language to be used and a text based document
markup language is too great to ever be made transparent.
>
> The answer is that you have to do some coding to parse and interpret
the XML correctly. This is extra work for developers but the benefit
is standardization across programming languages, operating systems,
middleware systems, database systems, messaging systems, and packaged
applications.
>
> Eric
>
> ----- Original Message ----
> From: Anne Thomas Manes <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Tuesday, April 11, 2006 9:17:16 AM
> Subject: Re: [service-orientated-architecture] Re: XML Tuple Spaces
as Middleware
>
> The primary difference between RMI and SOAP is that RMI works using
pass by reference, and SOAP works using pass by value. I discussed
these differences lightly in my blog entry, "Web services are not
distributed objects". See
http://atmanes.blogspot.com/2005/03/web-services-are-not-distributed.html.
>
> Someone from the Axis user community provided more specific
information here:
> http://marc.theaimsgroup.com/?l==axis-user&m=4091729003011&w==2
>
> The point is that developers need to recognize that SOAP is not a
distributed object system, and that although the JAX-RPC API provides
a programming model that is very similar to RMI, the communications
system acts more like JMS. In one of the earlier posts in this thread,
Dan Creswell lamented that the automatic seralization systems in most
SOAP frameworks handle only a limited subset of primitive types. In
fact, most frameworks can easily handle all primitive types, and they
can easily handle structures and arrays. They run into trouble when
you start trying to automatically serialize language-specific
collection classes, such as Java Hashmaps and .NET Datasets.
>
> The fact that developers assume that a SOAP toolkit should be able
to automatically handle language-specific collection classes is
indicative of the fact that they view SOAP as equivalent to the native
distributed object system. They are approaching the tools from the
wrong perspective.
>
> Rule #1 in SOAP interoperability -- start with the XML Schema type
system, not with the language type system. If you define your
interface using XML Schema and WSDL rather than trying to generate the
WSDL from a Java class, interoperability works much better. And that's
because SOAP is an XML messaging system, not a distributed object system.
>
> The serialization systems can handle all primitive types, and they
can handle most structures and arrays automatically. Some systems get
a bit challenged when using some of the more complex schema
structures, such as <choice> or <union> groups -- but worst case, it
deserializes these structures into DOM.
>
> Anne
>
>
> On 4/8/06, patrickdlogan <[EMAIL PROTECTED]> wrote:
> > It feels very much like RMI, although it's a document exchange
> > system rather than a distributed object system. Developers should
> be
> > aware of that subtle distinction (although many aren't -- leading
> to
> > a variety of bad practices).
>
> I would be interested in more information about why it "feels like
> RMI" but acts like a "document exchange system".
>
> Why does it feel one way, but act another?
>
> If it feels a certain way, why should developers be aware that it is
> acting some other way?
>
> What has led to this confusion, what bad practices have resulted, and
> what can be done to correct them?
>
> This seems critical knowledge toward success with SOAP. Is it boiled
> down somehwere, or why not, for better results with SOAP?
>
> Thanks,
> Patrick
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
>
> 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.
>
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.
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.
