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: [email protected] To: [email protected] 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 <[email protected]> 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:[email protected]] Sent: Saturday, August 03, 2013 3:52 PM To: [email protected] 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 <[email protected]> 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:[email protected]] Sent: Saturday, August 03, 2013 3:09 PM To: [email protected] 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 <[email protected]> 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:[email protected]] Sent: Friday, August 02, 2013 9:00 PM To: [email protected] 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 <[email protected]> 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:[email protected]] Sent: Friday, August 02, 2013 3:17 PM To: [email protected] 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 <[email protected]> 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:[email protected]] Sent: Friday, August 02, 2013 2:33 PM To: [email protected] 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 <[email protected]> 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: [email protected] To: [email protected] 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 <[email protected]>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:[email protected]] Sent: Thursday, August 01, 2013 7:09 PM To: [email protected] 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: [email protected] For additional commands, e-mail: [email protected] ----- 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: [email protected] For additional commands, e-mail: [email protected] 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
