Hi,

Jim and I had a discussion on IRC on the databinding to understand it should be 
a concern of "Programming Model" or "Assembly". Attached is the transcript.

Please express your views.

Thanks,
Raymond

(10:13:10 AM) jmarino [EMAIL PROTECTED] entered the room.
(10:13:21 AM) jmarino: Hi refng, yt?
(10:13:30 AM) jmarino: sorry rfeng, yt?
(10:13:30 AM) rfeng: yes
(10:13:48 AM) jmarino: hey I'm just thinking about the databinding stuff. Do 
you have a sec to chat here?
(10:13:58 AM) rfeng: sure
(10:14:53 AM) jmarino: k. A very high-level question: why is the databinding 
specified in the programming model at all as opposed to being an assembly 
concept (since it is something about the physical nature of the wire)?
(10:16:01 AM) rfeng: I would thing assembly level is approparate
(10:16:25 AM) rfeng: think
(10:17:27 AM) rfeng: and it get reflected into the PM?
(10:17:29 AM) jmarino: k so a radical thought: databinding should never really 
be expressed as annotations and should never show up in code except for when 
code explicitly required a dynamic interface (e.g. DataObject). In that case 
the runtime wouldn't require annotations but could introspect the operation 
types either in Java code or WSDL extensions.
(10:18:06 AM) jmarino: it would specified by the binding extension, or maybe in 
SCDL
(10:18:17 AM) jmarino: am I way off-base here?
(10:19:16 AM) rfeng: thinking ...
(10:19:53 AM) jmarino: sure np I'm just on a con call ;-)
(10:20:02 AM) rfeng: maybe it's mixed depending on the use cases
(10:20:24 AM) rfeng: three cases:
(10:20:36 AM) rfeng: 1) between mappable interfaces
(10:20:43 AM) rfeng: 2) complex properties
(10:21:03 AM) rfeng: 3) protocol/binding data format
(10:21:24 AM) jmarino: k in those three cases, why is the databinding 
requirement need to be known by the code or interface?
(10:22:01 AM) rfeng: I guess it's key to well define mappable interfaces
(10:22:20 AM) jmarino: k coul you explain that?
(10:23:28 AM) rfeng: for a client in favor of JAXB, can it talk to a service 
that requires SDO?
(10:24:56 AM) jmarino: sure but the question is the nature of the client and 
service implementations...
(10:25:54 AM) jmarino: do they need to know the databinding technology? If yes, 
isn't it because they need to use dynamic APIs and hence those types should be 
reflected in the contract operations?
(10:26:35 AM) rfeng: Are you thinking of the case that the same interface can 
be used for different databindings?
(10:27:08 AM) jmarino: no that's different. If the same interface can be used 
then there should be no knowledge of the databinding by the implementation
(10:27:18 AM) rfeng: ok
(10:27:45 AM) jmarino: I'm trying to say that most implementations should never 
know about the databinding used just as they don't need to know the physical 
transport
(10:28:12 AM) rfeng: ok, going back to the JAXB --> SDO case
(10:28:13 AM) jmarino: k hold on for a sec...
(10:28:56 AM) rfeng: let's say: CreditReport checkCredit(Csutomer ...). sure
(10:29:06 AM) rfeng: Customer
(10:37:47 AM) jmarino: hi I'm back
(10:37:56 AM) jmarino: sorry
(10:39:52 AM) jmarino: rfeng yt still?
(10:39:55 AM) rfeng: yes
(10:40:03 AM) jmarino: sorry I had to talk for a sec on the call
(10:40:07 AM) rfeng: np
(10:40:15 AM) jmarino: can you continue?
(10:40:26 AM) rfeng: so for the operation CreditReport checkCredit(Customer ...)
(10:41:26 AM) rfeng: the client side passes in JAXB objects and the service 
side expects SDOs (CreditReport' and Customer' are generated SDO classes) 
(10:41:48 AM) rfeng: how do we capture this at assembly level?
(10:41:54 AM) jmarino: why does the service side expect SDOs given that 
contract (strongly typed)?
(10:43:16 AM) rfeng: maybe because my business objects are generated SDO 
classes from the XSD and I don't like JAXB at all :-)
(10:43:36 AM) jmarino: then you should take DataObject as a parameter
(10:43:41 AM) rfeng: I'm not aware of any JAXB clients when the service is 
developed
(10:44:00 AM) rfeng: I don't use DataObject because I want strong-typing
(10:44:13 AM) jmarino: k then you shouldn't care about the databinding
(10:44:26 AM) jmarino: at the programming level
(10:44:47 AM) jmarino: you may have a policy that says "I want to use SDO, etc. 
in these palces..."
(10:44:57 AM) rfeng: you're right from the service side, I treat the annotation 
is just a convient way to help the runtime for this case
(10:44:58 AM) jmarino: but the business logic should not care
(10:45:15 AM) jmarino: k that's my point. It shouldn't be in the code.
(10:45:30 AM) jmarino: same as the physical transport
(10:45:38 AM) rfeng: do we have better way to express that?
(10:45:44 AM) jmarino: yes policy
(10:45:58 AM) jmarino: or through introspection of service contracts
(10:46:09 AM) jmarino: (e.g. if it takes DataObject)
(10:46:15 AM) jmarino: also through the binding extension...
(10:46:26 AM) jmarino: e.g. "I only know these formats..."
(10:46:48 AM) rfeng: it's not easy to introspect for cases that Customer 
doesn't extend from DataObject
(10:47:15 AM) jmarino: right and in that case the code should not specify 
anything since it doesn't need to care what databinding is in use
(10:47:29 AM) jmarino: it's the same principle as physical bindings
(10:47:59 AM) rfeng: can you give me a pesuo policy for this purpose?
(10:48:45 AM) jmarino: k, for binding type X (e.g. JMS) use SDO to encode the 
payload
(10:48:57 AM) jmarino: policy intents should be key
(10:49:14 AM) jmarino: another example...
(10:49:41 AM) jmarino: the "foo" binding only knows how to serialize using 
XmlBeans. That is specified by the binding extension
(10:50:00 AM) rfeng: yes
(10:50:26 AM) jmarino: so I'm not sure we need annotations at all
(10:51:21 AM) rfeng: but java annotations could be a convenient way, because 
they know what databinding they're using even they don't care
(10:52:18 AM) jmarino: I think the issue is more fundamental. Annotations burn 
things into the programming model that should not be there. In SCA we do not 
allow people to burn in the physical binding...Also, I think not having them 
simplifies things
(10:52:24 AM) rfeng: does the assembler have the knowledge?
(10:53:14 AM) rfeng: I agree with you on the proper use of annotations 
(10:53:17 AM) jmarino: they may or may not. If they don't the runtime will have 
the knowledge
(10:54:11 AM) rfeng: How does the runtime acquire the knowledge?
(10:54:35 AM) jmarino: it may know from the binding extension (or component 
extension maybe)
(10:54:42 AM) rfeng: yes
(10:54:53 AM) rfeng: axis2 binding may claim AXIOM only
(10:55:20 AM) jmarino: yes. Or it could be constructed in such a way to allow 
it to be configured to take almost anything
(10:55:30 AM) jmarino: then the binding could be configured
(10:56:35 AM) rfeng: how about the case that no bindings are involved, 
component talks to component over remotable interfaces?
(10:57:08 AM) jmarino: then policy could be used or the runtime could choose 
through some algorithm
(10:57:24 AM) rfeng: ok
(10:57:46 AM) jmarino: e.g. "the most performant thing is binary foo so I will 
use that"
(10:58:04 AM) rfeng: so the required info can be captured from the policies or 
introspections
(10:58:15 AM) jmarino: or from the extensions
(10:58:20 AM) rfeng: yes
(10:58:35 AM) rfeng: and part of them are defined using SCDLs?
(10:58:36 AM) jmarino: this way we keep the programming model "above" these 
concerns
(10:58:47 AM) jmarino: yes through policy
(10:59:13 AM) jmarino: I think this is different than just moving things from 
annotations to xml though
(10:59:39 AM) jmarino: most of the time nothing will need to be specified in 
SCDL or any application artifacts
(10:59:42 AM) rfeng: could the policy def become fairly complicated as we 
discussed the parameter-level databindings?
(10:59:45 AM) rfeng: I agree
(11:00:07 AM) jmarino: agree on complexity. I think we will need to work 
through that use case
(11:01:42 AM) jmarino: how do you want to proceed?
(11:02:03 AM) rfeng: for WSDL cases, it's usually simple
(11:02:15 AM) rfeng: it's a bit messy for java interfaces
(11:02:40 AM) rfeng: should we keep as is for M2 and fix it in M3?
(11:05:42 AM) jmarino: I don't think we should expose something fundamental 
like that if possible
(11:08:25 AM) rfeng: sorry, taking care of my kid for a few mintutes
(11:08:56 AM) jmarino: sure let's reconvene a bit later. I've got to go too
(11:09:02 AM) rfeng: sure

Reply via email to