[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] [NEW ISSUE] Wiring from a reference with no binding to a service with a binding
Hi Dave, I don't agree with you that there is no information. If the provider wanted to say "I can work only with XYZ and I would break without it" he should have specified the intent XYZ, otherwize what is the meaning of those intents ? And if it is mising, we can assume safely that it is ok to do whatever calls to it (i.e. binding.sca) However having such hardcoded usage of transport layer API-s and "I would break without it" should be extremely rare and more theoretical use case. I personally don't think that implementation.java for instance would allow access to the underlying transport infrastructure (s). Best Regards Peter -----Original Message----- From: David Booz [mailto:booz@us.ibm.com] Sent: Thursday, 29. November 2007 17:54 To: sca-assembly@lists.oasis-open.org Subject: RE: [sca-assembly] [NEW ISSUE] Wiring from a reference with no binding to a service with a binding In the absence of any other information, we don't know if the provider specified binding.xyz because there is a provider component implementation dependency on binding.xyz or for some other reason. Therefore, it seems that the conservative approach would be (A). There are several ways that a clever vendor could achieve that goal....and there might even be a locally optimized form of binding.xyz. If you really want this provider exposed locally because binding.xyz doesn't have a locally optimizable form or for some other reason, then do it. One way might be to add binding.sca to the provider. Dave Booz STSM, SCA and WebSphere Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:booz@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome "Peshev, Peter" <peter.peshev@sap .com> To David Booz/Poughkeepsie/IBM@IBMUS, 11/29/2007 10:08 <sca-assembly@lists.oasis-open.org> AM cc Subject RE: [sca-assembly] [NEW ISSUE] Wiring from a reference with no binding to a service with a binding Hi Dave, A question for your scenario : Suppose someone exposes on the domain a service with binding.xyz (no XYZ related intents), than deploys another component that wires to this service and there is no binding (or only binding.sca) on the reference of this second component. What should happen at runtime with the reference with the "morphed" binding.sca being used : A) The runtime implementation of "morphed" binding.sca MUST use the transport protocol as specific to binding.xyz B) The binding.sca MAY use the transport protocol (or for example it may do local calls satisfying the policies if the vendor detects that both components are from the same JVM / process / etc.) Best Regards Peter -----Original Message----- From: David Booz [mailto:booz@us.ibm.com] Sent: Thursday, 29. November 2007 15:59 To: sca-assembly@lists.oasis-open.org Subject: RE: [sca-assembly] [NEW ISSUE] Wiring from a reference with no binding to a service with a binding First to Mike E's proposal with my comments <dab> </dab>: - binding.sca is only present on a service or a reference if: a) it is explicitly specified b) no binding is specified at all (ie then it is the default binding) <dab> right </dab> - binding.sca is regarded as compatible for wiring purposes with any other binding type, and the actual binding used is the binding type on the other end of the wire. If both ends of the wire are binding.sca then the runtime is free to choose the actual binding to use. <dab> This raises a deployment problem when new clients, which use something other than binding.sca, are deployed after a service that exposes only binding.sca. This would force the service to be re-deployed in order to create the new protocol/binding endpoint. </dab> binding.sca will be declared as supporting a particular set of intents <dab> I assume this is done through the bindingTypes declaration so that vendors can decide what intents they want their binding.sca implementation to support.</dab> if a reference or service uses intents not supported by binding.sca then it is an error if binding.sca is used for that service/reference <dab> right </dab> Second, to Peter's idea: In general I agree because it avoids the deployment problem I mentioned above and because binding.sca should be the 80%, maybe 90% use case for component interactions. The additional burden for the 10-20% is not onerous IMHO. Going back to the original problem, another alternative might be to have slightly different rules for consumers versus providers. I don't like asymmetry, but let's try this out anyway for a moment. What if we allowed a reference with only binding.sca to wire to any provider binding, AND we require that any non-binding.sca reference to match (binding type match) a provider binding? 1) This avoids the deployment problem. 2) This would allow a reference binding.sca implementation to morph itself into any provider binding (ed: which is one of the reaons that SCA should _never_ try to create a cross vendor interoperable binding.sca). It enables easier access to the one of the 10-20% use cases (domain component using another Domain component that is also exposed outside the domain). 3) It would also work with callbacks as the provider only has to be able to speak what he's already configured to speak. Dave Booz STSM, SCA and WebSphere Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:booz@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome "Peshev, Peter" <peter.peshev@sap .com> To "Mike Edwards" 11/29/2007 07:45 <mike_edwards@uk.ibm.com>, "OASIS AM Assembly" <sca-assembly@lists.oasis-open.org> cc Subject RE: [sca-assembly] [NEW ISSUE] Wiring from a reference with no binding to a service with a binding Hi Mike, Let me clarify the idea (sorry if I didn't do it well before), binding.sca is always present, however it just doesn't implement the intent SOAP (or JMS in the earlier use case) So in case the assembler \ deployer has not put any bindings and there is SOAP intent, than the tooling \ deploy error will say -- "Hey the default binding.sca is not good, you need to put binding.ws". When the assembler fixes this, there will be both binding.ws & binding.sca on both end of the wires , than the runtime according to the current wiring algorithm will choose only binding.ws as being the only binding satisfying the intents. The downside of such proposal is that in case there is some specific intent -- SOAP, JMS, etc. the assembler \ deployer will need to put binding.ws on both ends of the wire, but I think that's not that frequent usecase. The benefit is that by having binding.sca by default we can simplify the most common use case - quote - " where the component is top-level (ie in the domain) and where some aspect of "external access" is required. The assembler wants to expose to the outisde world the web service, however for any internal inter-domain wiring, the optimised binding.sca can be used. I.e. if the vendor binding.sca can detect that let's say two components are living on one and the same server, than it can just make a local call between them as long as all policies are kept, there is no need to post HTTP requests or to do any JMS messaging. Best Regards Peter ________________________________ From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] Sent: Thursday, 29. November 2007 13:28 To: OASIS Assembly Subject: RE: [sca-assembly] [NEW ISSUE] Wiring from a reference with no binding to a service with a binding Peter, <copying the list too - everyone needs to see this discussion> The most common case where a binding will have been applied to a component service (or reference) is where the component is top-level (ie in the domain) and where some aspect of "external access" is required. It will not be uncommon for another component in the domain to also want to access the service and it is much simpler to use binding.sca to make the connection. (ie just set @target="ComponentName/ServiceName"). The problem with the idea of "binding.sca is always present" is exactly the one that you've outlined. There are some cases where the requiements of the component implementation may force the use of one binding - or of a subset of bindings. A good example of where web service binding would be needed is an implementation that uses the JAX-WS extended APIs for accessing SOAP headers. SCA does not outlaw this, but it does restrict the binding types that can be used. If you go down this road, let us assume that the requirement for a particular binding is indicated by some intent - say @requires="SOAP". Your suggestion is that if such an intent is specified, then binding.sca is removed at that point and binding.ws is required to be specified. So this implies that "binding.sca is always present except when it isn't", which I don't find very satisfactory. There has been another criticism of the my idea of "coercing" binding.sca to a specific binding type when the other end of a wire requires it. This is in the case where a service is declared as binding.sca and the reference using it specifies some specific binding like JMS or Web services. The argument in this case is that "coercion" of the service's binding.sca to binding..jms for one client reference and then coercion of the same service to support binding.ws for another client reference leads to multiple endpoints being created for the service. This is valid, in the sense that this would indeed imply multiple endpoints, but I've always bought off on the idea of binding.sca handling multiple endpoints for a service offered via binding.sca - for example, if there are local clients of the service, I'm quite happy for those local clients to use direct calls to the target service, rather than going via some remoting endpoint. So let's make my model clear: - binding.sca is only present on a service or a reference if: a) it is explicitly specified b) no binding is specified at all (ie then it is the default binding) - binding.sca is regarded as compatible for wiring purposes with any other binding type, and the actual binding used is the binding type on the other end of the wire. If both ends of the wire are binding.sca then the runtime is free to choose the actual binding to use. binding.sca will be declared as supporting a particular set of intents if a reference or service uses intents not supported by binding.sca then it is an error if binding.sca is used for that service/reference 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> 28/11/2007 13:28 To Mike Edwards/UK/IBM@IBMGB cc Subject RE: [sca-assembly] [NEW ISSUE] Wiring from a reference with no binding to a service with a binding Hi Mike, Your mail leads to a very good way to allow always binding.sca without any side effects. In case a particular binding is mandated by having JMS intent, than the binding.sca will simply not implement that specific intent, and the tooling \ deployment will say : "Hey, that's not valid wiring, you have JMS intent, you should put explicitly binding.jms on both ends of the wire) I am lacking your expertise and business vision, but I assume such "hardcoded JMS" should be rare, so the nuisance for declaring binding.jms on both end of the wires is not that big problem. Btw, I think at the moment that implementation.java offers no way for a developer to gain access to the underlying binding specific objects ( JMS connection, JMS session, etc.) , so such use case (I would break without JMS) is more theoretical. In addition I would imagine that an assembler would put a binding mainly to expose something to the outside world and configure the exposure, and as long as all policies are specified it's ok to have binding.sca to be present by default for inter-domain usage. What do you think ? Best Regards Peter ________________________________ From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] Sent: Wednesday, 28. November 2007 13:17 To: Peshev, Peter Subject: RE: [sca-assembly] [NEW ISSUE] Wiring from a reference with no binding to a service with a binding Peter, Thank you for pointing this out. I agree that these issues are closely related. I suggest that we should consider a single proposal to deal with both issues. The question of whether "binding.sca is always present" is not quite the same as "binding.sca is always compatible with any other binding type when matching the two ends of a wire". My distinction was mentioned in my previous note earlier this morning - the use of a particular binding may be mandated (eg through intents) since the component involved uses specific APIs that can only deal with that binding (eg envisage existing code that uses the JMS APIs). In that case, the only binding that can be used for the wire is really the specified binding. My thinking is that binding.sca on one end of the wire is regarded as compatible with the mandated binding on the other end of the wire - and that the mandated binding is what gets used. This is a bit different from the concept that binding.sca is always present on both ends of the wire. In that case, it would be possible for the SCA runtime to use a binding other than the mandated one - and this would be an error. I think it is likely to be more consistent to say that the binding.sca can be matched with (any) other binding type when doing wire compatibility. However, I realize that the distinction between the two cases is pretty small. 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> 28/11/2007 10:30 To Mike Edwards/UK/IBM@IBMGB, "OASIS Assembly" <sca-assembly@lists.oasis-open.org> cc Subject RE: [sca-assembly] [NEW ISSUE] Wiring from a reference with no binding to a service with a binding Hi, when looking at the description, it seems that this is closely connected (maybe even classified as duplicate) to the already raised ASSEMBLY-1 (?http://www.osoa.org/jira/browse/ASSEMBLY-1 <http://www.osoa.org/jira/browse/ASSEMBLY-1> ), which has the following description : It is not clear whether presence of binding.sca can always be assumed for internal wires, specifically when standard bindings are associated with either end of that internal wire Although the suggested proposal in ASSEMBLY-1 (adding binding.sca implicitly to each service/reference and thus satisfying the wiring algorithm requirements for the case "reference with no binding to a service with a binding") seems to be different than the currently suggested proposal (changing the algorithm). Best Regards Peter ________________________________ From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] Sent: Tuesday, 27. November 2007 17:43 To: OASIS Assembly Subject: [sca-assembly] [NEW ISSUE] Wiring from a reference with no binding to a service with a binding <This issue is transferred from the SCA Policy TC where it was dubbed POLICY-34> RAISER Michael Rowley (original) TARGET: SCA Assembly Specification DESCRIPTION: The algorithm in the policy spec says that it is _not_ possible to wire from a reference that does not declare a binding (i.e. uses binding.sca) to a service that declares one or more bindings. However, I think this should be possible. It is an unreasonable requirement to say that a service with a binding can only be the target of a reference that has that same binding. The default binding (binding.sca) should be treated as the "I don't care" binding, and should work with any binding available within the domain. Or, more precisely, any binding that can satisfy the required intents. Section 4.8.1 of the Policy frmework spec states: The wiring compatibility algorithm below determines the compatibility of a wire by a pairwise choice of a binding instance and the corresponding policySets on each side of the wire. This should be changed to the following: If either side of a wire does not specify a binding (or explicitly specifies binding.sca) the wire is considered to be valid for the purposes of policy processing. If both sides of the wire use binding.sca then the policies will be determined by the union of the required intents of both sides (policy sets aren't used with binding.sca). Otherwise, the bindings and policies used for the wire will be determined by adding the intents that are required by the binding.sca end of the wire to the other end of the wire and then following the section 4.10 algorithm in the Polcy Framework. If neither side of the wire uses binding.sca, then the wiring compatibilty algorithm below is used for determining compatibility. Note that there may be many binding instances present at each side of the wire. This algorithm determines the compatibility of a wire by a pairwise choice of a binding instance and the corresponding policySets on each side of the wire. PROPOSAL: The following should be added to the Wires section of the Assembly specification: If either end of a wire does not specify a binding (or explicitly specifies binding.sca) the wire is regarded as valid. In other words, binding.sca is regarded as being compatible with any other type of binding. Where other types of binding are applied to each end of a wire, compatibility of the two bindings is determined by the specifications for the two bindings involved, allied to the intent and policies attached at each end. In general, a wire which has two different binding types at each end (non binding.sca) is likely not to be valid. If both ends of the wire use binding.sca then the policies will be determined by the union of the required intents of both ends (policy sets aren't used with binding.sca). Otherwise, where one end of the wire uses binding.sca, the bindings and policies used for the wire will be determined by adding the intents that are required by the binding.sca end of the wire to the other end of the wire and then following the algorithm defined in the Policy Framework specification section 4.10. If neither end of the wire uses binding.sca, then the wiring compatibilty algorithm described in section 4.10 of the Policy Framework specification is used for determining compatibility. Note that there may be many binding instances present at each side of the wire. This algorithm determines the compatibility of a wire by a pairwise choice of a binding instance and the corresponding policySets on each side of the wire. 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 ________________________________ 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 ________________________________ 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 --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]