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] Summery of todays Hackathon
Date Wed, 11 Oct 2006 02:42:51 GMT
Sanjiva

I also agree on your comments regarding the operation client.

Now about the whole session/clustering thing.
You mention that outside of Axis2 the concept of Service Group does not
exist !!!
So a client would expect to interact with Services from two Service Groups
in a single session.

Thats the reason why I proposed a WS-Addressing or WS-Context based approach
which has a notion of session outside the context heirachy and spans
ServiceGroups. It's a lot more simple than
ServiceGroupContext.getEPRForService ("serviceName") to propogate
information.

Why can't we have a single lightweight mechanism to share "application data"
among services without all the hassel of being tied down to the context
heirachy.
However we still need to replicate Service Context and ServiceGroupContext
as there maybe axis2 specific operational data that needs to available to
service the client properly.

I hear your argument about isolation at Service and Service Group level. But
I think it should be limited to operational data.
For business data we should be able to share across Services that spans
serveral Service Groups if the user chooses to do so.

Comments are welcomed !!

Regards,

Rajith


On 10/10/06, Sanjiva Weerawarana <sanjiva@opensource.lk> wrote:
>
> On Tue, 2006-10-10 at 17:54 -0500, Deepal Jayasinghe wrote:
> > Why do we need operation client ?........
>
> ??? You gotta be kidding.
>
> We have it because that's the client API for a generic MEP.
>
> > As Dennis suggested , having annon name as public static seems not that
> > good , so we need to remove them I mean we need to make the private.
>
> Sorry I don't understand what you're referring to. If its the constants
> we used to make the simple API work then I don't agree there's any
> problem.
>
> > Rather than giving two client API to client cant we have one API , we
> > can have all the methods in serviceClient then no one need to know about
> > the operationClient (service client will use that internally ). So our
> > proposal is to add few more methods into ServiceCleint;
> >
> > public MessageContext sendReceive(MessageContext req){}
> > public void sendReceiveNonBlocking(MessageContext req){}
> > public fireAndForget(MessageContext req){}
> > public sendRobust(MessageContext req){}
>
> This only works for the 4 built-in MEPs. Have we decided to narrow Axis2
> down to the built in MEPs? If so half of the machinery in Axis2 can be
> removed.
>
> > if we introduce these methods into ServiceClient then we do not too much
> > worry about how to create operationClient etc...
> >
> > I am +1 on adding these four methods in to serviceClient.
>
> Sorry, I'm -1 to this change. No way. It fundamentally breaks the client
> API!!!!
>
> If you want to do this then in the minimum it has to be after 1.1. No
> way we're going to change the client API after RC1 has been cut!
>
> > =======
> > How do we reflect service group concept in to client , and manage
> > session using that. Well I do understand if we use Axis2 client <->
> > Axis2 service this will work , but what if we use .Net client <-> Axis2
> > Service. Is there any kind of specification sending session related data
> > in SOAP message ? , if there is such a thing then we need to use them.
>
> You're forgetting a design decision we made a while ago: to make the
> service group concept not visible to the outside. That's why we said
> services withing group become top level services. I was against it but
> that's what we decided. As such there's no need to expose it to the
> client.
>
> What will be useful is for one service in a group to be able to get the
> EPR of another service in a group. Something like
> ServiceGroupContext.getEPRForService ("serviceName"). That can propagate
> the contextID etc. so that they share the same interaction session.
>
> Sanjiva.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>

Mime
View raw message