There is a nice separation between application processing and
infrastructure processing. WSDL describes the former and WS-Policy
describe the later.
If you are writing application code, you shouldn't care about WS-Policy
(and WS-Security), you only care about WSDL. The underlying
this to the client?
Clearly, I need to supply something more than a WSDL
document to the client. Even if the client has an
underlying infrastructure (e.g. a security gateway) it
needs some sort of information. Does WS-Policy provide
that?
Thanks,
Shantanu Sen
--- Ricky Ho [EMAIL PROTECTED] wrote
just has to notify the event to a client
who registered oneself as the event listener.
Best Regards,
Toshi (Toshiyuki Kimura) [EMAIL PROTECTED]
RD Headquarters
NTT DATA Corporation
-Original Message-
From: Ricky Ho [mailto:[EMAIL PROTECTED]
Sent: Monday, March 17, 2003 4:41 PM
One of the primary reasons why you might want to use SAML is to support
single sign-on. But if you don't have a SAML authentication authority, then
you probably don't want to use SAML.
Can I use SAML for just Authorization Authority ?
But you don't need to use either SAML or WS-Security to
We certainly can use a Gnutella approach to multi-cast an event.
Rgds, Ricky
At 10:15 AM 3/17/2003 -0800, Steve Loughran wrote:
- Original Message -
From: Ricky Ho [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, March 17, 2003 09:47
Subject: Re: Callbacks
A SOAP client registers with a SOAP server: send me a message when event
XYZ occurs
The client should register: send me a message AT THIS LOCATION when the
event XYZ occurs
When XYZ occurs, how should the server callback? Is there anything
provided as part of the Axis framework?
The server
Note that I'm comparing UDP multicast with sending a message repeatedly
over multiple HTTP/TCP connections.
1)Reliability: The UDP packets might be lost depending on the network
conditions, as you may know.
As I said, the callback message in this application-specific case is
and faster.
- Dennis
Ricky Ho wrote:
Thanks Dennis, some more followup question
Is it true that Pull Parser is also a forward-only iterator ? The only
difference that I see is still that Pull Parser allows you to stop
anytime. Maybe lets go through an example as follows ...
Look
Tom, my comments embedded
My impression (until this discussion started) was that both are linear
in input, able to quit at any point, but the difference was three-fold
(a) since SAX events are context-independent, and the logic of XML
often depends on what has gone before it, event handlers
Got it ! Thanks
At 04:39 PM 2/21/2003 +, you wrote:
Ricky Ho wrote:
At the Parser side, in both XPP and SAX code case, the parser deliver
the same number of elements to the application sequentially (regardless
of whether the application ask for it or the parser callback the
application
Few months ago, I run into the same issue when I try to implement a cache
handler. The answer I got back from Steve is the only way to stop the
handler passing on the request is to throw an exception, in that case a
SOAP Fault is send back to client.
I guess this behavior is still the same
Would it be nice to no requiring the TCPTunnel to define the target address
and port ?
For example, I have a client application which dynamically determine the
service endpoint address (via UDDI), there is NO way that I can setup the
TCPTunnel to monitor the traffic between the client app and
://www.javaworld.com/javaworld/jw-04-2002/jw-0426-xmljava3.html?
Anne
-Original Message-
From: Ricky Ho [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 10, 2003 10:02 PM
To: Anne Thomas Manes
Subject: RE: Why Pull-Parser faster ?
I don't see they are giving an introduction of how Pull
, [EMAIL PROTECTED]
Researching tomorrow's decisions today.
(319) 369-2070 (work)
SYSTEMS ARCHITECT, ITS, AEGON FINANCIAL PARTNERS
-Original Message-
From: Ricky Ho [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 20, 2003 9:57 AM
To: Anne Thomas Manes
Cc: [EMAIL PROTECTED
is also useful at times, but not that big of a deal (you can always stop a SAX parse by throwing an exception from your handler, after all).
- Dennis
Ricky Ho wrote:
Thanks Annie, but it is still unclear to me why Pull-Parser is faster when the application take control.
Is it because ...
1) Less
Just between SAX and XPP
If SAX can be stopped anytime by throwing an exception, this means the
application can control when to stop. And if XPP is not skipping
whitespace ...
Why XPP is faster than SAX ??
Best regards,
Ricky
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
I definitely appreciate the simplicity and elegance of AXIS handler chain
model. But on the other hand, I also observe some limitations when trying
to build a more sophisticated intermediary processing model on it. I would
like to get a sense if other people hitting the same issues in their
Who is making the Manager.getInstance() call ?
Is it simpler by just declaring the object class in application scope ?
Rgds, Ricky
At 08:25 AM 1/24/2003 -0700, Wes Devauld wrote:
The approach you can take is to create your 'Manager' classes as singletons.
The idea is to make the constructors
I try to add a SOAP header into a SOAP envelope.
1) SOAPEnvelope soapEnv = ;
2) System.out.println(SoapEnv is ..\n + soapEnv);
3) SOAPHeaderElement hdrElement = new SOAPHeaderElement(new
PrefixedQName(myNamespace,someHeader,
prefix));
4) soapEnv.addHeader(hdrElement);
5)
Most Java-based SOAP engine (over HTTP) implementation leverages the
Servlet model which allows you to specify whether the service
implementation object is request, or session, or application scope.
But there is no industry standards around this, and there is no way to
communicate this
You need to tell the client to store all cookies you receive, and resend
it in your next request.
Also, there is nothing in the WSDL telling the client that the state is
maintained in the server side. The fact that session scope is configured
is purely an implementation detail. Therefore, I
Although I assume the session id is locally unique (which is the same
assumption of the HTTPSession), there is NO need for a globally unique
session id across servers. Since the session id is only being used within
a service container to identify a previous client session, it is OK to have
No ! I think the same mechanism works for the scenario you describe here
as well by having the client pass an extra session id for each request it
make. In other words, the client will use different session id for each
different server it contacts.
Rgds, Ricky
At 10:23 AM 11/27/2002 -0800,
As you see in my sample code, I think the right way is NOT to spawn a
thread at the calling client, but have the server immediately return after
buffering the request. In fact, the thread is spawned at the server which
take the request from the buffer to handle at a later time.
At the same
I guess the behavior you observe is implementation dependent. The SOAP
server you've used doesn't take advantage of the optimization opportunity
where things can be execute in parallel.
But you certainly can achieve what you want in the following ways ...
public class AsyncService {
This sounds violate the heterogeneity principle of SOAP. And SOAP has
never define language bindings, so you can only have such guarantee when
using the same vendor's product. And of course, the same Java class need
to be explicitly installed at both side.
I think you should question why you
My previous comment is making in the parameter object (not the service
object). As I mentioned before, SOAP is NOT DESIGN FOR transferring
object behavior across the wire because this is infeasible in a
heterogeneous programming language environment. Think about the
scenario your Java client may
Besides the performance overhead of converting the XML to a byte array and
back, another big minus is the WSDL in this case has lost all the schema
definition. In other words, the client and the server has to use another
channel to communicate what does the detail of the request and response
rather than manipulate the data type to another form.
Rgds, Ricky
At 05:08 PM 10/29/2002 -0500, [EMAIL PROTECTED] wrote:
What I was thinking of was some sort of equivalent - not necesarily the DOM
tree sa I've laid it out here.
Ricky Ho [EMAIL PROTECTED] on 10/29/2002 05:06:49 PM
Please
If you are not the service provider and if the service itself is
synchronous, then the only way is to spawn multiple threads, each making a
synchronous invocation to a different web services.
If you have control on the service, then use an async invocation model, by
splitting the service
You are using different stub for different user. Do you put the each stub
in the HttpSession ? How do you get a particular stub ?
Rgds, Ricky
At 08:21 PM 10/23/2002 -0500, Sandeep G Nijsure wrote:
Hi all,
Could someone plz. explain me the diff between session management using
cookies and
Comments and questions as embedded ...
The second answer (for Axis again) is using HTTP for communications
between the SOAP client and server, but having the SOAP messages be
persisted in JMS inside the Web Service client before they are
sent. It could also mean persisting the SOAP Messages
An excellent summary !!
Another BIG thing about the Web Service and JMS semantic mismatch is about
the way they look at TRANSACTION (although there is not a widely-accepted
one at this moment, so I'm talking about the model behind BTP and
WS-Transaction).
In JMS, it is NOT possible to send
I agree that SOAP over JMS over the intranet (to Dave's definition) is a
very practical approach today. although we still need to be aware of other
conflicting approaches as well
Without knowing the Sonic contribution, I', not sure if the message
correlation id is an explicit field
are you talking about here when you say SOAP over JMS ?
I can undertand the reverse JMS over SOAP where the wire level binding is
a SOAP message and travels over another protocol like HTTP (eg the Systinet
product).
/S
Original Message:
-
From: Ricky Ho [EMAIL PROTECTED]
Date: Mon
Your suggested approach is in fact very heavy-weight because of the life
cycle management of millions of service instances behind each URL. Passing
along the account id (or any business data for correlation) is a better way
to handle this.
I've observed a pure OO thought is in many times a
I guess what Tuan wants is NOT writing the dispatching code. The way you
suggest is the same as asking the client to pass the account as a parameter
to a generic service. It makes no difference whether you pass via the URL
or in the SOAP request.
Rgds, Ricky
At 08:12 AM 10/1/2002 -0400,
I think your SOAP service is depending on the cookie
mechanism as well as the HTTP transport. And you also restricting
the session variables to ONE client. But no doubt this approach is
the easiest.
I think a better approach is to have the message itself carry some data
that maps into an
How does the handler detect the incoming request belongs to some existing
sessions ?? (is it assessible via MessageContext ?) And then throw a SOAP
Fault if not.
Rgds, Ricky
At 10:29 AM 9/30/2002 +0200, Matthias Brunner wrote:
On Monday 30 September 2002 10:23, Jan-Olav Eide wrote:
When
SOAP is more an RPC mechanism than a remote Object mechanism. I doubt it
would be scalable. From the lesson we learnt in EJB, if we shouldn't
expose EntityBean, then expose a web service per object instance is even
much worse.
Rgds, Ricky
At 10:48 AM 10/1/2002 +0700, Tuan Le Viet wrote:
Use document/literal encoding
At 12:56 PM 9/17/2002 -0700, you wrote:
Hi,
I noticed that the SOAP generated by Axis clients is
different from what I expected. Whenever, the
request/reply messages contain a complexType as a
parameter then the generated SOAP seems to use
multiRef and the
41 matches
Mail list logo
