axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <mgai...@hotmail.com>
Subject RE: retrieving message_id
Date Sat, 03 Aug 2013 23:45:16 GMT
Interesting dichotomy as there *seems to be* 2 working solutions for the same problem

solution1)implement reliable-messaging and block consequent processing until ALL transmitted
messages are acknowledged
PROS: No additional Hardware or servers required ..development effort will block processing
until ALL sent messages are respectfully ack'ed
CONS: what happens is there is a problem with receiving service which may not be able to process
message...is there protential for unintended race condition?

solution2)implement redundancy thru fault-tolerant nodes participating on cluster
PROS: this is the most reliable ..if the originating request cannot be processed within specified
time..cluster-manager sends to service2 to process the SOAP request
CONS: Purchase of fault-tolerant Hardware (participating in a cluster?) would be necessary

implementations can depend on 
1)strength of operations role to the company vs development role
2)resources to refactor code using development-centric methodologies should be compared with
resources required for client implementation (Hardware purchase)
 
example

BancoSantander: solution2 would win..the almost negligible cost of hardware expended by the
operations team which implemented clustered fault-tolerant node solutions is what the banks
 operations unit did best..they had a world-wide network of servers ..retasking some of those
servers to shoulder the load for cluster-failover is something the ops team implemented frequently
and with remarkable efficiency

deNovisMedical: solution1 (implement reliable-messaging in code) would win..requesting our
client (Tufts) to purchase additional hardware was never an option
for our HIPAA EDI ..DeNovis 835 and 837 Transactions implemented reliable-messaging (as specified
by the original architecture document)

I would interested to hear what solution would others implement and why?

Martin 
______________________________________________ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten
wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist
unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet
keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
wir keine Haftung fuer den Inhalt uebernehmen.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire
prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe
quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information
seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les
email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune
responsabilité pour le contenu fourni.

 
Date: Sat, 3 Aug 2013 23:07:59 +0200
Subject: Re: retrieving message_id
From: w_benkhelouf@esi.dz
To: java-dev@axis.apache.org

As i see ws-addressing is very helpful ,but you know my work (final year engineering project)is
an approach based redundancy to achieve fault tolerance, so processing like that is the only
way authorized.thank you very much Brian for your helpful advises ,I hope that I've not  bothered
you too much with my beginners questions.
Please accept my best regards ;-)

2013/8/3 Brian Reinhold <brianreinhold@lampreynetworks.com>

Walid,
 It is my understanding that the ws-reliable transfer does that; if a server goes down while
a request is in progress the request remains on the client side. The reliable messaging transfer
sets up a “shell” around the transfer of interest and the shell does not terminate until
the message of interest has completed. The protocol is to be sure that a message gets through
(for example medical data). It also has different QoS settings (once and only once, at least
once). However, clearly it has the disadvantage over duplicate implementations that it requires
the endpoint to come back on line before the shell can acknowledge the completion of the transaction.
 But if you have already looked at this and decided that redundancy is the way to go, well
then that is the way to go.  (It’s certainly faster!)
 Brian.
 From: Walid Benkhelouf [mailto:w_benkhelouf@esi.dz] 

Sent: Saturday, August 03, 2013 3:52 PM
To: java-dev@axis.apache.org
Subject: Re: retrieving message_id

 Yes Brian ,but my first problem is to address problems when a web server goes down ,and figure
a way to not loose requests which are in process,so the clients can have a response even if
it is from another endpoint.
when a web server goes down ,another hosted in another machine,will takes his place(designed
as the primary)it will :1-Update the endpoint reference in the repository(uddi,membrane,..etc)
so he will be requested by the future clients.
2-Continue processing the requests not accomplished by the server who was down.  
  2013/8/3 Brian Reinhold <brianreinhold@lampreynetworks.com>
