axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Walid Benkhelouf <w_benkhel...@esi.dz>
Subject Re: retrieving message_id
Date Sun, 04 Aug 2013 04:36:24 GMT
Thank you all!


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

> Martin,****
>
> ** **
>
> This is a university project and the project is determined. So it’s a
> raid-type approach; backup servers!****
>
> ** **
>
> Brian****
>
> ** **
>
> *From:* Martin Gainty [mailto:mgainty@hotmail.com]
> *Sent:* Saturday, August 03, 2013 7:45 PM
> *To:* java-dev@axis.apache.org
> *Subject:* RE: retrieving message_id****
>
> ** **
>
> 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.com****
>
> Version: 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.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*
> ***
> ------------------------------
>
> 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*
> ***
>
> 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