axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: [AXIS2] [Sandesha2] Saving the message context
Date Sat, 29 Jul 2006 15:53:56 GMT
Hi Bill,

comments inline.

Regards,

Rajith

On 7/29/06, Bill Nagy <nagy@watson.ibm.com> wrote:
>
> On Fri, 2006-07-28 at 23:46 -0400, Rajith Attapattu wrote:
> > Anne,
> >
> > Again I will advice again serializing the contexts using any form of
> > serialization. This will not scale at all in a production environment.
>
> Hi Rajith,
>
> Could you please explain this last comment?


[RA] Sorry I should have been more specific [appologies]. I was refering to
the option (A) in Ann's reply.
Ann mentioned "Do a customized serialization using java.io.Externalizable in
the complex objects and use the default serialization mechanism (
java.io.Serializable) in the simple objects." , so I assume that Ann is
planning to save the ctx hierarchy, with complex objects in a customized
form and use simple java serialization for the simple objects.

In a production environment with 1000s of Msg Ctxs, saving and re-creating
these complex object structures will be very expensive Vs saving only the
message essential in a bean and reprocessing it again.

Remember we always optimize the system to process the messages efficiently
and we scale better with large number of messages than the serializable
approach. So recreating the message and re-processing it is not expensive
compared to the more memory intensive serializing and deserializing complex
object hierarchies.

IMHO the serialization approach will not scale in a production environment.
YMMV

> Again this approach will be error prone and as chamikara mentioned
> > there will be too many information saved in the database.
>
> I don't understand why you and Chamikara keep saying that there will be
> too much information serialized.  You have the option of taking complete
> control of the serialization, thereby writing/reading only the
> information that you want and in the form that you want it to be in.


[RA] Bill as Ann has rightly pointed out " The AXIS2 message context is very
complex (it includes references to several complicated objects)" , it would
be pointless to save the message ctx in isolation. So invariably u would be
serializing a hierarchy of contexts.
Now I agree that with java.io.Externalizable you can control what can be
saved and in what form, but still u have to maintain the complex hierarchy
in what ever form u plan to serialize. So u can get away with not
serializing everything, but u will have to ensure the bare minimum to ensure
the hierarchy is maintained properly.
Now this could still mean more information than the external approach that
Chamikara use for sandesha.


>
> > I am looking at clustering certain information within the ctx heirachy
> > for high availability and I would only do with the bare minimum.
> >
> > In my opinion the performance overhead of serializing and
> > deserializing (and validations to avoid erros) is a lot more than
> > saving the required info in a bean like what chamikara does for
> > Sandesha and then reconstructing it.
> >
>
> Having the objects persist their own state is far less error prone than
> having a third-party piece of code do the persistence.


[RA] Yes, I totaly agree with you on this point. But again I should have
explained more clearly [appologies for not doing so].
I was refering to another problem.
As chamikara pointed out each MC deserialization could result it's own copy
of ctx hierarchy which may not map with the hierarchy of another MC.
So we might end up doing more validations to eradicate these error states.

 For one, anytime someone changes or adds a piece of information that needs
> to be saved in
> order to correctly restore the state, they have to remember to modify
> the external code.  It's generally hard enough to remember to modify
> code embedded in the class itself, much less having to remember to
> modify a completely separate piece of code.
>
> Secondly, you require the objects that need to be saved to expose
> methods, to return the portions that you want to have serialized, that
> you may not have to expose otherwise.
>
> In effect, the approach that you've chosen has abandoned encapsulation
> and created fragile dependencies -- this is bad design.
>
> -Bill


[RA] Bill I totaly agree here from a design POV. But as we all know, design
that looks perfect on paper sometimes fail w.r.t performance and
scalability.
I guess we need to maintain a delicate balance btw design elegance and
performance.
We should try to maintain encapsulation as much as possible, no question
about that.

Btw as Sanjiva mentioned all data that we are interested in the MC were
already exposed by the object by design. So atleast there we are not in
violation of encapsulation.

I value object oriented principles very much, but nothing is written in
stone and sometimes u need to bend the rules a bit to achive performance and
scalability.
How much we do so depends on the fragile balance btw accepted design
principles  vs performance.

IMHO, having the MC (and ctx objects) manage their sate is very nice design,
but the saving the message and then reprocessing is more scalable.
YMMV.