Walid, 
Sounds involved. Could the same be accomplished using the WS reliable messaging protocol (Sandesha
project in the Axis2/Apache hierarchy)? Would be almost no work; just add the module in your
Axis2 xml. The main difference (I think) from your proposal is that this protocol is still
point to point. Should an endpoint go down during a transaction it could not be completed
until the endpoint came back up. But at least there wouldn’t be all this duplication of
resources and multiple databases. But I suppose you have probably looked at this.
 Brian
 From: Walid Benkhelouf [mailto:w_benkhelouf@esi.dz] 

Sent: Saturday, August 03, 2013 3:09 PM
To: java-dev@axis.apache.org
Subject: Re: retrieving message_id
 hi brian, 
My goal is to achieve fault tolerance using replication in web services,
 -->I have a set of web services containers interconnected via a private p2p network ,which
are communicating with a specific protocol(the main problematic of the project).
 -->When a problem occur(one server goes offline or restart),this problem is detected by
one of his neighbors  which contains identical copies of it's web services ,it will retrieve
the uncomplicated tasks  and return them to the clients.
 -->To achieve this goal,every node of the network (so the server) is notifying his incoming
request to his neighbors ,so when the request is delivered he(the server) notify it again
and the requests will be dropped from the databases.
 -->This database is located in every node of the network ,it contains information about
the current tasks in the neighborhood ,stored in one table: [msg_ID,Client add,Request].the
message_id is the auto-incremented key retrieved from the database(when a message is inserted).
 -->So the purpose for which i want to use messageID is exclusively for the server side
,tracing in/out message is only used for storing requests properly ,what do you think about
the approach Brian?
 Walid 
2013/8/3 Brian Reinhold <brianreinhold@lampreynetworks.com>
This one is a little tougher because it is not based upon protocol. You want to maintain some
kind of internal tracker. Clearly Axis2 does this since it is able to generate a response
to an incoming message. Thus it must have something that tracks it (which may be based upon
protocol). However, setting the message Id is probably not a reliable way. The messageID is
part of the ws-addressing protocol. The message context object is used by both clients and
servers so the ‘set’ method is probably meant for the client; setting it on the server
side is likely ignored as Axis2 constructs the ws-addressing response based upon protocol
and who knows where it stores its internal information (it may make a copy and pass that up
to the user; that way Axis2 is sure to respond to the protocol correctly which it can’t
do if the user corrupts the incoming message context).
 Without protocol, how are you intending to identify the incoming message as one that you
want to filter? As I understand your goal, you want to block the response to certain incoming
messages.
 Brian
 From: Walid Benkhelouf [mailto:w_benkhelouf@esi.dz] 

Sent: Friday, August 02, 2013 9:00 PM
To: java-dev@axis.apache.org

Subject: Re: retrieving message_id Hi Brian,sorry for my misunderstanding :-)
The solution that i'm developing (for academic purpose)is located in the handlers levels,so
i'm trying to be the most transparent as possible to the client and the service writer ,so
for this I've written two handlers one for incoming and one for outgoing putted in an AXIS2
module.
For now i was able to address the problem by activating "ws-addressing"in the client side(and
let the message_id blank), so when the message is intercepted by the "incoming_handler",it
will set the message_id "manually" msgctx.setMessageID (a random key).
The outgoing handler can access to this value by "msgctx.getRelatesTo()).it's addressing my
problem when "ws_addressing"is activated in the client side.
But i was looking for a "more general"solution that can address the problem where the client
don't have the ws_addressing activated in the request.
Best Regards! 
2013/8/3 Brian Reinhold <brianreinhold@lampreynetworks.com>
Walid, 
I think you misunderstood my American slang comment and took it the wrong way (it’s kind
of an expression); I am not saying that YOUR question was stupid. If you look below you will
see I am asking the ‘stupid’ question which was “did you check to see if the client
sent you a message id?”. If it hadn’t, you looking for something that didn’t exist and
there was never anything wrong with your logic or code!
 Now if I understand you correctly, the client did NOT have a message ID and you were able
to add one. So now you are getting the message id at least on the incoming. But NOT on the
outgoing.  Is that correct?
 If so, the outgoing maybe a lot more difficult. I have had some issues with the ws addressing
