Win a copy of Micro Frontends in Action this week in the Server-Side JavaScript and NodeJS forum!

David Bueche

Greenhorn
+ Follow
since Oct 08, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by David Bueche

Mark,

Like you, I have found that trying to get my arms around Web Services has been about as easy as bathing a small herd of cats.

One of my disappointments has been the lack of clear high level documentation on either JAX-WS or Apache Muse. I see that the focus of your book is primarly JAX-WS (as opposed to Muse). In general, do you delve right into an example, or first provide some amount of discussion on the high level interactions of the base JAX-WS classes so the reader can better understand how the example works within the JAX-WS infrastructure and how to specialize the default web service behavior (special handlers, subscription handling/interception, etc.)?

Thanks,
-David Bueche
13 years ago
Mark,

In the area of "pixie dust", do you discuss in your book any JAX-WS approach for generating a WSDL from Java classes, then generate the Web Service from that (or even a single-step approach that does both of these)?

Also, do you do any comparisons between JAX-WS and Apache Muse regarding pros and cons for writing WS-Notification services?

Thanks,
-David
13 years ago
It looks like your examples are not something that Web Services should look to solve, but should be handled by the interfacing client app or in the deployment plan:

Example 1: A denial of service attack is not unique to web services and should be handled like any other denial of service attack (blocking the requestor or other approach to shut down a denial of service attack, be it HTTP or some other protocol).

Example 2: A Web Service crash/malfunction should be handled by the client application the same as a crash/malfunction of any other Servlet, server, or other outside application with which a client application must interface. E.g., if your application invokes a Google search engine and Google's servers crash, your application must deal with it as it deems best (displaying an error or informational message, using an alternate service, etc.

Example 3: This is a migration/deployment issue, rather than a technology issue. A responsible provider of web services would provide a migration path for it's customers/consumers. If the protocol or API changes, both versions of the service service could be provided for a time (a new URL for the new version) with the phase out of the old service advertised well in advance, including a termination date. Customers should be notified periodically, including an urgent notice the day before the termination of the old service. Of course, in some cases, it may be beneficial to continue supporting the old service for a more extended period of time or indefinitely.

-David
13 years ago
My employer does not allow us access directly to our proxy server, but requires that we use a script. I was able to obtain the name of a "depricated" proxy server that they will soon be shutting down. The following code works fine:

WebConversation conversation = new WebConversation();
conversation.setProxyServer("<proxyServerName>",
<portGoesHere>,
"<myIdGoesHere>",
"<myPasswordGoesHere>");
WebRequest request = new GetMethodWebRequest
("<urlAccessedGoesHere>");
WebResponse response = conversation.getResponse(request);

However, when I use the <proxyScriptName> instead of <proxyServerName>, all I get back is an empty page in my response.

Has anyone encountered or found a work-around for this issue before with HttpUnit (or similar tools)?

Thanks,
-David
15 years ago