Hi,
We had a chat on IRC brainstorming how JMS binding can leverage the
databinding framework. Please see the transcripts below for more details.
A brief summary:
1) There are two service contracts involved for services or references
with JMS bindings:
a) The service contract from <interface ...>
b) The service contract from the binding (which can be a
javax.jms.MessageListener).
2) We may need an interceptor to do ServiceContract mapping. For example,
it uses the OperationSelector to map a JMS message to a given operation on
the interface.
3) Databinding options are exploited. There may be two options:
a) For reference, transform the Object[] into an intermediate format
such as XMLString, the JMS binding code will construct the Message. For
service, the JMS binding code will extract the XMLString from the Message
and the databinding framework will transform the XMLStrings into Object[].
b) A transformer transforms the Object[] into a Message and vice
versa. This requires that the JMS Session accessible from the transformation
context.
Thanks,
Raymond
(3:07:50 PM) rajith_home: rfeng, hello
(3:09:27 PM) dkulp left the room (quit: Remote closed the connection).
(3:12:05 PM) rfeng: rajith?
(3:12:42 PM) rajith_home: rfeng, can you please answer the question on
databinding sent to the list.
(3:12:49 PM) rfeng: just came back from a training class
(3:12:57 PM) rfeng: sure, I'll
(3:13:00 PM) rajith_home: rfeng, I still feel that I haven't understood
the whole concept
(3:13:06 PM) rfeng: ok
(3:13:16 PM) rajith_home: rfeng, thansk raymond and sorry for bugging you
(3:13:16 PM) rfeng: which part?
(3:13:20 PM) rfeng: np
(3:14:00 PM) rajith_home: rfeng, I need to understand where I have to
indicate the expected data type
(3:14:39 PM) rajith_home: rfeng, so then in the target invoker and in my
service I can work with my prefered data type and let the framework do the
conversion
(3:15:08 PM) rfeng: let's put this way
(3:15:28 PM) rfeng: you're implementing a JMS binding
(3:15:42 PM) rajith_home: rfeng, now axis2 works with AXIOM, but I want to
work with Object[] for invoking methods, but I want to serialize them to xml
when I send them over the wire
(3:15:46 PM) rajith_home: rfeng, sorry go ahead
(3:15:59 PM) rfeng: for reference (outbound) and service (inbound), right?
(3:16:10 PM) rajith_home: yes
(3:16:22 PM) rfeng: let's start with the reference
(3:16:44 PM) rfeng: assuming you use java interface to model your
reference
(3:17:05 PM) rfeng: or WSDL?
(3:17:24 PM) rajith_home: I use java interface
(3:17:27 PM) rfeng: ok
(3:18:13 PM) rfeng: there is an operation: String concat(String s1, String
s2)
(3:18:24 PM) rajith_home: ok
(3:18:26 PM) rfeng: how do you want to create the JMSMessage?
(3:19:24 PM) rajith_home: ok, the operation name is send as a jms
property, and the arguments should be serialized (XML, java
serialization...etc), but XML is preffered. The arguments are sent as the
jms payload
(3:19:36 PM) rfeng: component1.ref1 --> composite.reference w/ JMS binding
--> JMS layer
(3:19:46 PM) rajith_home: yep
(3:21:03 PM) rfeng: so the JMS binding builder will tell me the native
ServiceContract for the JMS layer
(3:21:28 PM) rajith_home: ok thats a part I missed
(3:21:36 PM) rajith_home: now where does the conversion happen, and what
do I have to do to get the required conversion from say object[s1,s2] to
some xml serialization
(3:21:52 PM) rajith_home: so I need to specifiy the native format ?
(3:22:29 PM) rfeng: if you tell me that the native format is XMLString
(3:23:22 PM) rajith_home: it is XML string, btw how do u specifiy this in
the binding builder?
(3:24:00 PM) rfeng: The databinding interceptor on the outbound wire of
the reference will find a transformer which can convert s1, s2 into xml
(3:25:16 PM) rfeng: in your case, really you don't have a ready-to-use
ServiceContract for the JMS layer, so maybe clone the JavaServiceContract
and call setDataBinding()
(3:25:55 PM) rfeng: maybe we should transform the Object[] as a whole
(3:26:03 PM) rfeng: right now it's arg by arg
(3:26:10 PM) rajith_home: ok I see
(3:26:15 PM) rajith_home: so in my target invoker what should I expect
then for the payload?
(3:26:27 PM) rfeng: but you can claim the JMS contract is wrapped
(3:27:07 PM) rfeng: and the JMSDataBinding will provide a wrapper handler
(3:27:23 PM) rfeng: in your case, the wrapper can be the JMSMessage
(3:27:33 PM) rfeng: and args are children
(3:28:29 PM) rajith_home: so u mean I pass in the arguments and the
JMSDataBinding class will return me a JMS Message?
(3:28:34 PM) jboynes: the wrapper being a transform that converts Object[]
to JMSMessage?
(3:29:00 PM) rajith_home: LOL, same idea
(3:29:10 PM) rfeng: yes
(3:29:16 PM) rajith_home: well to be honest thats more inline with the
spec
(3:29:48 PM) rajith_home: so I register my JMSDataBinding with the
registry as another framework?
(3:30:10 PM) rajith_home: like sdo,xmlbeans, jaxb.axiom ..etv
(3:30:14 PM) rfeng: so the JMSMessageDataBinding will register itself with
the DataBindingRegistry
(3:31:21 PM) rfeng: the incoming data is Object[] (unwrapped)
(3:31:23 PM) rajith_home: hmm makes more sense now, and I can use what
ever serialization I want for the objects when I implement the
JMSDataBinding
(3:31:37 PM) rfeng: and if we detect the target operation is wrapped
(3:32:01 PM) rfeng: we lookup the WrapperHandler (from DataBinding)
(3:32:35 PM) rfeng: then call create() to create the wrapper (in your case
JMSMessage)
(3:32:53 PM) rfeng: then call setChild(wrapper, child ,...)
(3:33:18 PM) jboynes: rfeng: I hate to ask, but why is wrapping special?
(3:33:29 PM) rajith_home: rfeng, to create a JMS message we need to have
access to a jms session, so my data binding class needs to be given a
session, so is that dependency acceptable?
(3:33:40 PM) jboynes: isn't it just another data transform?
(3:33:57 PM) rfeng: it's another data transform
(3:34:34 PM) rfeng: we have Input2Input, Output2Output transformers which
deal with it
(3:34:49 PM) jboynes: ok
(3:34:51 PM) jboynes: cool
(3:34:57 PM) tsee [EMAIL PROTECTED] entered the
room.
(3:35:18 PM) jboynes: I was confused by create() and setChild() - it
sounded like there was a different api
(3:35:49 PM) rfeng: That's used to define the wrapping capabilities from
different databindings
(3:35:51 PM) rajith_home: ok, I got lost again, what did u mean by
Object[] (unwrapped) ?
(3:36:25 PM) bhdaniel left the room (quit: Read error: 145 (Connection
timed out)).
(3:36:30 PM) rfeng: meaning each element in the Object[] is the real arg
(3:36:41 PM) rfeng: (s1, s2)
(3:37:11 PM) rfeng: I guess there're two choices for JMS case
(3:37:34 PM) rajith_home: rfeng, ok and if the target operation is
expecting a JMS message then we need to wrap the args inside a JMS message
(3:37:42 PM) rfeng: 1) convert (s1, s2) to an intermediate format and the
target invoke will take that to create the JMSMessage
(3:38:05 PM) rfeng: 2) Directly convert (s1,s2) to a JMSMessage
(3:38:25 PM) rajith_home: rfeng, convert to XML and give it to me so I can
transport it inside a JMS message
(3:38:35 PM) rfeng: which one do you prefer? 1?
(3:38:55 PM) rajith_home: option 2 mean my JMSDataBinding class needs
access to a jms session to create the message
(3:39:01 PM) rfeng: yes
(3:39:07 PM) rajith_home: rfeng, so option 1 is better
(3:39:11 PM) rfeng: ok
(3:39:22 PM) rfeng: then it could be simpler
(3:40:13 PM) rajith_home: rfeng, jboynes do we need to support the case
where the target component is expecting a message? if thats the case then
the target component needs to know how to parse the payload
(3:40:46 PM) rajith_home: rfeng, jboynes which is not every elegant in my
opinion.
(3:41:27 PM) jboynes: don't get that
(3:41:32 PM) rajith_home: rfeng, os it's better if [s1,s2] --> xml --> jms
msg --> xml --> [s1,s2]
(3:41:57 PM) jboynes: I think option 2 sounds better
(3:42:09 PM) rfeng: :-)
(3:42:17 PM) jboynes: s1, s2 could convert to XML using different
serializers
(3:42:42 PM) rajith_home: jboynes, well if the target component has a
operation like onMessage(javax.jms.Message message) then it needs to know
how to parse the payload and extract the arguments or business data
(3:42:53 PM) jboynes: so [s1,s2] -> [x1, s2] -> [x1, x2] -> JMSMessage
(3:43:25 PM) jboynes: rajith_home: if that's its service contract then
that would be what it was expectinvg
(3:43:56 PM) rajith_home: jboynes, agreed also if people want [s1,s2] -->
java serialized --> bytes message --> java serialized --> [s1,s2]
(3:44:20 PM) jboynes: yes
(3:44:22 PM) rfeng: I think the reference and service side can be asymtric
(3:44:42 PM) jboynes: yes
(3:45:32 PM) rajith_home: jboynes, if it expects a message directly then
the component invoking the reference will obviously needs to send some
business data in the payload in a format the target component understands
(3:45:35 PM) rfeng: s1, s2 --> jms .... jms ... --> SDO, SDO
(3:46:02 PM) jboynes: it would depend on what the target component was
doing with the message
(3:46:09 PM) jboynes: it may never need to deserialize the payload
(3:46:19 PM) rfeng: right
(3:46:20 PM) jboynes: it may just be forwarding it on
(3:46:48 PM) jboynes: but another component might want us to do the
deserialization
(3:46:58 PM) rfeng: the JMSMessage is picked up the service and delegate
downstream to target component
(3:47:12 PM) jboynes: but in that case it would not be expecting a Message
but one or more bits of business data
(3:48:19 PM) jboynes: it may even expect a combination
(3:48:33 PM) jboynes: doStuff(Message msg, Order payload)
(3:50:04 PM) rfeng: Assume this flow: JMS --> (service.binding) Message
--> (service.interface SDO) --> (component.interface, Message)
(3:51:12 PM) rfeng: by default, it goes from Message to SDO and then back
to Message (not sure the 2nd part is possible)
(3:51:31 PM) rfeng: but we can optimize to have Message --> Message
(3:52:01 PM) rfeng: because the service.interface is for wiring purpose
(3:53:21 PM) rfeng: jboynes, we may have to transform Object[] as a whole
in generic cases
(3:53:28 PM) rfeng: instead of arg by arg
(3:54:14 PM) rajith_home: jboynes, rfeng extreamly sorry I had to change
me kids diaper :-)
(3:54:23 PM) rajith_home: jboynes, rfeng sorry for the delay
(3:54:35 PM) rfeng: np, I do the same job
(3:54:42 PM) rajith_home: LOL
(3:54:52 PM) jboynes: one is tempted to say s**t happens
(3:55:05 PM) rfeng: :-)
(3:55:06 PM) jboynes: sorry
(3:55:18 PM) rajith_home: jboynes, and it happens during the most
important conversations
(3:56:18 PM) jboynes: back on track, rfeng why would generics make a
difference?
(3:56:39 PM) rfeng: didn't mean to java generics
(3:56:53 PM) jboynes: ah
(3:57:32 PM) rfeng: I'm thinking of the case that transform from Object[]
to another Object[] (the size can be different)
(3:58:27 PM) rfeng: for the wrapping case, we transform Object[n] to
Object[1] (the only child is the wrapper)
(3:58:29 PM) jboynes: wouldn't arg-by-arg just be a series of Object[]
transforms
(3:58:56 PM) jboynes: Object[s1, s2] -> Object[t1, s2]
(3:59:13 PM) rfeng: yes it is
(3:59:29 PM) rajith_home: ok so we need to handle the message --> message
case and then object[] ---n transformations -- object[] ?
(3:59:47 PM) jboynes: so its a transform of an Object[] to an Object[]
with different contnt
(3:59:52 PM) jboynes: content
(3:59:58 PM) rajith_home: yes
(4:00:03 PM) rfeng: yes
(4:00:47 PM) tsee left the room (quit: Read error: 110 (Connection timed
out)).
(4:00:54 PM) rajith_home: but when u code the invoker and the service
which data type should u work with? thats where I am convinced, what should
expect in the payload in the invoke method
(4:01:04 PM) rfeng: so the incoming data is Object[] {s1, s2}
(4:01:20 PM) jboynes: rajith_home: which invoker?
(4:01:20 PM) rfeng: then it got converted to {Message} if we follow option
2
(4:01:34 PM) rajith_home: sorry conviced should be changed to confused :-)
(4:02:04 PM) rfeng: then the target invoker should just send the Message
out
(4:02:34 PM) rajith_home: JMSTargetInvoker invoke()
(4:02:55 PM) jboynes: rfeng: you're saying the target invoker for the JMS
binding should expect to have a Message in the payload
(4:02:57 PM) jboynes: ?
(4:03:13 PM) rfeng: for option 2
(4:03:18 PM) jboynes: or actually, can assume it has a Message in the
payload
(4:04:05 PM) rfeng: what's the difference?
(4:04:08 PM) lresende [n=
[EMAIL PROTECTED] entered the room.
(4:04:14 PM) jboynes: none
(4:04:23 PM) jboynes: just trying to clarify my phrasing
(4:04:30 PM) rajith_home: jboynes, so does it mean that we have a
transformer registered that will convert this object array into some
serialized format and then shove it into a jms message?
(4:04:37 PM) rfeng: ok, that's what I meant.
(4:04:52 PM) jboynes: I think that would be a set of transformers but yes
(4:05:28 PM) rfeng: it could be a transformer invoking other transformers
(4:05:44 PM) rfeng: using the mediator interface
(4:05:59 PM) jboynes: or just a transform pipeline?
(4:06:15 PM) rajith_home: can we defined the path using these
transformers, for example [s1,s2] --> some xml --> JMS message ?
(4:06:27 PM) rfeng: yes
(4:06:59 PM) rajith_home: rfeng, where is that defined ? in the code? or
in some config ?
(4:07:32 PM) rfeng: let's assume the java interface for your JMS reference
is annotated with SDO databinding
(4:08:49 PM) rfeng: then we try to convert the SDO input to XMLString
(expressed by the JMS binding) using SDO-->XMLString transformer
(4:10:09 PM) rajith_home: rfeng, ok
(4:10:23 PM) rfeng: jboynes, a related question here
(4:10:52 PM) jboynes: ok?
(4:11:07 PM) rfeng: if I have an operation say String
doSomething(DataObject, String, Customer)
(4:11:22 PM) rfeng: it seems that operation level databinding is not good
enough
(4:11:52 PM) rfeng: for me to identify which arg needs to convert
(4:12:37 PM) jboynes: unless you are assuming SDO throughout, no
(4:12:54 PM) jboynes: if Customer is e.g. JAXB then you need per-arg
(4:13:03 PM) rfeng: should we add the parameter-level databinding back?
(4:13:35 PM) rajith_home: rfeng, I thought we don't support mixed argument
types
(4:13:43 PM) rfeng: I also have a simple case such as op(String str1,
String str2)
(4:13:49 PM) jboynes: i think the reason it was dropped was that we didn't
think anyone would be crazy enough to do that ;-)
(4:14:10 PM) rfeng: and I expect str1 is XML but str2 is a plain string
(4:14:33 PM) rfeng: I don't have a way to express that
(4:15:14 PM) jboynes: physical type String, logical type an element QName
?
(4:15:41 PM) rfeng: yes, but it cannot be expressed at operation level
(4:16:06 PM) jboynes: oh
(4:16:09 PM) rfeng: because for str2, I want to have (String, String,
java-data-binding)
(4:16:39 PM) rfeng: meaning no conversion will apply to str2
(4:17:04 PM) jboynes: sounds like per-arg is not that crazy after all
(4:17:13 PM) rfeng: I found it different to decide which arg needs to
convert
(4:17:26 PM) rfeng: or not to convert
(4:18:05 PM) rfeng: for WSDL portType, seems to be fine with
interface-level databinding
(4:18:46 PM) rfeng: because its types are usually modeled using XSD, and
there should be a XML binding behind it (AXIOM, DOM, JAXB or SDO)
(4:19:18 PM) rfeng: for java interface, it's a bit challenging
(4:19:26 PM) rajith_home: exactly
(4:19:52 PM) rajith_home: so do I have to support per argument level data
binding for jms binding as well? will it makes sense?
(4:20:17 PM) rfeng: I don't think so
(4:21:00 PM) rfeng: to me , the JMS message is a carrier of business data
which is transparent to other components
(4:21:04 PM) rajith_home: I guess the simple case of [s1,s2] -->
intermediate --> jms --> intermediate --> [t1,t2] is fine
(4:21:12 PM) rajith_home: yes
(4:21:57 PM) rfeng: if you express the requirement of an intermediate
format, the wiring fabric can convert for you (the jms binding code)
(4:22:51 PM) rajith_home: u mean my JMSDataBinding code will convert from
the object[] to lets say XML and vice verca ?
(4:23:20 PM) rajith_home: rfeng, do u prefer that route
(4:24:15 PM) rfeng: what's your requirement on the Object[]?
(4:24:46 PM) rfeng: if you use the java interface to define a reference
with JMS binding?
(4:25:11 PM) rfeng: I mean the expectation from the JMS binding side?
(4:25:45 PM) rajith_home: for example [string, int, string] just simple
data types and the target component expects the same
(4:25:59 PM) jboynes: i would think there would be multiple JMS data
bindings
(4:26:22 PM) jboynes: in that case what would the message be?
(4:26:43 PM) jboynes: I can see Object[string, int, string] ->
ObjectMessage
(4:27:07 PM) rajith_home: the operation name is mapped as a jms propert
and the the arguments serialized as the payload
(4:27:27 PM) jboynes: and Object[string, int, string] -> DOM(foo:msg) ->
TextMessage containing XML
(4:27:38 PM) rajith_home: the serialization could be xml or java
serialization so it could be a text msg or object or even bytes msg
(4:27:44 PM) rfeng: maybe we should follow the java 2 WSDL doc-lit wrapper
mapping
(4:27:56 PM) rfeng: then we have clean data contract
(4:28:30 PM) jboynes: rajith_home: in that case isn't the operation name a
constant value
(4:28:38 PM) jboynes: added to the specific bindng
(4:28:55 PM) jboynes: and the binding would insert that to the Message
(4:30:03 PM) rajith_home: yes the binding defines a operation selector
(4:30:17 PM) jboynes: yes
(4:30:38 PM) rajith_home: the op selector decides how to encode the
operation name and also how to extract it from the jms message
(4:30:44 PM) jboynes: we could actually implement that as an
interceptor/transform
(4:31:18 PM) jboynes: the binding service contract could be
onMessage(Message)
(4:31:48 PM) rfeng: yes
(4:32:01 PM) jboynes: and an interceptor routes that to a different chain
based on content of the message
(4:32:19 PM) jboynes: e.g. using the supplied OperatonSelector
(4:32:36 PM) rajith_home: yes, if thats the case then it doesn't make
sense to encode the operation name in the jms message and the payload will
contain business data instead of encoded arguments
(4:33:01 PM) jboynes: lost me there
(4:33:31 PM) rajith_home: sorry I replied to "the binding service contract
could be onMessage(Message)", didn't see your latest post
(4:34:02 PM) jboynes: ah
(4:34:57 PM) rajith_home: so the operation selector acts as a transformer?
but it doesn't define any data transformation right? it mearly describes how
to encode/decode the operation name from a message
(4:35:35 PM) jboynes: I think its more of an interceptor
(4:35:38 PM) rajith_home: so I am not sure if the op sec qualifies as a
transformer. maybe I didn't understand your point
(4:35:50 PM) rfeng: do you expect the JMSMessage from other non-SCA
client?
(4:36:03 PM) rajith_home: thats the intention of the spec group
(4:36:09 PM) rfeng: ok
(4:36:29 PM) rfeng: then we need to have a well-defined wire format for
JMS message?
(4:36:36 PM) rajith_home: specially we could be accessing a non SCA
resource like some legacy JMS application
(4:36:39 PM) jboynes: I'm thinking there are two service contracts in the
Service with a JMS binding
(4:36:55 PM) jboynes: the first is MessageListener
(4:36:58 PM) rfeng: seems so
(4:37:05 PM) jboynes: that's the binding contract
(4:37:10 PM) rfeng: 2nd is mapped interface
(4:37:19 PM) jboynes: the other is the Service's interface e.g. Foo.class
(4:37:33 PM) jboynes: as defined by the <interface>
(4:37:40 PM) rfeng: yes
(4:38:10 PM) jboynes: the first part of the interceptor stack converts
between those two contracts
(4:38:55 PM) rajith_home: jboynes, when I coded the JMS service I register
it as a JMS listener, it picks up the message and invoke a java interface
after converting the payload into an object[]
(4:39:04 PM) jboynes: e.g. using an interceptor to call the
OperationSelector to map from onMessage to the operation in Foo
(4:39:30 PM) rfeng: what invocation chain is the interceptor added?
(4:39:43 PM) rfeng: the fixed onMessage operation?
(4:39:47 PM) jboynes: yes
(4:40:01 PM) jboynes: it maps from one chain to many
(4:40:14 PM) rfeng: ok
(4:40:23 PM) jboynes: rajith_home: we're trying to cut out the prozy
invoke
(4:40:29 PM) jboynes: s/prozy/proxy/
(4:40:40 PM) rfeng: one inbound chain to many outbound chains to the
target component
(4:41:06 PM) jboynes: hmm
(4:41:09 PM) rajith_home: jboynes, I see
(4:41:22 PM) jboynes: one inbound chain to many inbound changes to the
Service
(4:41:28 PM) jboynes: s/changes/chains/
(4:43:00 PM) rfeng: why do you need to have many inbound chains in this
case?
(4:43:01 PM) rajith_home: jboynes, so if we cut the proxy invoke then we
always have fixed operation as rfeng suggested. So onMessage()?
(4:43:31 PM) jboynes: for the binding contract yes
(4:43:50 PM) jboynes: as that is the interface we are exposing to the JMS
implementation
(4:43:57 PM) rfeng: right
(4:44:23 PM) rajith_home: rfeng, jboynes I need to go pick up my wife from
school, I really hate to leave in the middle of a conversation, but have no
choice
(4:44:32 PM) jboynes: [ I'm going to have to cut and run in a bit - no
diapers, collecting kid from school ]
(4:44:33 PM) rfeng: sure, np.
(4:44:39 PM) jboynes: me too
(4:44:46 PM) jboynes: sounds like a good time to take abreak
(4:44:48 PM) rfeng: I'll think more
(4:44:50 PM) rajith_home: rfeng, jboynes cool
(4:45:01 PM) rfeng: ttyl
(4:45:02 PM) jboynes: rfeng: as the last survivor, can you summarize/post
this to the list
(4:45:09 PM) jboynes: please
(4:45:09 PM) rfeng: sure
(4:45:14 PM) jboynes: thanks
(4:45:18 PM) rajith_home: are u guys comming to apache con?
(4:45:29 PM) jboynes: i think I am
(4:45:36 PM) jboynes: not confirmed yet
(4:46:18 PM) rajith_home: we need to come to some resolution on the data
binding stuff and the binding contract before I move any forward :-(
(4:47:20 PM) rajith_home: ant has the patch commited to
../sandbox/rajith... so feel free to dig in and change stuff if u guys wanna
experiment
(4:47:36 PM) rajith_home: rfeng, jboynes bye guys and thanks for the
support
