You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@ws.apache.org by P Sreenivasa Rao <ps...@cmcltd.com> on 2001/06/12 13:21:32 UTC
performance issues in Web Services
Hi all,
I have some doubts regarding the performance issues(u can call them as disadvntages ) of Web Services.
Actually,we'll depend on the performnace of Service Provider in web services.So in the internet scenario,the performance will be a bottleneck as it'll take much time (due to more no of hops or more traffic to SP etc) to get response.
Another thing, I dont know the necessity of request broker in the web serives scenario.Is it replaced by UDDI registry or UDDI registry is the implementation of request broker?Is there any public UDDI registry available? I tried with IBM's site but I dint get the actaul link pointed in their documentation.
Finally,what are the other advantages and bottlenecks in this Web serivces scenario.
Thanks a lot for one and all.
Awaiting your early response.
Thanks and regards,
Sreenivas,CMCLtd
Re: performance issues in Web Services
Posted by Araf Karsh Hamid <ka...@netforensics.com>.
Hi Rao,
Can u clarify, what u mean by performance issues of Web Services?
Web services are nothing but an open standard for bringing island of
closed networks to communicate on the net. Its nothing but an RPC
mechanism (XML over HTTP/SMTP)
Karsh
P Sreenivasa Rao wrote:
> Hi all,I have some doubts regarding the performance issues(u can call
> them as disadvntages ) of Web Services.Actually,we'll depend on the
> performnace of Service Provider in web services.So in the internet
> scenario,the performance will be a bottleneck as it'll take much time
> (due to more no of hops or more traffic to SP etc) to get response.
>
> Another thing, I dont know the necessity of request broker in the web
> serives scenario.Is it replaced by UDDI registry or UDDI registry is
> the implementation of request broker?Is there any public UDDI registry
> available? I tried with IBM's site but I dint get the actaul link
> pointed in their documentation. Finally,what are the other advantages
> and bottlenecks in this Web serivces scenario.
> Thanks a lot for one and all.Awaiting your early response.Thanks and
> regards,Sreenivas,CMCLtd
RE: performance issues in Web Services
Posted by Frank Feldmann <fr...@silverstream.be>.
You don't have a request broker.
Once you know the service details (obtained through UDDI) you
just call it directly.
It's kind of similar to the ORB scenario's in Corba, but the
client doesn't have a stub and the server doesn't have a skeleton.
Or at least in most SOAP implementations that is.
SilverStream introduced the RMI programming model to SOAP
using JBroker web. (http://extend.silverstream.com/)
So instead of building an Call object and setting the method
and params you would like to call you just work with a
local object and call method on the object. The plumming
code will the actuall take care of constructing a proper soap
call out of this.
The eXtend Workbench also provides you with the tools to just
generate this stub skeleton stuff (or just a client based on
a WSDL file).
Take a look it is really nice stuff and it interoperates with
Apache and MS as well, runs on Tomcat, BEA, SilverStream...and
it is for free.
Frank
-----Original Message-----
From: Ryan Tomayko [mailto:ryant@mad.scientist.com]
Sent: Friday, June 15, 2001 1:38 PM
To: soap-user@xml.apache.org
Subject: RE: performance issues in Web Services
It's a trade-off. I wouldn't suggest using SOAP based web services over the
public Internet if you have some other solution that meets your
requirements. However, web services solve a specific problem that is
currently unsolvable otherwise:
1. Interoperability between platforms/languages. (Debatable at present)
2. Firewall friendly Internet RPC.
If these are requirements of your situation than you don't have much choice
outside of web services--without rolling your own binary protocol
implementation for performance. If you need RPC, but don't require the
interop or internet then check out some other RPC technology, such as RMI,
CORBA, DCOM.
As for the request broker/UDDI thing, I don't have a clue what your talking
about.
- Ryan
-----Original Message-----
From: P Sreenivasa Rao [mailto:psrao@cmcltd.com]
Sent: Tuesday, June 12, 2001 7:22 AM
To: soap-user@xml.apache.org
Cc: soap-dev@xml.apache.org; SOAP@DISCUSS.DEVELOP.COM
Subject: performance issues in Web Services
Hi all,
I have some doubts regarding the performance issues(u can call them as
disadvntages ) of Web Services.
Actually,we'll depend on the performnace of Service Provider in web
services.So in the internet scenario,the performance will be a bottleneck as
it'll take much time (due to more no of hops or more traffic to SP etc) to
get response.
Another thing, I dont know the necessity of request broker in the web
serives scenario.Is it replaced by UDDI registry or UDDI registry is the
implementation of request broker?Is there any public UDDI registry
available? I tried with IBM's site but I dint get the actaul link pointed in
their documentation.
Finally,what are the other advantages and bottlenecks in this Web serivces
scenario.
Thanks a lot for one and all.
Awaiting your early response.
Thanks and regards,
Sreenivas,CMCLtd
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Frank Feldmann
Manager eBusiness Strategy
SilverStream Software EMEA
Mobile : +31 622429856
e-mail: frank@silverstream.be
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: performance issues in Web Services
Posted by Frank Feldmann <fr...@silverstream.be>.
You don't have a request broker.
Once you know the service details (obtained through UDDI) you
just call it directly.
It's kind of similar to the ORB scenario's in Corba, but the
client doesn't have a stub and the server doesn't have a skeleton.
Or at least in most SOAP implementations that is.
SilverStream introduced the RMI programming model to SOAP
using JBroker web. (http://extend.silverstream.com/)
So instead of building an Call object and setting the method
and params you would like to call you just work with a
local object and call method on the object. The plumming
code will the actuall take care of constructing a proper soap
call out of this.
The eXtend Workbench also provides you with the tools to just
generate this stub skeleton stuff (or just a client based on
a WSDL file).
Take a look it is really nice stuff and it interoperates with
Apache and MS as well, runs on Tomcat, BEA, SilverStream...and
it is for free.
Frank
-----Original Message-----
From: Ryan Tomayko [mailto:ryant@mad.scientist.com]
Sent: Friday, June 15, 2001 1:38 PM
To: soap-user@xml.apache.org
Subject: RE: performance issues in Web Services
It's a trade-off. I wouldn't suggest using SOAP based web services over the
public Internet if you have some other solution that meets your
requirements. However, web services solve a specific problem that is
currently unsolvable otherwise:
1. Interoperability between platforms/languages. (Debatable at present)
2. Firewall friendly Internet RPC.
If these are requirements of your situation than you don't have much choice
outside of web services--without rolling your own binary protocol
implementation for performance. If you need RPC, but don't require the
interop or internet then check out some other RPC technology, such as RMI,
CORBA, DCOM.
As for the request broker/UDDI thing, I don't have a clue what your talking
about.
- Ryan
-----Original Message-----
From: P Sreenivasa Rao [mailto:psrao@cmcltd.com]
Sent: Tuesday, June 12, 2001 7:22 AM
To: soap-user@xml.apache.org
Cc: soap-dev@xml.apache.org; SOAP@DISCUSS.DEVELOP.COM
Subject: performance issues in Web Services
Hi all,
I have some doubts regarding the performance issues(u can call them as
disadvntages ) of Web Services.
Actually,we'll depend on the performnace of Service Provider in web
services.So in the internet scenario,the performance will be a bottleneck as
it'll take much time (due to more no of hops or more traffic to SP etc) to
get response.
Another thing, I dont know the necessity of request broker in the web
serives scenario.Is it replaced by UDDI registry or UDDI registry is the
implementation of request broker?Is there any public UDDI registry
available? I tried with IBM's site but I dint get the actaul link pointed in
their documentation.
Finally,what are the other advantages and bottlenecks in this Web serivces
scenario.
Thanks a lot for one and all.
Awaiting your early response.
Thanks and regards,
Sreenivas,CMCLtd
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Frank Feldmann
Manager eBusiness Strategy
SilverStream Software EMEA
Mobile : +31 622429856
e-mail: frank@silverstream.be
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: performance issues in Web Services
Posted by Ryan Tomayko <ry...@mad.scientist.com>.
It's a trade-off. I wouldn't suggest using SOAP based web services over the
public Internet if you have some other solution that meets your
requirements. However, web services solve a specific problem that is
currently unsolvable otherwise:
1. Interoperability between platforms/languages. (Debatable at present)
2. Firewall friendly Internet RPC.
If these are requirements of your situation than you don't have much choice
outside of web services--without rolling your own binary protocol
implementation for performance. If you need RPC, but don't require the
interop or internet then check out some other RPC technology, such as RMI,
CORBA, DCOM.
As for the request broker/UDDI thing, I don't have a clue what your talking
about.
- Ryan
-----Original Message-----
From: P Sreenivasa Rao [mailto:psrao@cmcltd.com]
Sent: Tuesday, June 12, 2001 7:22 AM
To: soap-user@xml.apache.org
Cc: soap-dev@xml.apache.org; SOAP@DISCUSS.DEVELOP.COM
Subject: performance issues in Web Services
Hi all,
I have some doubts regarding the performance issues(u can call them as
disadvntages ) of Web Services.
Actually,we'll depend on the performnace of Service Provider in web
services.So in the internet scenario,the performance will be a bottleneck as
it'll take much time (due to more no of hops or more traffic to SP etc) to
get response.
Another thing, I dont know the necessity of request broker in the web
serives scenario.Is it replaced by UDDI registry or UDDI registry is the
implementation of request broker?Is there any public UDDI registry
available? I tried with IBM's site but I dint get the actaul link pointed in
their documentation.
Finally,what are the other advantages and bottlenecks in this Web serivces
scenario.
Thanks a lot for one and all.
Awaiting your early response.
Thanks and regards,
Sreenivas,CMCLtd
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: performance issues in Web Services
Posted by Anne Thomas Manes <at...@sun.com>.
Sreenivasa,
I'll let others respond to the performance questions, but I'm happy to tell
you about UDDI.
UDDI is a static registry of businesses and services, not an object request
broker. You use UDDI to find a business that offers the kind of service you
want, and then to find information on how to make use of that service --
such as a description of the web service interface (such as a WSDL file),
the access point used to invoke the service (a URL), and any other
information that you might need to negotiate a contract with the service
provider (contact information, terms and conditions, quality of service
requirements, etc.).
You use UDDI to find the information that you need to build an interface to
talk to a web service. Although some might argue that you can use UDDI to
dynamically connect to services at runtime, for most practical purposes,
UDDI is a design-time discovery service. UDDI does not return a client
proxy -- you have to construct your client proxy from the information you
retrieve from UDDI.
There is a public UDDI registry called the UDDI Business Registry (UBR). The
UBR is currently hosted by IBM and Microsoft. Each company hosts a complete
replica of the registry, so it doesn't matter which one you access. You can
find lots of information about UDDI, including the programmers reference, at
www.uddi.org.
You can play with UDDI by going to either the IBM or Microsoft UDDI web
pages:
http://www-3.ibm.com/services/uddi/
http://uddi.microsoft.com
You can also interface with the UBR nodes programmatically using SOAP
messages. Query the UBR registry and search for IBM or Microsoft and find
the service descriptions for their UDDI Business Registry services. (note:
the UBR is a web service)
You can also set up a private UDDI registry to experiment with. I know of
four different UDDI server implementations (all are free at the moment):
- http://www.alphaworks.ibm.com/tech/webservicestoolkit
- http://www.idoox.com/products/wasp_uddi/download/index.html
- http://www.themindelectric.com/products/download/download.html
- http://sourceforge.net/projects/uddi/ (see also www.juddi.org)
The juddi.org project is open source (BSD-style license)
You also might want to join the UDDI discussion lists, hosted by Yahoo
Groups. See http://groups.yahoo.com. The UDDI groups are:
- uddi-general
- uddi-technical
Regards,
Anne Thomas Manes
Sun Microsystems
-----Original Message-----
From: P Sreenivasa Rao [mailto:psrao@cmcltd.com]
Sent: Tuesday, June 12, 2001 4:22 AM
To: soap-user@xml.apache.org
Cc: soap-dev@xml.apache.org; SOAP@DISCUSS.DEVELOP.COM
Subject: performance issues in Web Services
Hi all,
I have some doubts regarding the performance issues(u can call them as
disadvntages ) of Web Services.
Actually,we'll depend on the performnace of Service Provider in web
services.So in the internet scenario,the performance will be a bottleneck as
it'll take much time (due to more no of hops or more traffic to SP etc) to
get response.
Another thing, I dont know the necessity of request broker in the web
serives scenario.Is it replaced by UDDI registry or UDDI registry is the
implementation of request broker?Is there any public UDDI registry
available? I tried with IBM's site but I dint get the actaul link pointed in
their documentation.
Finally,what are the other advantages and bottlenecks in this Web serivces
scenario.
Thanks a lot for one and all.
Awaiting your early response.
Thanks and regards,
Sreenivas,CMCLtd
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Deployment descriptor file implementation
Posted by Frederic Jeanne <fj...@symetrx.com>.
Hello all,
Are there any reasons that the current implementation of Apache SOAP
deployment descriptor files doesn't allow the declaration of multiple
services in an unique dd file ?
Thanks,
FJ.
RE: performance issues in Web Services
Posted by Ryan Tomayko <ry...@mad.scientist.com>.
It's a trade-off. I wouldn't suggest using SOAP based web services over the
public Internet if you have some other solution that meets your
requirements. However, web services solve a specific problem that is
currently unsolvable otherwise:
1. Interoperability between platforms/languages. (Debatable at present)
2. Firewall friendly Internet RPC.
If these are requirements of your situation than you don't have much choice
outside of web services--without rolling your own binary protocol
implementation for performance. If you need RPC, but don't require the
interop or internet then check out some other RPC technology, such as RMI,
CORBA, DCOM.
As for the request broker/UDDI thing, I don't have a clue what your talking
about.
- Ryan
-----Original Message-----
From: P Sreenivasa Rao [mailto:psrao@cmcltd.com]
Sent: Tuesday, June 12, 2001 7:22 AM
To: soap-user@xml.apache.org
Cc: soap-dev@xml.apache.org; SOAP@DISCUSS.DEVELOP.COM
Subject: performance issues in Web Services
Hi all,
I have some doubts regarding the performance issues(u can call them as
disadvntages ) of Web Services.
Actually,we'll depend on the performnace of Service Provider in web
services.So in the internet scenario,the performance will be a bottleneck as
it'll take much time (due to more no of hops or more traffic to SP etc) to
get response.
Another thing, I dont know the necessity of request broker in the web
serives scenario.Is it replaced by UDDI registry or UDDI registry is the
implementation of request broker?Is there any public UDDI registry
available? I tried with IBM's site but I dint get the actaul link pointed in
their documentation.
Finally,what are the other advantages and bottlenecks in this Web serivces
scenario.
Thanks a lot for one and all.
Awaiting your early response.
Thanks and regards,
Sreenivas,CMCLtd
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: performance issues in Web Services
Posted by Anne Thomas Manes <at...@sun.com>.
Sreenivasa,
I'll let others respond to the performance questions, but I'm happy to tell
you about UDDI.
UDDI is a static registry of businesses and services, not an object request
broker. You use UDDI to find a business that offers the kind of service you
want, and then to find information on how to make use of that service --
such as a description of the web service interface (such as a WSDL file),
the access point used to invoke the service (a URL), and any other
information that you might need to negotiate a contract with the service
provider (contact information, terms and conditions, quality of service
requirements, etc.).
You use UDDI to find the information that you need to build an interface to
talk to a web service. Although some might argue that you can use UDDI to
dynamically connect to services at runtime, for most practical purposes,
UDDI is a design-time discovery service. UDDI does not return a client
proxy -- you have to construct your client proxy from the information you
retrieve from UDDI.
There is a public UDDI registry called the UDDI Business Registry (UBR). The
UBR is currently hosted by IBM and Microsoft. Each company hosts a complete
replica of the registry, so it doesn't matter which one you access. You can
find lots of information about UDDI, including the programmers reference, at
www.uddi.org.
You can play with UDDI by going to either the IBM or Microsoft UDDI web
pages:
http://www-3.ibm.com/services/uddi/
http://uddi.microsoft.com
You can also interface with the UBR nodes programmatically using SOAP
messages. Query the UBR registry and search for IBM or Microsoft and find
the service descriptions for their UDDI Business Registry services. (note:
the UBR is a web service)
You can also set up a private UDDI registry to experiment with. I know of
four different UDDI server implementations (all are free at the moment):
- http://www.alphaworks.ibm.com/tech/webservicestoolkit
- http://www.idoox.com/products/wasp_uddi/download/index.html
- http://www.themindelectric.com/products/download/download.html
- http://sourceforge.net/projects/uddi/ (see also www.juddi.org)
The juddi.org project is open source (BSD-style license)
You also might want to join the UDDI discussion lists, hosted by Yahoo
Groups. See http://groups.yahoo.com. The UDDI groups are:
- uddi-general
- uddi-technical
Regards,
Anne Thomas Manes
Sun Microsystems
-----Original Message-----
From: P Sreenivasa Rao [mailto:psrao@cmcltd.com]
Sent: Tuesday, June 12, 2001 4:22 AM
To: soap-user@xml.apache.org
Cc: soap-dev@xml.apache.org; SOAP@DISCUSS.DEVELOP.COM
Subject: performance issues in Web Services
Hi all,
I have some doubts regarding the performance issues(u can call them as
disadvntages ) of Web Services.
Actually,we'll depend on the performnace of Service Provider in web
services.So in the internet scenario,the performance will be a bottleneck as
it'll take much time (due to more no of hops or more traffic to SP etc) to
get response.
Another thing, I dont know the necessity of request broker in the web
serives scenario.Is it replaced by UDDI registry or UDDI registry is the
implementation of request broker?Is there any public UDDI registry
available? I tried with IBM's site but I dint get the actaul link pointed in
their documentation.
Finally,what are the other advantages and bottlenecks in this Web serivces
scenario.
Thanks a lot for one and all.
Awaiting your early response.
Thanks and regards,
Sreenivas,CMCLtd
RE: performance issues in Web Services
Posted by Anne Thomas Manes <at...@sun.com>.
Sreenivasa,
I'll let others respond to the performance questions, but I'm happy to tell
you about UDDI.
UDDI is a static registry of businesses and services, not an object request
broker. You use UDDI to find a business that offers the kind of service you
want, and then to find information on how to make use of that service --
such as a description of the web service interface (such as a WSDL file),
the access point used to invoke the service (a URL), and any other
information that you might need to negotiate a contract with the service
provider (contact information, terms and conditions, quality of service
requirements, etc.).
You use UDDI to find the information that you need to build an interface to
talk to a web service. Although some might argue that you can use UDDI to
dynamically connect to services at runtime, for most practical purposes,
UDDI is a design-time discovery service. UDDI does not return a client
proxy -- you have to construct your client proxy from the information you
retrieve from UDDI.
There is a public UDDI registry called the UDDI Business Registry (UBR). The
UBR is currently hosted by IBM and Microsoft. Each company hosts a complete
replica of the registry, so it doesn't matter which one you access. You can
find lots of information about UDDI, including the programmers reference, at
www.uddi.org.
You can play with UDDI by going to either the IBM or Microsoft UDDI web
pages:
http://www-3.ibm.com/services/uddi/
http://uddi.microsoft.com
You can also interface with the UBR nodes programmatically using SOAP
messages. Query the UBR registry and search for IBM or Microsoft and find
the service descriptions for their UDDI Business Registry services. (note:
the UBR is a web service)
You can also set up a private UDDI registry to experiment with. I know of
four different UDDI server implementations (all are free at the moment):
- http://www.alphaworks.ibm.com/tech/webservicestoolkit
- http://www.idoox.com/products/wasp_uddi/download/index.html
- http://www.themindelectric.com/products/download/download.html
- http://sourceforge.net/projects/uddi/ (see also www.juddi.org)
The juddi.org project is open source (BSD-style license)
You also might want to join the UDDI discussion lists, hosted by Yahoo
Groups. See http://groups.yahoo.com. The UDDI groups are:
- uddi-general
- uddi-technical
Regards,
Anne Thomas Manes
Sun Microsystems
-----Original Message-----
From: P Sreenivasa Rao [mailto:psrao@cmcltd.com]
Sent: Tuesday, June 12, 2001 4:22 AM
To: soap-user@xml.apache.org
Cc: soap-dev@xml.apache.org; SOAP@DISCUSS.DEVELOP.COM
Subject: performance issues in Web Services
Hi all,
I have some doubts regarding the performance issues(u can call them as
disadvntages ) of Web Services.
Actually,we'll depend on the performnace of Service Provider in web
services.So in the internet scenario,the performance will be a bottleneck as
it'll take much time (due to more no of hops or more traffic to SP etc) to
get response.
Another thing, I dont know the necessity of request broker in the web
serives scenario.Is it replaced by UDDI registry or UDDI registry is the
implementation of request broker?Is there any public UDDI registry
available? I tried with IBM's site but I dint get the actaul link pointed in
their documentation.
Finally,what are the other advantages and bottlenecks in this Web serivces
scenario.
Thanks a lot for one and all.
Awaiting your early response.
Thanks and regards,
Sreenivas,CMCLtd
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org