We are going to develop webservices for internal use as well as external use. I am trying to find the technology that we should use for internal webservices and external webservices.

1. We run our applications in JOBSS environment. At present we don't have any ESB but we will have one in the future.

2. The communication with our customers is secured by VPN

I want to set the foundation for our webservices making sure that costly mistakes have been avoided. Therefore I need experets' feedback.

To my knowledge web servives use SOAP/HTTP. Is SOAP/HTTP right fit for both external and internal webServices?

I'm trying to find what shold be the technology stack for:
1.  internal web servicec and
2. what should it be for external web Services.

How do we make sure that the business critical request invoked internally is not lost?
How do we make sure that the business critical request invoked by our customers (external)  is not lost?

asked 08/14/2011 09:57

javaCaravan0's gravatar image

javaCaravan0 ♦♦

4 Answers:
SOAP is a common standard in use in the creation of webservices for both internal and external access.

Another consideration is the REST protocol.

There is no issue with using the same technology for both webservices.  The only difference would be in access to services and perhaps security levels.  Your external web servers should be in a DMZ subnet and generally forward operational requests to internal web services, thereby providing a filter between external and internal services.

The next questions is whether to use synchronous or asynchronous communications.  When using synchronous it is easier to implement but suffers from resource hogging and timelimits on response generation.  Asynchronous is better to ensure guaranteed delivery.

To ensure things are not lost either use synchronous and build reliability into the client (doesn't seem to be what you want) or use asynchronous and use reliable-messaging to store-forward your requests.

Running SOAP or REST over an ESB is not an issue and really the ESB should provide your first level entry point to your services.  This allows you to scale your application more easily at a later date if the ESB forwards messages to your service handlers.


sweetfa2's gravatar image


Thank you for the response.

Can you please elaborate on:
“When using synchronous it is easier to implement but suffers from resource hogging and timelimits on response generation”.
Since Asynchronous communication is better to ensure guaranteed delivery, does it mean that I implement SOAP/JMS? How should I make the distinction what to use i.e. SOAP/JMS or SOAP/HTTP. Which one should be used externally? I think internally one should always use SOAP/JMS for guaranteed delivery, please correct me .

answered 2011-08-17 at 02:40:36

javaCaravan0's gravatar image


Synchronous is like you asking me to do something and sitting waiting for me to respond.  Therefore, the whole time you are waiting for me to respond you are unavailable to do something else.  That is the resource tie up issue.  You will get bored with waiting for me, and most systems are configured at 5 minute boredom threshold, so that is what is meant by timelimit responses.

Depending on the type of service you are providing ie. query service would more likely be synchronous whereas a notification would more likely be asynchronous or have no response generated.

Queries would best be served using SOAP/HTTP whereas notification type messages would more likely be SOAP/JMS.

answered 2011-08-17 at 07:42:43

sweetfa2's gravatar image


This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.


answered 2011-08-17 at 13:29:00

mwvisa1's gravatar image


Your answer
[hide preview]

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments



Asked: 08/14/2011 09:57

Seen: 297 times

Last updated: 10/07/2011 09:21