Invoke a webservice within the same application

Suppose, an administrator wants to invoke a web service through jsp. Now, my question is; is it a good practice to invoke the web service through jsp within the same application (in which web services are defined)?

jsp within the same application (in which web services are defined)?

would that not be a local call? why do you need to call webservice if its local ?

It is not a good idea.
Web service is expensive as it involves forming a verbose XML (SOAP), marshalling and unmarshalling and serialization and deserialization.

Regards,
Vivek
http://towardssoa.wordpress.com

Hi Sarah,
There is nothing stopping if you use webservices within a same application if you see it's beneficial in a long run, e.g. may be some other client will call that web service. Depending on the complexity of data structures sent and received by the web service, you may want to decide what kind of web service to use SOAP or REST or JMS etc.

Vivek Raut wrote:Web service is expensive as it involves forming a verbose XML (SOAP), marshalling and unmarshalling and serialization and deserialization.

That is an over-generalization. Not all web services use SOAP.

Thanks to all for the responses!

In my application, web services are using SOAP. There are other clients also that are invoking these web services. The administrator of the organization (there is a central authority in this case)has to call some web services that's why I was asking whether it is a good practice or not to:

1. Create a separate client application for the administrator of the organization to invoke the required web services.

2. make a local call through JSP within the same application

The WS must call some internal operation (considering business logic isn't implemented inside it lol).

So why don't you just call that same operation directly?

Now, if you wanna develop a separated client, then yes WS is a good solution. WS isn't just for people that can't access your software directly, it can be used as a client-server communication.

Hikari Shidou wrote:The WS must call some internal operation (considering business logic isn't implemented inside it lol).

So why don't you just call that same operation directly?

Now, if you wanna develop a separated client, then yes WS is a good solution. WS isn't just for people that can't access your software directly, it can be used as a client-server communication.

As I have mentioned earlier, some operations are called by many users including admin that's why I have defined a web service and included those operations in that web service.

Ok I got that.

But how is your UI? If it's a separated software, WS is a possible solution. But if it's in the same process as your software, it can call those operations directly.

If your software is accessed by many users, you may be wanting to have a server hosting business logic and many clients to interact with users and communicate with your server using WebService, is that it?

Hikari Shidou wrote:Ok I got that.

But how is your UI? If it's a separated software, WS is a possible solution. But if it's in the same process as your software, it can call those operations directly.

If your software is accessed by many users, you may be wanting to have a server hosting business logic and many clients to interact with users and communicate with your server using WebService, is that it?

yes, you are right!!

As far as UI is concerned, this is what I am asking

is it a good practice to call that web service operation within the same application or should I create a separate application (for admin) and then invoke that WS operation?

For other clients, separate applications are developed.

It's kinda hard to understand what you're doing.

Now it seems you have a Servlet-based UI with application layer within it, and you want a backend for admin to manage the software, with features not accessible for normal users.

In that case just develop backend pages and handle access management, all in Servlet or in any technology that's used now.

WebService is recommended just when different technologies are talking, like Java with C#, or when you wanna provide services to ther softwares with possibility of a future software with different technology to use it too. It takes too much time to transfer and process XML building and parsing, it's not the first technology you should consider for any server-client communication.

WebService is recommended just when different technologies are talking, like Java with C#, or when you wanna provide services to ther softwares with possibility of a future software with different technology to use it too. It takes too much time to transfer and process XML building and parsing, it's not the first technology you should consider for any server-client communication.

I beg to differ , web service dose not only mean JAX-WS, JAX-RS is much simpler and light weight.

-P

Praful Thakare wrote:

It takes too much time to transfer and process XML building and parsing, it's not the first technology you should consider for any server-client communication.

I beg to differ , web service dose not only mean JAX-WS, JAX-RS is much simpler and light weight.

It is nevertheless correct that WS -in any form- should not be the default choice for just about client-server communication. There may well be better choices. Or there may not be. It depends too much on the circumstances to make a general recommendation.

Well, building and parsing XML for sure isn't trivial, that's why we have Binary XML and other alternative solutions.

I couldn't find now, but last week I saw a small benchmark comparing SOAP with CORBA, and CORBA is a bit faster. And in the works I've been doing, internal calls that happen instantly take like 200 miliseconds throu WebService.

What I'm talking to him is that Servlet may be a better solution then some Swing (?) client talking via SOAP, and if he'll stay in Java it may be better use RMI.

Hikari Shidou wrote:I saw a small benchmark comparing SOAP with CORBA, and CORBA is a bit faster.

What CORBA is or is not capable of doing is really not relevant at this point in time; it is dead, individual data points indicating its superior performance notwithstanding.

What I'm talking to him is that Servlet may be a better solution then some Swing (?) client talking via SOAP, and if he'll stay in Java it may be better use RMI.

How is a Swing client sending SOAP comparable to a servlet? Heck, a servlet could be used as the target of a SOAP client. Let's not confuse the issue further by throwing in additional technologies that don't constitute a relevant comparison. Same for binary XML (dead for all practical purposes) and RMI (close to being dead, certainly not one of the first choices for new implementations).