On a seperate note, saving the messages in the format described by Chamikara
has the added benifit of allowing querries on the message table in case of
failure or for other management reports. This is just an added frill that I
thought would be useful.

> Regards,
> >
> > Rajith
> >
> >
> > On 7/28/06, Chamikara Jayalath <chamikaramj@gmail.com> wrote:
> >         Hi Ann,
> >
> >         Yes. We had introduced Externalizable implementaitons for all
> >         of the Context hierarchy objects sometime back. But this
> >         approach seemed to be saving too much information on the
> >         database.
> >
> >         For example at some point there may be following context
> >         objects available in a running axis2 instance.
> >         1. configuration context object
> >         2. service group context objects
> >         3 service context objects
> >         4. Operation context objects
> >         5. A lot of message context objects
> >
> >         If we try serializing starting from a message context, since
> >         we have to serialize every incoming message context all these
> >         objects will be serialized every time (recall that the message
> >         context hs a link to the configuration context which has links
> >         to all other context objects). Think how deficult the
> >         reconstruction would be. Every deserialized message context
> >         will come up with its own hierarchy of context objects which
> >         may not map with the context objects reconstructed by
> >         deserializing others message contexts.
> >
> >         Thats why I went for this approach of saving only the relavent
> >         information. It seemed to be much cleaner and it was
> >         working :-)
> >
> >         You had mentioned about serializing the AxisOperaion object.
> >         All the 'Axis*'  objects in Axis2 (AxisConfiguration,
> >         AxisServiceGroupt etc.) contains deployment time information.
> >         So we can safely ignore them in the serializing process.
> >
> >
> >         Chamikara
> >
> >
> >
> >
> >         On 7/29/06, Ann Robinson <robinsona@us.ibm.com> wrote:
> >                 Hi Chamikara,
> >                 Thanks for the information.
> >
> >                 Did you consider using java.io.Externalizable for the
> >                 AXIS2 message context-related classes? (Having the
> >                 work done by the AXIS2 objects would have simplified
> >                 the actions that Sandesha needed to take in order to
> >                 save the message context, so I am curious about any
> >                 issues that were encountered.
> >
> >
> >                 In the MessageStoreBean, how much of the various
> >                 objects do you store as Strings? For example, the
> >                 AxisOperation object contains several lists and the
> >                 executionChain object contains a list of handlers and
> >                 phases.
> >
> >
> >
> >
> >                 Ann
> >
> >
> >                 WebSphere Development, Web Services Engine
> >
> >                 IBM
> >                 11501 Burnet Rd IZip 9035G021
> >                 Austin, TX 78758
> >                 (512)838-9438 TL 678-9438
> >
> >
> >
> >                 Inactive hide details for Chamikara"Chamikara
> >                 Jayalath" < chamikaramj@gmail.com>
> >
> >
> >
> >                                                 "Chamikara Jayalath" <
> chamikaramj@gmail.com>
> >                                                 07/28/2006 07:23 AM
> >                                                 Please respond to
> >                                                 axis-dev@ws.apache.org
> >
> >
> >
> >                            To
> >
> >                 Ann
> >                 Robinson/Austin/IBM@IBMUS
> >
> >                            cc
> >
> >                 axis-dev@ws.apache.org, sandesha-dev@ws.apache.org
> >
> >                       Subject
> >
> >                 Re: [AXIS2]
> >                 [Sandesha2]
> >                 Saving the
> >                 message
> >                 context
> >
> >
> >
> >                 Hi Ann,
> >
> >                 I did some work on serializing message contexts and
> >                 reconstructing them. This was done as a part of the
> >                 Sandesha2 Persistent Storage Manager implementation.
> >                 Unfortunately could not commit the code into Apache
> >                 due to a license issue (it was dependent on
> >                 Hibernate). But will try to host it somewhere else
> >                 soon.
> >
> >                 The approach i took was extracting the relevant
> >                 information from the message context, and saving them
> >                 in a java bean. Later this bean was used to recostruct
> >                 the message context. The format of this bean was as
> >                 follows.
> >
> >                 public class MessageStoreBean {
> >
> >                 private String SOAPEnvelopeString;
> >                 private String storedKey;
> >                 private int SOAPVersion = 0;
> >                 private String transportOut;
> >                 private String axisServiceGroup;
> >                 private String axisService;
> >                 private String axisOperation;
> >                 private String axisOperationMEP;
> >                 private String toURL;
> >                 private String transportTo;
> >                 private int flow;
> >                 private String executionChainString;
> >                 private String messageReceiverString;
> >                 private boolean serverSide;
> >                 private String inMessageStoreKey;
> >                 private String messageID;
> >                 private String persistentPropertyString;
> >                 private String callbackClassName;
> >                 private String action;
> >
> >                 }
> >
> >                 As you can see the aim was to avoid Java
> >                 serialization. One defect here is SOAP envelope being
> >                 saved as a string, which may not be possible in the RM
> >                 +MTOM scenario. I guess we can support that when a
> >                 better serialization mechanism gets available for SOAP
> >                 envelopes.
> >
> >                 Chamikara
> >
> >
> >
> >                 On 7/27/06, Ann Robinson <robinsona@us.ibm.com>
> >                 wrote:
> >                         Hi all,
> >
> >                         I have posted this note to both the AXIS2 and
> >                         SANDESHA developer discussion lists, so I
> >                         apologize in advance to those folks who get
> >                         multiple copies of this note.
> >
> >                         I am investigating how to save and restore the
> >                         message context in AXIS2. This is
> >                         functionality that would be used by other
> >                         quality-of-service layers, for example, by a
> >                         WS-ReliableMessaging implementation -
> >                         particularly one that is composed with
> >                         WS-Security, to save the message in persistent
> >                         storage and later resume the message
> >                         processing.
> >
> >                         The AXIS2 message context is very complex (it
> >                         includes references to several complicated
> >                         objects) and does not lend itself to the
> >                         default java serialization mechanism
> >                         (java.io.Serializable). In order to save the
> >                         message context, the possible solutions
> >                         include the following:
> >
> >                         (A) Internal Message Context option
> >
> >                         Do a customized serialization using
> >                         java.io.Externalizable in the complex objects
> >                         and use the default serialization mechanism
> >                         (java.io.Serializable) in the simple objects.
> >                         - - This keeps the knowledge of the object's
> >                         internals in the object and keeps the
> >                         responsibility in the object for persisting
> >                         and resurrecting its own state.
> >                         - - This lets an object have a plugpoint where
> >                         needed to manage "user" data. This would apply
> >                         to the situation where an object maintains a
> >                         set of properties or attributes that are
> >                         supplied by users of the object. The plugpoint
> >                         would define an interface so that the users of
> >                         the object could save their
> >                         properties/attributes appropriately.
> >
> >                         (B) External Layer option
> >
> >                         Put in get/set methods in all of the objects
> >                         related to the message context in order to
> >                         allow another layer or quality of service
> >                         (QoS) to extract sufficient information from
> >                         the message context in order to save and
> >                         resurrect the information.
> >                         - - The simplest form of this technique is
> >                         saving just the message (and the message
> >                         attachments). However, this means that any
> >                         processing on the message has to be re-done
> >                         from the beginning.
> >                         - - If there is a requirement to maintain the
> >                         security context with the message, then the
> >                         security layer would need to provide
> >                         additional interfaces to allow that message's
> >                         security context to be acquired by that other
> >                         layer.
> >
> >                         (C) Core Plugpoint option
> >
> >                         Have a plugpoint in the AXIS2 core that would
> >                         provide an interface to capture essential
> >                         message context data for saving and restoring
> >                         it.
> >                         - - This solution would be a compromise
> >                         between (A) and (B)
> >                         - - This requires knowledge of message context
> >                         object-related internals inside of the
> >                         plugpoint implementation, which is not good
> >                         object oriented design
> >
> >
> >                         Any other suggestions or comments?
> >
> >                         I understand that there has been a previous
> >                         attempt to do this in AXIS2 based on Sandesha
> >                         requirements and that this attempt did not
> >                         work. I was wondering if anyone remembers what
> >                         problems were encountered and what issues
> >                         ultimately blocked that solution?
> >
> >
> >                         Thanks,
> >                         Ann
> >
> >
> >                         WebSphere Development, Web Services Engine
> >
> >                         IBM
> >                         11501 Burnet Rd IZip 9035G021
> >                         Austin, TX 78758
> >                         (512)838-9438 TL 678-9438
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>

Mime
View raw message