headers on the response. I do not know if it affecting your results.
 Can you show the sent/incoming SOAP message? That would help answer some of the other questions
I asked.
 Brian
  
From: Walid Benkhelouf [mailto:w_benkhelouf@esi.dz] 

Sent: Friday, August 02, 2013 3:17 PM
To: java-dev@axis.apache.org

Subject: Re: retrieving message_id Sorry for my stupid question ,the thing is that i'm not
an expert in axis or java programming ,i was using SOAPUI to simulate the client, i can see
now that i can add messageID from SOAPUI ,it's addressing my problem for the incoming,but
i just wanna ask one more stupid question :)  :
-->is there any property in common between the incoming and outgoing message ,that i can
use as primary key in my database that is used to store incoming messages.(and when a response
occur without a problem ,this message will be drooped) . 
 2013/8/2 Brian Reinhold <brianreinhold@lampreynetworks.com>
A stupid question: you are sure that the message id field is sent by the client …
Is this null response only on the incoming message?And what version?
Sending secure or unsecure?Is ‘must understand’ set by the client?
I know I had to do some messing around with the addressing modules to get the ws addressing
headers to appear in the response. But it’s been a long time so I don’t recall the details.
 Brian
 
From: Walid Benkhelouf [mailto:w_benkhelouf@esi.dz] 

Sent: Friday, August 02, 2013 2:33 PM
To: java-dev@axis.apache.org
Subject: Re: retrieving message_id
 hi Martin,yes i did this and i'm getting a null value in both incoming and outgoing, even
if "ws-addressing" is engaged.
 2013/8/2 Martin Gainty <mgainty@hotmail.com>
try
 
mc.getMessageID()

(case matters)
 
does this help?
Martin 
______________________________________________ 
Verzicht und Vertraulichkeitanmerkung


Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten
wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist
unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet
keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
wir keine Haftung fuer den Inhalt uebernehmen.


 Date: Fri, 2 Aug 2013 18:55:18 +0200

Subject: Re: retrieving message_id
From: w_benkhelouf@esi.dz
To: java-dev@axis.apache.org
 I need to know if there is a property shared between the two messages(IN/OUT) ,
I was thinking that this property is the message_id contained in "messageContext.getmessageID()"
,but i'm getting a null value when trying to retrieve it (ws-addressing module is engaged)
  
2013/8/2 Brian Reinhold <brianreinhold@lampreynetworks.com>Not sure I understand the
problem ... is what you are trying to do is

retrieve the ws:addressing message id?

Brian
-----Original Message-----
From: Walid Benkhelouf [mailto:w_benkhelouf@esi.dz]

Sent: Thursday, August 01, 2013 7:09 PM
To: java-dev@axis.apache.org
Subject: retrieving message_id

Hello,

I'm developping a module that handler in/out message from axis2 engine and

store them in a database.
I have two handlers :one for the incoming and one for the outgoing.
I need to store the incoming ,and drop the outgoing messages.
The problem is that i need to have the same message_id so i can access to

the database in the second time(the two messages needs to have the same
key).
Thanks;---------------------------------------------------------------------

To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org



-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3209/6543 - Release Date: 08/01/13


---------------------------------------------------------------------

To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
  
 No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3209/6545 - Release Date: 08/02/13
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3209/6545 - Release Date: 08/02/13 
No virus found in this message.

Checked by AVG - www.avg.comVersion: 2013.0.3392 / Virus Database: 3209/6547 - Release Date:
08/02/13
 No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3209/6548 - Release Date: 08/03/13
No virus found in this message.
Checked by AVG - www.avg.comVersion: 2013.0.3392 / Virus Database: 3209/6548 - Release Date:
08/03/13
 No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3209/6548 - Release Date: 08/03/13
No virus found in this message.
Checked by AVG - www.avg.com

Version: 2013.0.3392 / Virus Database: 3209/6548 - Release Date: 08/03/13
 		 	   		  
Mime
View raw message