[Apache Web Services Wiki] New: ChatAgenda/20050316/ChatLog

[ge...@ws.apache.org]

   Date: 2005-03-16T06:22:46
   Editor: AjithRanabahu
   Wiki: Apache Web Services Wiki
   Page: ChatAgenda/20050316/ChatLog
   URL: http://wiki.apache.org/ws/ChatAgenda/20050316/ChatLog

   no comment

New Page:

Glen is back in chat after a long time and the talk was on transport.
There were some conversation about MTOM also.
{{{[18:57]  ***  Apache Axis -- WSDL SOAP XML-RPC
[18:57]  *** [freenode-info] please register your nickname...don't
forget to auto-identify! http://freenode.net/faq.shtml#nicksetup :
#apache-axis
[18:57]  *** srinath_perera is now known as Srinath
[18:57]  *** Chamil joined #apache-axis
[18:57]  *** Deepal joined #apache-axis
[19:00]<Deepal> Hi all
[19:01]  *** glen-brb is now known as gdaniels
[19:01]<gdaniels> Hi Deepal, all!
[19:01]<Srinath> hi glen all
[19:01]<Deepal> BTW wt are we going to talk today
[19:01]<Srinath> after some time :)
[19:01]<Chamil> hi all
[19:01]<gdaniels> Deepal: politics! :)
[19:01]<Deepal> I didnt see any thing in the agenda
[19:01]<Deepal> :)
[19:02]<Srinath> oops glen.. what ppolitics
[19:02]<gdaniels> Srinath: Yes, I've been travelling a lot... :(
[19:02]<Deepal> oh : seems you are busy
[19:02]<Ajith> anyway its nice to have you here
[19:02]<gdaniels> Yes, but I'm going to try really hard to focus on
Axis2 for a while.
[19:03]<gdaniels> Thx Ajith :) :)
[19:03]<Deepal> thats great
[19:03]<gdaniels> You guys have been doing great stuff!
[19:03]<Srinath> glen we are going see u SL ?
[19:03]<Deepal> thanks
[19:03]<Srinath> at F2F :
[19:04]<gdaniels> I'm mostly here today to hang out - I haven't yet
fully grokked the current state of the world, so that's my immediate
goal.  Then I'm sure I'll have commentary. :)
[19:04]<gdaniels> I'll be in SL yes
[19:04]<Srinath> :)
[19:04]<gdaniels> Last time was way too much fun to even consider
missing the next one
[19:04]<Srinath> :):)
[19:04]<Srinath> :)
[19:05]<gdaniels> So "maven idea" doesn't seem to work for me :(
[19:05]<Srinath> I got one quick Q, how should we specify the
transport senders, reciver in the DD?
[19:05]<Deepal> I think its working
[19:05]<Deepal> i mean mavne idea
[19:05]<Srinath> ajith ayya u use maven idea plugien?
[19:06]<gdaniels> It generates a project file, but doesn't actually
set up the classpaths or mark the source directories as source
roots....
[19:06]<Deepal> but the problem is it dose not creat a multi module project
[19:06]<gdaniels> I might be using too old a version of IDEA
[19:07]<Deepal> nope glen :
[19:07]  *** Thilina joined #apache-axis
[19:07]<Srinath> new IDEA thing has modules yes
[19:07]<Thilina> hi
[19:07]<Deepal> it is not a prob. with IDEA
[19:07]<Srinath> is it prob with maven plugien
[19:07]<Deepal> I think maven idea    cant creat a multi module project
[19:08]<Deepal> we will take a look at that
[19:08]<Deepal> glen did u go throgh the f2f ageneda
[19:08]<gdaniels> Cool, but if it's a prob with the plugin we'll need
to coordinate with the author
[19:08]<Srinath> but Geronimo ppl should know the answer ... it has
too many jars even  to consider create a project manually
[19:08]<gdaniels> Deepal: I haven't looked at it yet, unfortunately :(
[19:09]  *** Gayan joined #apache-axis
[19:09]<Srinath> I got one quick Q, how should we specify the
transport senders, reciver in the DD?
[19:09]<Deepal> http://wiki.apache.org/ws/FrontPage/Axis2/f2f_2d2
[19:09]<Srinath> server.xml
[19:10]<Srinath> as attributes of transports? or elements
[19:10]<Ajith> sorry Srinath : No I am not using maven to generate the
idea project
[19:10]<Ajith> I actually created the project by hand
[19:10]<Deepal> lets use elemnt as we have used in service.xml
[19:10]<gdaniels> transports should be their own thing, I think, and
senders and receivers are separate
[19:11]<Gayan> testin
[19:11]<Srinath> glen: I mean TransportSenders, TransportRecivers
[19:11]<Deepal> Srinath u are talking abot diffrent tarnsport
[19:12]<Deepal> wt would be the sender , recieber for HTTP , SMTP etc.
[19:12]<gdaniels> So a transport receiver needs to know a) a name, and
b) configuration data (chains, properties)
[19:12]<gdaniels> A transport sender needs to know a) a name, b) a
classname, and c) configuration data (chains, properties)
[19:13]<gdaniels> sound right?
[19:13]<Srinath> yes teanport has parameters inside them
[19:13]<Srinath> should we make the transportsender parameter special
[19:13]  *** sanjiva quit FreeNode : Read error: 60 (Operation timed out)
[19:13]<Srinath> or use it as usual attribute
[19:14]<gdaniels> <transportSender name="http"
class="org.apache.axis.transports.http.Sender"><parameter name="foo"
value="bar"/><requestFlow>...</requestFlow></transportSender>
[19:14]<Ajith> hmmm
[19:15]<Deepal> hmm
[19:15]<Ajith> this goes inside the service.xml ?
[19:15]<Deepal> sound good
[19:15]<Deepal> nope ajith
[19:15]  *** Jaliya joined #apache-axis
[19:15]<Deepal> it shoud be inside server.xml
[19:15]<Deepal> i guess
[19:15]<gdaniels> server.xml
[19:15]<Ajith> well here is my problem
[19:15]<Srinath> it is in server.xml
[19:16]<gdaniels> and client.xml :)
[19:16]<Srinath> yap
[19:16]<Ajith> wouldn't you need to specify the sender in terms of the service ?
[19:16]<Deepal> glen : we dont have that yet :(
[19:16]<gdaniels> Ajith: why?
[19:17]<Deepal> Ajith : you are talking about aynchrouns behaviour
[19:17]<Ajith> cant you have two services that use different
transports in a single server
[19:17]<Ajith> I mean cant you have a service that takes in an HTTP
request and send out an email ?
[19:17]<gdaniels> Ajith: Yes, sure!
[19:17]<Srinath> glen does the for transport is it not <tansport
name="http"> <sender class=""/> ....</transport>?
[19:18]<gdaniels> Srinath: I'm not sure - I think it might be good to
split the senders and receivers entirely, since they're so different
[19:18]<Deepal> got it
[19:18]<Srinath> glen u got a point
[19:18]<Jaliya> At the moment also we have them separate, but still
the receiver is the one who select the sender
[19:18]<Srinath> and ajith is getting to it very sso
[19:18]<Srinath> soon
[19:19]<gdaniels> Jaliya: the receiver can select the default sender,
but it might change based on addressing stuff
[19:19]<Jaliya> So IMHO is we need them to separate so that somebody
else will decide the exact sending path
[19:19]<Jaliya> Glen : Yes true
[19:19]<Ajith> yes I also see the importance of that
[19:19]<Srinath> jaliya:bit careful sender!= TransportSender
[19:20]<Jaliya> I would like to propose engine to handle that
[19:20]<gdaniels> Srinath: Yup
[19:20]<Ajith> But my guess is we should have *some* mechanism to
specify senders/recievers per service
[19:20]<Deepal> engine or a handler , am i correct ?
[19:20]<Srinath> I belive we should change engine registry too..
replace tranports with transport sender
[19:20]<gdaniels> We also need to make sure that things like "200 OK"
and other kinds of acks are handled correctly in all cases (even when
the transport changes due to addressing headers, for instance)
[19:21]<Deepal> ajith : is it service based or operation based ?
[19:21]<gdaniels> Ajith: We could spec per-service senders, but I'd
rather not for v1
[19:21]<gdaniels> Service-specific receivers don't really make any
sense (since transports happen before dispatch)
[19:21]<Srinath> yes logic should be .. if (reponse not written) write 200 ok
[19:22]<Srinath> glen:should we have transportReciver in the DD...I
feel we need not
[19:22]<gdaniels> Srinath: Yes, but we also need to make sure that
kind of thing works for email transports, etc
[19:22]<gdaniels> Srinath: Yes
[19:22]<Jaliya> Yes, if we can have some component who is dealing with
the transports yet understand addressing in the receiving path, then
it will handle the 202 , acks etc
[19:22]<gdaniels> You have to specify the transport-specific handlers,
parameters, etc....
[19:23]<gdaniels> <transportReceiver name="http"><requestFlow><handler
name="URLDispatcher"/>... etc
[19:24]<Deepal> glen : <requestFlow> == inFlow (outFlow)
[19:24]<gdaniels> right :)
[19:24]<Srinath> mmm .. may be tranportReciver are used int hthe cleint? yap
[19:25]<Srinath> is that the reason to have them
[19:25]<Srinath> ?
[19:26]<gdaniels> The reason to have them is that there are
receiver-specific handlers and configuration, even on the server.
[19:26]<gdaniels> If the client is using receivers, then it's really
also a server.
[19:26]<Srinath> u mean to put handlers inside :) yap
[19:27]<Jaliya> So if the receiver is http then our transport receiver
component will deal with the message path from that point, I mean take
necessary actions ?
[19:27]<Jaliya> specific to http
[19:27]<Ajith> hold on a sec
[19:27]<Ajith> may be i dont understnad well
[19:27]<gdaniels> Jaliya: The receiver will do the minimum amount
necessary to package the incoming message as a MessageContext, label
it with it's transport name ("http"), and pass it to the engine.  The
engine does all the rest.
[19:28]<Ajith> but what are these handlers inside the transport ?
[19:28]<gdaniels> All the other HTTP-specific stuff happens in
HTTP-specific handlers
[19:28]<Ajith> are they like the global handlers
[19:28]<Deepal> before the global
[19:28]<Ajith> Glen : aah I got it
[19:28]<gdaniels> They run before the global handlers
[19:28]<Srinath> e.g. simple http autentication
[19:28]<Jaliya> ok that is ok
[19:28]<Deepal> we have that now
[19:29]<Jaliya> one more clarification; can we get to know the
addressing stuff from those handles?
[19:29]<gdaniels> The engine's first job in life is to say "hey, this
message I just got says 'http' on it - let me look that up... oh, here
it is!  I'll just call those handlers first..."
[19:29]<gdaniels> Jaliya: Probably not, since the addressing stuff is
usually inside the SOAP envelope
[19:29]<Deepal> so when Tomcat handlers over the message to axis
engine , first it go through transport handlers  ?
[19:30]<gdaniels> right
[19:30]<Srinath> yes
[19:31]<gdaniels> brb
[19:31]  *** gdaniels is now known as glen-brb
[19:31]<Deepal> so in that case who is going to be decide which
tarnsport the message come form
[19:32]  *** glen-brb is now known as gdaniels
[19:33]<gdaniels> The guy who brings it into the Axis world in the first place
[19:33]<Jaliya> ok, then if the addressing handlers are at least in
global level, now we got a message and when it passes the addressing
handler, it will set all the properties to the message ctx, and now,
who is going to decide how to proceed, i mean where to send a response
(if any) or whether to send http 202 (in http case)? is it engine
[19:33]<gdaniels> i.e. the servlet / POP-reader / socket acceptor
[19:33]<Deepal> glen  :  did not get u
[19:33]<Deepal> jaliya : difficult to read such a long para :(
[19:34]<gdaniels> Jaliya: Yes, mostly it's the engine.  But there are
some more complex patterns we might want to support where the service
gets involved explicitly as well.
[19:34]<gdaniels> Deepal: The servlet is configured with it's
"transport name", which it plunks into the MessageContext for every
message it receives.
[19:35]<gdaniels> Just like Axis 1.X
[19:35]<Deepal> glen : tahnks
[19:36]<gdaniels> So you can have three copies of the servlet, each
configured with a different transport name.  They would each receive
messages with the same code, but the engine would run different sets
of handlers for them depending on the configuration.
[19:36]<Jaliya> Glen :Yes,we need to support  (I am wondering how to
implement the functional extensions like, RM and Secure Convercation
etc..)
[19:37]<Srinath> glen: do not get u?
[19:37]<gdaniels> Jaliya: We need to run the use cases for sure, but I
think we satisfied ourselves that it can work back in September in
Colombo.
[19:37]<Deepal> jaliya  : ist come after gloab handlers  ?
[19:38]<Ajith> hmmm
[19:38]<Ajith> Transport name for a servlet is its mapping name ?
[19:38]<Srinath> got what u mean glen (Q before)
[19:39]<gdaniels> Srinath: servlet 1 is configured with transport name
"http1", servlet 2 is configured with transport name "http2".  The
engine is configured with transport "http1" having handlers a,b,c -
transport "http2" has handlers d,e,f.  Depending on which servlet gets
the message, it's a different "transport" to Axis and therefore
different handlers run.
[19:39]<gdaniels> Srinath: but I'd already typed all that. :)
[19:39]<gdaniels> Ajith: Transport name for a servlet is probably a
separate piece of configuration (servlet param)
[19:39]<Srinath> :) thanks .. it suddenly occured to me after bit of time
[19:40]<Ajith> hmmm
[19:40]<Ajith> I had the concept that we have a single servlet as the reciever
[19:40]<gdaniels> Ajith: open your mind to larger possibilities. :)
[19:40]<Ajith> and the services are picked from that
[19:41]<Ajith> :D
[19:41]<gdaniels> I think Axis 1.X does this part exactly right
[19:41]<Srinath> should we have a place holder for transport sender
and seciver in the message context?
[19:41]<Ajith> well cant we have something like the struts thingy
[19:42]<Ajith> where all requests are directed to one servlet
[19:42]<Deepal> ?
[19:42]<Srinath> ajith: it is getting dangerous:D
[19:42]<Deepal> :D
[19:42]<Ajith> and the rest done through the url ?
[19:42]<Ajith> hey Just concepts
[19:43]<gdaniels> Srinath: yes (MC place holder), but I think mostly
for receiving transport name.  Sender is determined by our Sender
class.
[19:43]<Srinath> yes .. but it is used at the end .. we might need placeholders
[19:45]<gdaniels> maybe...
[19:45]<gdaniels> So hey can we talk MTOM for a minute?
[19:45]<Ajith> you mean sender is put in the MC ?
[19:46]<gdaniels> Ajith: it's in the MC now, right?
[19:46]<Deepal> Srinath : when a message get who is going t o creat the MC
[19:46]<Ajith> ?
[19:46]<Thilina> yeah
[19:46]<Ajith> No I dont think so
[19:46]<Srinath> now it put the transport type as a parameter in the
message context
[19:47]<Ajith> BTW if you do , you are getting onestep closer to my
suggestion of per service senders :)
[19:47]<Deepal> Srinath : by whome
[19:47]<gdaniels> What about the Sender object?  Or is that the
"Responder" that I'm thinking of?
[19:47]<Srinath> it is Sender
[19:48]<gdaniels> ok so it's in there already?
[19:48]<Srinath> Sender is there .. I think what it does can be imporved
[19:48]<Srinath> as it does not decide beased on addressing
[19:49]<gdaniels> well the decision making part is separate from the
actual Sender mechanism
[19:49]<Deepal> Srianth : if addresing handler need cant they change the sender
[19:49]<gdaniels> +1 Deepal
[19:50]<Ajith> Yeah I guess they can
[19:50]<Srinath> BTW I update
http://wiki.apache.org/ws/FrontPage_2fArchitecture_2fDeployment for
new transport info in DD
[19:50]<gdaniels> cool, thanks Srinath
[19:50]<Srinath> see Transport in the server.xml/cleint.xml and verify
[19:50]<Srinath> :)
[19:50]<Ajith> so if the addressing says its  mail to respond the
addressing handler puts the mail sender ?
[19:51]<gdaniels> Ajith: Exactly
[19:51]<Thilina> i have a question to be clarified
[19:51]<Srinath> mail sender == MailTransportSender right?
[19:51]<Ajith> oh the MTOM man is here
[19:51]<Ajith> :)
[19:51]<Thilina> can we identify a MTOM message in the transport laval
[19:52]<Thilina> :D
[19:52]<Ajith> So lets have a look of what he has to say
[19:52]<Thilina> nope
[19:52]<Thilina> since the discussion is on transport i raised the question
[19:52]<gdaniels> Thilina: We can identify it as soon as we know the
MIME type, so in many cases the answer is "yes".
[19:52]<Deepal> from HTTP header cant we decide ?
[19:52]<gdaniels> Deepal: yup
[19:52]<Srinath> thilina how ever we start u find  awaay to put MTOM in :)
[19:52]<Thilina> but the prob is ws-atts is also mime
[19:53]<Ajith> atts == Attachements I guess
[19:53]<Thilina> yep
[19:53]<Ajith> the contet type ?
[19:53]<Thilina> theres a type header in the mime message which says
|"application/xop+xml"
[19:53]<Deepal> The prob. is the knowldge abt MTOM is very low
[19:54]<Thilina> if we can read it from transport level then the
rpoblem is solved
[19:54]<Thilina> ALEK said it's possible
[19:54]<gdaniels> ah the outer part is multipart/related - I thought
it was MTOM-specific
[19:54]<Thilina> i just wanted to get it confirmed
[19:54]<gdaniels> So we can't know until we crack the MIME envelope, I think
[19:54]<Thilina> yep
[19:54]<Thilina> MIME-Version: 1.0
[19:54]<Thilina> Content-Type: Multipart/Related;boundary=MIME_boundary;
[19:54]<Thilina>     type="application/xop+xml";
[19:54]<Thilina>     start="<my...@example.org>";
[19:54]<Thilina>     startinfo="application/soap+xml; action=\"ProcessData\""
[19:54]<Thilina> Content-Description: A SOAP
[19:54]<gdaniels> oh no -
[19:55]<Thilina> :D
[19:55]<gdaniels> we have the type parameter
[19:55]<gdaniels> all set :)
[19:55]<Thilina> can v read it from trasport
[19:55]<gdaniels> type="application/xop+xml"
[19:55]<Thilina> yep dats wat i'm mentioning
[19:55]<Ajith> I am not sure how the mail transport handles this
[19:55]<Ajith> I mean MTOM
[19:56]<Thilina> if the transport can handle this my worries are over :)
[19:56]<Chamil> i guess i can program some thing into the mail
reciever to do that
[19:57]<gdaniels> Thilina: Transport certainly could do it, but it
could also be a transport-specific handler.
[19:57]<Thilina> glen: have u looked at the proto at scratch
[19:57]<gdaniels> Thilina: Barely; hope to do so this week
[19:57]<gdaniels> Are there examples/tests in there?
[19:58]<Thilina> glen: u mean v can access it either at trasport or at
a transprot specific header
[19:58]<Thilina> theres one test
[19:58]<gdaniels> handler, not header :)
[19:58]<Thilina> :) yeah . a typo
[19:59]<Ajith> I have a small Q regarding the new OMBlob
[19:59]<Thilina> i'm thinking of looking at some interop tests this week
[19:59]<gdaniels> Thilina: The thing I'd really like to see is a few
coding examples - it's really critical that we make the APIs easy to
use, I think.
[19:59]<Ajith> How do you make out whether to make a blob or just text ?
[19:59]<gdaniels> I still want omElement.createChild(qname,
dataHandler) to just do the right thing. :)
[20:00]<Srinath> ajith u ask the mtom killer Q?
[20:00]<Thilina> Ajith: if the data is in base 64 ( not ooptimised)
then no options have to go for text
[20:00]<Ajith> Hmmm
[20:00]<Ajith> we are not going for schema aware parsing then ?
[20:00]<Thilina> if the data is in MTOM optimised form as <xop:inlude>
then go for OMBlobs
[20:00]<Ajith> building I mean
[20:00]<Srinath> glen how we know the text is base64 binary or a name
.. one is text and other ia ablob?
[20:01]<Deepal> but if it base64 , its also text ?
[20:01]<gdaniels> Srinath: ?  Not sure what you mean.  Example?
[20:01]<Ajith> I was thinking of something like a "builder extension"
but its long to explain
[20:01]<Thilina> text will remain there untill the user wants a binary
[20:01]<Thilina> IMHO it'll depend on the schema
[20:01]<Srinath> glen:say <a>sjifjjforjrgregjtggt</a> tag is found
[20:02]<Deepal> so in that case do we need schema aware parsing ?
[20:02]<Srinath> the text in the middle or 1) test or 2)base 64 binary
[20:02]<Srinath> how do u know
[20:02]<Srinath> ?
[20:02]<gdaniels> Of course we need schema-aware parsing. :)
[20:02]<Srinath> sorry 1) trest = text
[20:03]<Deepal> Sinath : cant it be decide at the service provider
[20:03]<gdaniels> In the absence of metadata, we should be able to ask
for it in whatever form we want
[20:03]<Srinath> but then there is  a code gen part of om? as ajith like ;)
[20:03]<Thilina> at the moment wat I do is create OMText from that.
then later depending on the schema one can request fopr binaries
[20:03]<Ajith> I have some suggestion s but its along story so I will
make a formal suggestion and send it over the mail
[20:03]<gdaniels> element.getText() / element.getBinaryValue()
[20:04]<Srinath> I think schema aware most of the things are troubled water :)
[20:04]<Thilina> OMtext.getDataHandler
[20:04]<Thilina> ()
[20:04]<gdaniels> I'm not sure it makes sense on OMText...
[20:04]<gdaniels> seems more at the element level to me
[20:05]<Srinath> yap
[20:05]<Deepal> +1 glen
[20:05]<Thilina> Glen: wat do u think about treating those base 64
strings as text till somebody asks for the binary
[20:05]<Deepal> if it text node we know it has text :)
[20:05]  *** Jaliya left #apache-axis :
[20:05]<gdaniels> Thilina: Sure that part seems fine, but you ask for
the binary by asking the element, not the OMText... (IMHO)
[20:05]<Thilina> yeah . base 64 text
[20:06]<Srinath> thilina well to avoid it we have MTOM aren,t we?
[20:06]  *** Jaliya joined #apache-axis
[20:06]<Thilina> in the mtom having both base 64 & optimised Mtom in
one message is possible
[20:07]<gdaniels> Oops - I need to run, folks (today is full of meetings :( )...
[20:07]<Ajith> ok then
[20:07]<gdaniels> Talk to you all on email, and see you in a couple of weeks!
[20:07]<Deepal> k
[20:07]<Ajith> guess its time for us to conclude as well
[20:07]  *** gdaniels quit FreeNode :
[20:07]<Thilina> glen: it's like OMText foo;  foo.getDataHandler();
[20:08]<Ajith> enough buddy :  geln is already gone
[20:08]<Ajith> :D
[20:08]<Thilina> :D
[20:08]<Jaliya> :)
[20:08]<Jaliya> Bye all
[20:08]  *** Jaliya left #apache-axis :
[20:09]<Thilina> srinath: is it wat u asked
[20:09]<Ajith> Will post the chat log then
[20:10]<Chamil> bye all :)
[20:10]<Deepal> thanks ajith
[20:10]  *** Chamil quit FreeNode : "Leaving"
[20:10]<Deepal> bye all and GN}}}