You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@xml.apache.org by hu...@jpmorgan.com on 2002/01/30 19:14:08 UTC
Implementation-independent services...
This is probably a pretty basic question but I'm not sure I should be
implementing what the specification for the project defines...
I am creating a system where different development groups are implementing
a pre-defined SOAP service. It's possible that the service implementors
will not use Java. There is a defined API for the SOAP service as follows:
String getPublication( PublicationInputModel pim, EntitlementsModel em)
The original architect specified that the objects should be passed in as
XML instead of objects to support a non-Java SOAP service implementations.
It seems to me that I should just publish the generated WSDL to the service
implementors and that should be sufficient for them to implement the
service in any language. Is that the correct way to do this? It also
appears that using XML inputs (vs. objects) hampers discovery of services
in a UDDI repository.
Thanks,
Shawn.
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.
Re: Implementation-independent services...
Posted by John Mani <jo...@sixthdimension.com>.
> The original architect specified that the objects should be passed in as
> XML instead of objects to support a non-Java SOAP service implementations.
Well, one of SOAP's key features is the ability to pass around objects
(actually data structures)
in an interoperable manner.
> It seems to me that I should just publish the generated WSDL to the
service
> implementors and that should be sufficient for them to implement the
> service in any language. Is that the correct way to do this?
I'd say so. If the Java objects that you pass around are simple JavaBeans,
Apache's
build-in (assuming you're using apache-soap) beanserializer can do all the
hard lifting
for you.
> It also
> appears that using XML inputs (vs. objects) hampers discovery of services
> in a UDDI repository.
No idea.
-john
> Thanks,
> Shawn.
>
>
> This communication is for informational purposes only. It is not intended
as
> an offer or solicitation for the purchase or sale of any financial
instrument
> or as an official confirmation of any transaction. All market prices, data
> and other information are not warranted as to completeness or accuracy and
> are subject to change without notice. Any comments or statements made
herein
> do not necessarily reflect those of J.P. Morgan Chase & Co., its
> subsidiaries and affiliates.
>
>
Re: Implementation-independent services...
Posted by John Mani <jo...@sixthdimension.com>.
> The original architect specified that the objects should be passed in as
> XML instead of objects to support a non-Java SOAP service implementations.
Well, one of SOAP's key features is the ability to pass around objects
(actually data structures)
in an interoperable manner.
> It seems to me that I should just publish the generated WSDL to the
service
> implementors and that should be sufficient for them to implement the
> service in any language. Is that the correct way to do this?
I'd say so. If the Java objects that you pass around are simple JavaBeans,
Apache's
build-in (assuming you're using apache-soap) beanserializer can do all the
hard lifting
for you.
> It also
> appears that using XML inputs (vs. objects) hampers discovery of services
> in a UDDI repository.
No idea.
-john
> Thanks,
> Shawn.
>
>
> This communication is for informational purposes only. It is not intended
as
> an offer or solicitation for the purchase or sale of any financial
instrument
> or as an official confirmation of any transaction. All market prices, data
> and other information are not warranted as to completeness or accuracy and
> are subject to change without notice. Any comments or statements made
herein
> do not necessarily reflect those of J.P. Morgan Chase & Co., its
> subsidiaries and affiliates.
>
>
AW: Implementation-independent services...
Posted by Stefan Henke <st...@gmx.de>.
Hi,
your idea is right. You should define an interface in wsdl for your service.
Everybody who wants can download this definition and create a soap-service
with any language he wants.
Addiotionally, you can use uddi to discover the implementations and
advertise your interface. But this is a bit more complicated. If you want to
know it, just tell me.
Stefan
-----Ursprungliche Nachricht-----
Von: hughes_shawn@jpmorgan.com [mailto:hughes_shawn@jpmorgan.com]
Gesendet: Mittwoch, 30. Januar 2002 19:14
An: soap-user@xml.apache.org
Betreff: Implementation-independent services...
This is probably a pretty basic question but I'm not sure I should be
implementing what the specification for the project defines...
I am creating a system where different development groups are implementing
a pre-defined SOAP service. It's possible that the service implementors
will not use Java. There is a defined API for the SOAP service as follows:
String getPublication( PublicationInputModel pim, EntitlementsModel em)
The original architect specified that the objects should be passed in as
XML instead of objects to support a non-Java SOAP service implementations.
It seems to me that I should just publish the generated WSDL to the service
implementors and that should be sufficient for them to implement the
service in any language. Is that the correct way to do this? It also
appears that using XML inputs (vs. objects) hampers discovery of services
in a UDDI repository.
Thanks,
Shawn.
This communication is for informational purposes only. It is not intended
as
an offer or solicitation for the purchase or sale of any financial
instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.
Installing apache soap and axis?
Posted by "Walter G. da Cruz" <wd...@pacbell.net>.
Quick question:
I have Apache SOAP 2.2 up and running on my Linux box. Is there any
issues/concern if I also install Apache Axis on the same machine? I will
appreciate any help on this.
Thank you, Walter
--
"If we were logical, the future would be bleak |
indeed. But we are more than logical. We are |(408)294-4750
human beings, and we have faith, and we have |wdacruz@pacbell.net
hope, and we can work." -Jacques Cousteau |http://www.wdacruz.com
-----------------------------------------------|----------------------
Installing apache soap and axis?
Posted by "Walter G. da Cruz" <wd...@pacbell.net>.
Quick question:
I have Apache SOAP 2.2 up and running on my Linux box. Is there any
issues/concern if I also install Apache Axis on the same machine? I will
appreciate any help on this.
Thank you, Walter
--
"If we were logical, the future would be bleak |
indeed. But we are more than logical. We are |(408)294-4750
human beings, and we have faith, and we have |wdacruz@pacbell.net
hope, and we can work." -Jacques Cousteau |http://www.wdacruz.com
-----------------------------------------------|----------------------
RE: Implementation-independent services...
Posted by Anne Thomas Manes <an...@manes.net>.
Shawn,
I'm not sure that I understand your terminology, but my answer assumes
that your term "object inputs" refers to the SOAP RPC style and "XML
inputs" refers to the SOAP Document style.
A SOAP service should be implementation-independent regardless of whether
you are passing XML documents (document style) or invoking methods with
parameters (RPC style). Your WSDL description will describe the structure
of your inputs regardless of the style used. From the WSDL descriptions,
anyone should be able to build clients and/or services using any platform,
language, and toolkit they choose. Assuming that you're using relatively
simple datatypes (string, int, struct, array, etc) as defined by Section 5
of the SOAP spec, pretty much every SOAP stack should be able to encode
and decode your objects. Document style generally requires the application
to convert the input string from XML into the appropriate lanuage objects.
RPC does the conversion automatically. Most people view RPC style as
simpler.
Document or RPC style shouldn't have any bearing on UDDI queries. UDDI
doesn't indicate this level of detail about your service. In UDDI you
create a tModel to represent the service type, and this tModel points to
your WSDL description. You can classify your service type with taxonomies
to help people find the tModel. UDDI supplies standard taxonomies for
industry and product codes and for geographical locations. In UDDI V2
you can define your own taxonomies. You can also classify a tModel using
other tModels. But you would not be able to find a tModel based on the
objects it supports unless you create tModels for each of these objects,
and then somehow manage to relay information about all of these tModels
to everyone who might want to use them for searching purposes.
Best regards,
Anne Thomas Manes
CTO, Systinet
www.systinet.com
> -----Original Message-----
> From: hughes_shawn@jpmorgan.com [mailto:hughes_shawn@jpmorgan.com]
> Sent: Wednesday, January 30, 2002 10:14 AM
> To: soap-user@xml.apache.org
> Subject: Implementation-independent services...
>
>
> This is probably a pretty basic question but I'm not sure I should be
> implementing what the specification for the project defines...
>
> I am creating a system where different development groups are implementing
> a pre-defined SOAP service. It's possible that the service implementors
> will not use Java. There is a defined API for the SOAP service
> as follows:
>
> String getPublication( PublicationInputModel pim, EntitlementsModel em)
>
> The original architect specified that the objects should be passed in as
> XML instead of objects to support a non-Java SOAP service implementations.
> It seems to me that I should just publish the generated WSDL to
> the service
> implementors and that should be sufficient for them to implement the
> service in any language. Is that the correct way to do this? It also
> appears that using XML inputs (vs. objects) hampers discovery of services
> in a UDDI repository.
>
> Thanks,
> Shawn.
>
>
> This communication is for informational purposes only. It is not
> intended as
> an offer or solicitation for the purchase or sale of any
> financial instrument
> or as an official confirmation of any transaction. All market prices, data
> and other information are not warranted as to completeness or accuracy and
> are subject to change without notice. Any comments or statements
> made herein
> do not necessarily reflect those of J.P. Morgan Chase & Co., its
> subsidiaries and affiliates.
>
AW: Implementation-independent services...
Posted by Stefan Henke <st...@gmx.de>.
Hi,
your idea is right. You should define an interface in wsdl for your service.
Everybody who wants can download this definition and create a soap-service
with any language he wants.
Addiotionally, you can use uddi to discover the implementations and
advertise your interface. But this is a bit more complicated. If you want to
know it, just tell me.
Stefan
-----Ursprungliche Nachricht-----
Von: hughes_shawn@jpmorgan.com [mailto:hughes_shawn@jpmorgan.com]
Gesendet: Mittwoch, 30. Januar 2002 19:14
An: soap-user@xml.apache.org
Betreff: Implementation-independent services...
This is probably a pretty basic question but I'm not sure I should be
implementing what the specification for the project defines...
I am creating a system where different development groups are implementing
a pre-defined SOAP service. It's possible that the service implementors
will not use Java. There is a defined API for the SOAP service as follows:
String getPublication( PublicationInputModel pim, EntitlementsModel em)
The original architect specified that the objects should be passed in as
XML instead of objects to support a non-Java SOAP service implementations.
It seems to me that I should just publish the generated WSDL to the service
implementors and that should be sufficient for them to implement the
service in any language. Is that the correct way to do this? It also
appears that using XML inputs (vs. objects) hampers discovery of services
in a UDDI repository.
Thanks,
Shawn.
This communication is for informational purposes only. It is not intended
as
an offer or solicitation for the purchase or sale of any financial
instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.
RE: Implementation-independent services...
Posted by Anne Thomas Manes <an...@manes.net>.
Shawn,
I'm not sure that I understand your terminology, but my answer assumes
that your term "object inputs" refers to the SOAP RPC style and "XML
inputs" refers to the SOAP Document style.
A SOAP service should be implementation-independent regardless of whether
you are passing XML documents (document style) or invoking methods with
parameters (RPC style). Your WSDL description will describe the structure
of your inputs regardless of the style used. From the WSDL descriptions,
anyone should be able to build clients and/or services using any platform,
language, and toolkit they choose. Assuming that you're using relatively
simple datatypes (string, int, struct, array, etc) as defined by Section 5
of the SOAP spec, pretty much every SOAP stack should be able to encode
and decode your objects. Document style generally requires the application
to convert the input string from XML into the appropriate lanuage objects.
RPC does the conversion automatically. Most people view RPC style as
simpler.
Document or RPC style shouldn't have any bearing on UDDI queries. UDDI
doesn't indicate this level of detail about your service. In UDDI you
create a tModel to represent the service type, and this tModel points to
your WSDL description. You can classify your service type with taxonomies
to help people find the tModel. UDDI supplies standard taxonomies for
industry and product codes and for geographical locations. In UDDI V2
you can define your own taxonomies. You can also classify a tModel using
other tModels. But you would not be able to find a tModel based on the
objects it supports unless you create tModels for each of these objects,
and then somehow manage to relay information about all of these tModels
to everyone who might want to use them for searching purposes.
Best regards,
Anne Thomas Manes
CTO, Systinet
www.systinet.com
> -----Original Message-----
> From: hughes_shawn@jpmorgan.com [mailto:hughes_shawn@jpmorgan.com]
> Sent: Wednesday, January 30, 2002 10:14 AM
> To: soap-user@xml.apache.org
> Subject: Implementation-independent services...
>
>
> This is probably a pretty basic question but I'm not sure I should be
> implementing what the specification for the project defines...
>
> I am creating a system where different development groups are implementing
> a pre-defined SOAP service. It's possible that the service implementors
> will not use Java. There is a defined API for the SOAP service
> as follows:
>
> String getPublication( PublicationInputModel pim, EntitlementsModel em)
>
> The original architect specified that the objects should be passed in as
> XML instead of objects to support a non-Java SOAP service implementations.
> It seems to me that I should just publish the generated WSDL to
> the service
> implementors and that should be sufficient for them to implement the
> service in any language. Is that the correct way to do this? It also
> appears that using XML inputs (vs. objects) hampers discovery of services
> in a UDDI repository.
>
> Thanks,
> Shawn.
>
>
> This communication is for informational purposes only. It is not
> intended as
> an offer or solicitation for the purchase or sale of any
> financial instrument
> or as an official confirmation of any transaction. All market prices, data
> and other information are not warranted as to completeness or accuracy and
> are subject to change without notice. Any comments or statements
> made herein
> do not necessarily reflect those of J.P. Morgan Chase & Co., its
> subsidiaries and affiliates.
>