[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] RE: [ASSEMBLY-31] Wiring from a reference with nobinding to a service with a binding
Peter, I'll admit that I know very little about JMS (though I intend to learn much more). I used JMS as an example to make a point, and from your reply I believe that I have made it reasonably effectively. If these are the semantics of using "real JMS" to make a call, then any optimization must preserve the same semantics. This does not look very simple! I do have some relevant experience, though not for JMS. In a past life, I implemented local calling optimizations for RMI-IIOP, and there were some "interesting" wrinkles including very careful attention to cases involving different classloaders at the source and target ends. In that case, correct semantics could only be preserved by baking this optimization into the RMI-IIOP runtime. I think the same is likely to be the case for JMS. Replacing the JMS invocation by some other kind of "optimized" local call doesn't seem likely to preserve all of the expected semantics. Simon Simon C. Nash, IBM Distinguished Engineer Member of the IBM Academy of Technology Tel. +44-1962-815156 Fax +44-1962-818999 "Peshev, Peter" <peter.peshev@sap.com> 06/12/2007 17:36 To Simon Nash/UK/IBM@IBMGB, "OASIS Assembly" <sca-assembly@lists.oasis-open.org> cc Subject RE: [sca-assembly] RE: [ASSEMBLY-31] Wiring from a reference with no binding to a service with a binding Hi Simon, can we clarify first the "observable JMS semantics" . For queues it is guaranteed that there will be exactly once delivery, there will be no side effect. (Assuming the local call deals with crashes and provides the quality of service required by the intents) For JMS topics it is quite different, where as side effect of a call to a service, a message should be sent, and another service from another component on the same topic could be invoked. Such usage of topics coincides pretty much to some pub/sub messaging model that let's say is in scope of this TC to discuss. Is this your understanding as well ? Best Regards Peter -----Original Message----- From: Simon Nash [mailto:NASH@uk.ibm.com] Sent: Thursday, 6. December 2007 17:55 To: OASIS Assembly Subject: RE: [sca-assembly] RE: [ASSEMBLY-31] Wiring from a reference with no binding to a service with a binding I don't want to spoil the party, but... It's clearly fine to do this local optimization for <binding.sca>. But it is OK to do this for <binding.jms>? To make this safe, it would be necessary to ensure that all observable JMS semantics are preserved. Are we agreed that any local optimization would need to do this? Simon Simon C. Nash, IBM Distinguished Engineer Member of the IBM Academy of Technology Tel. +44-1962-815156 Fax +44-1962-818999 "Peshev, Peter" <peter.peshev@sap.com> 06/12/2007 14:03 To Mike Edwards/UK/IBM@IBMGB, "OASIS Assembly" <sca-assembly@lists.oasis-open.org> cc Subject RE: [sca-assembly] RE: [ASSEMBLY-31] Wiring from a reference with no binding to a service with a binding Hi Mike, At least to me that's very good model and clear description that solves nicely ASSEMBLY-1 & 31 as long the last paragraph is kept. Best Regards Peter From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] Sent: Thursday, 6. December 2007 11:36 To: OASIS Assembly Subject: RE: [sca-assembly] RE: [ASSEMBLY-31] Wiring from a reference with no binding to a service with a binding Peter, After some private discussions of the issues with Dave, I now believe that Dave's proposal is the right one. The treatment of services should not be exactly the same as the treatment of references. Creating a proxy object for a reference is a very different process from the business of creating an endpoint for a service. It is reasonable for an SCA runtime to know in advance what endpoints it has to create for the services present in the domain - and that the idea that new endpoints have to be created merely to satisfy a new client reference turning up somewhere in the domain is not reasonable. So, I think that the principle for a service needs to be that there will be an endpoint created for each binding explicitly declared for the service, with the existence of a binding.sca endpoint IF no explicit binding is specified. The point you make in the last paragraph below, I believe DOES apply to references. So, for a reference, a "binding.sca" (either implicit or explicit) can be taken to mean "give me a connection to the target service(s), using whatever communication means are available". In this case, I think that the proxies given to the component for the reference could each deal with a separate protocol and that the protocol used simply "matches" the target service's protocol. I agree - in these cases the protocol used by the proxy is irrelevant to the implementation code. IF the reference or the service requires a particular protocol for some reason, then that need should be expressed via an intent and the presence of the intent would then limit the range of protocols that can be used. So, I think it gives us a clean model where: a) For services, you get endpoints for each explicitly declared binding, with the default of binding.sca if there is no explicit binding. Multiple bindings imply multiple endpoints. b) For references, you get proxies using any of the declared bindings, with the default of binding.sca if there is no explicit binding. The binding actually used for a given wire depends on the binding(s) attached to the target service, where the principle is to select compatible bindings (for the moment, I take that to mean the binding types must be the same). In addition, binding.sca is "flexible" for the purposes of wiring and will match ANY binding on the target service(s). I think that this is the simplest model and avoids the problem associated with the model which you have proposed, that binding.sca may or may not be present depending on whether it can or cannot satisfy the intents attached to the reference. I think that the model I propose has the merit of simplicity and encourages the creation of simple compositions, where most references to targets within the domain either have no explicit binding at all (the 80% case) or have binding.sca attached, while any service endpoints which need an explicit binding attached in order to be available outside the domain don't have to be concerned about additional endpoints being necessary for clients within the domain. I note that the principle of "optimised communication" between clients and providers that run on the same machine or within the same process, is not affected by this model. The runtime is ALWAYS free to optimise communications, as long as the interfaces to both client and provider code are honoured. Yours, Mike. Strategist - Emerging Technologies, SCA & SDO. Co Chair OASIS SCA Assembly TC. IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain. Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431 Email: mike_edwards@uk.ibm.com "Peshev, Peter" <peter.peshev@sap.com> wrote on 06/12/2007 08:51:22: > Hi Mike, > > OK, I understand we have different opinion between me and you + Dave > > But can you help me understand why ? I guess you are afraid that the > component may break without binding.xyz in the scenario below. However > the contract between the SCA assembly and the programming technology is > the interface that is on the service. If the SCA runtime can construct > objects fulfilling the interface, then what is the problem ? > > I.e. does it makes a difference for a component with interface.wsdl > whether its XML-ish data objects in the interface were received via > HTTP POST operation, via SOAP over JMS, or by direct local call ? > > Best Regards > Peter Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]