[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-bindings] Recent SCA interest
Hi Jim,
Thanks for your reply. For the past month, we are working on our project and trying to find a better solution. It would be interesting to submit and share a informative
proposal about our solution to the work group if it was needed. Please check our comments inline.
Thanks, Michael From: Jim Marino [mailto:jim.marino@gmail.com]
Hi Michael, Sorry for taking so long to respond but your email was very thought provoking and I needed time to formulate my thoughts. I'm glad to see Huawei and China Shanghai
Jiao Tong University have found SCA useful. It sounds as if you are conducting very useful work! [Michael] Thanks very much for sharing the valuable thoughts and
inspiring advices given in the last email. Your opinions are very helpful to our work. Our project will last for near two years to make SCA work in
special industry like Unified Communication (UC). If I follow your requirements correctly, your use case involves autowiring based on selectors other than interface contract (I understand autowiring to be the
SCA analog of your term "auto-binded"). This is similar to use cases I have encountered where a service needs to be selected based on additional criteria other than name and contract. For example, a client requires the "Gold Member" version of a particular
service. [Michael] As to the requirement we mentioned, the key _expression_ “autowiring based on selectors
other than interface contract” is a much better summary of our idea. As SCA are aiming at a programming model that reduces complexity while at the same time providing for modularity through composition, the reusing of modules (or components) is the key point
of SCA. Other dependency injection-based programming models such as CDI, Spring and Guice provide this feature in the form of qualifiers. I'm not sure if many people realize but SCA autowiring does allow for a similar capability. However, I have ran into a few limitations with it. The SCA Assembly
Specification includes in the autowire selection algorithm the requirement to match on policy. For example, if a client requires a transactional service, the "requires transaction" attribute can be used to select an appropriate service from two with matching
interfaces. This could theoretically be expanded to encompass other attributes such as "Gold Member". [Michael] To satisfy the demand of component selecting, runtime selection is one important part in SCA since the goal is to composite the components.
Autowiring is a mechanism now for service selections which is important to select service for additional information other than just interface contract, although it may still surfer from some problems. And that is a reason for using policy. The policy mechanism
certainly provides some approach to handle the additional criteria. This can satisfy the need of special requirement in service behavior or service level.
I have ran into a few problems with this which leads me to believe using policy in this way (or abusing it) may not be the best solution and what we need instead
is a proper conceptual model: 1. While the qualifiers should be added to the interface, there needs to be a way to specify them from the implementation. In Java, an implementation specifies
its service contract by implementing an interface (there are exceptions to this but we don't need to go into them here) and potentially using the @Service annotation. As it stands today, there is no mechanism in SCA for also specifying additional qualifiers
*to the interface* from an implementations. Conceptually, this can be thought of as an extension of Java "implements". 2. If policy is used as the qualifier, there may be a problem with a runtime trying to satisfy it. For example, if I specify "Gold Member" on reference that
I configure with a binding, an SCA runtime will likely try and resolve it against the binding type. This would require each binding to have a declaration that it satisfies the "Gold Member" policy. This is not feasible since the types of policies cannot be
known in advance by a runtime. There may be a creative way around this, but the point is use policy in this sense is cumbersome. [Michael] As in this issue, criteria and requirement are talked about in the condition where the interfaces are compatible to each other but not
informative enough for runtime selections. So in that case, interfaces can match with each other and several distinguish implementations exist for one interface.
[Michael] Through policy is an option here, it is sometimes unskillful, and “types of policies cannot be known in advance by a runtime” is a critical
point in cases as the “Gold Member” example. So the “adding qualifiers” and “support query languages” could potentially be rather powerful. This share the same thought with other injection-based programming models, and it is very similar to our first thought
to reduce the complexity. If it is possible, would you like to show more details about the “Gold Member”?
I think we should look into the notion of adding "qualifiers" as a first-class citizen to the SCA Assembly model. These could potentially be very powerful: 1. They can be used to distinguish wiring in addition to interface contracts. 2. Autowire could be extended to support query languages for selecting interfaces. For example SPARQL or OData could be used as a way to specify conditions for
autowiring (I think this is where you may be referring to semantic web concepts). 3. Adding qualifiers would make integrating SCA with CDI, Spring and Guice easier and better 4. It would be easy to create the capability to add default wiring in a component implementation. For example, a component implementation could specify a query
on a reference that would be the name of a component to wire to (traditional wire-by-name in this respect is just a degenerate case of autowire): @Reference (query="name='foo'") MyService service [Michael] Although despite of that, we have another issue based on our experience for now. What we are facing here is that the difference between
systems (basically, different vendors, different mid-wares, and some legacy systems) may introduce more complexity in service composition. Since in UC area, the reuse (most times *modify then reuse*) is quite a common thing in service open layer, the reducing
of this kind of complexity is quite necessary. So based on our view of using SCA, we think a developing-time (or configuring-time) matching might be sometimes effective for developers. [Michael] Our original thoughts contains another case, the interfaces are *not exactly compatible* due to some of them were not design to work
together in the first place. For instance, the services with those interfaces cannot interact with each other directly without some modification like data type adaption, chain invocation, etc. So in this case, the interfaces are lack of information for more
automatic composition. [Michael] So what we are hoping is to work out a solution of *more intelligent composition*. With the runtime selection part as above, the wiring
of SCA can be more powerful, and hopefully with a more automatic service selection, the SCA framework may provide some automatic interface matching feature (that is, in our first trial, by generating some glue-code base on OWL reasoning).
Regarding your other point about capturing information from legacy systems, there is an interesting extensibility point in SCA Assembly. Specifically, SCA Assembly
states that the XML *infoset* is normative, not simple the XML itself. SCA could be extended to support additional formats that can be mapped to the XML infoset/model. This would make it possible for software to "introspect" existing services that are already
deployed and produce an SCA representation that can be used to wire to legacy services. In my opinion, such a capability would be more practical than a centralized registry that must be manually synchronized. Finally, one other issue I think you touch on is inter-domain wiring. In other words, the ability to wire services that are deployed in two different domains.
SCA currently says nothing about this and it is one of the areas that I believe warrants future work as it limits interoperability. For example,wiring services deployed on two different SCA vendor runtimes (this cannot be done today using SCA "wiring"; it
can be done using bindings, however). This is also important for cloud computing since it would provide a way to assemble services deployed across multiple clouds. I believe such a capability can be achieved with very minimal complexity (a discovery URI and
infoset/model of services and bindings delivered over HTTP). [Michael] As to the issues of dealing with non-SCA systems and inter-domain wiring, there might be a misunderstanding because we didn’t express
clear enough. Anyway, the advices given are very useful. In both case, services or other kind of modules cannot be composite today directly using SCA "wiring", but it can be done using “binding”. [Michael] With the “legacy system”, our point is the difference of design style, naming style and some other factors of different operation signature
of similar function. The issue here is same as “different business domain” below. And about the non-SCA legacy system, we think produce an SCA representation is a really practical way to handle the situation. [Michael] And about the “inter-domain”, we are actually referring “different business domain”(for instance, person profile in an company organization
archive can be different with those in a common yellow page, but some information can be share when different data presenting style is well handled). As to the “domain” concept in SCA, it is a role that can be broken down into four functions: management,
artifact sharing, policy administration, and communications. SCA has some limits in interoperability might be just a conceptual idea of boundary between domains, and most of them can be achieved with very minimal complexity as reasoned. I am not sure if I answered your questions but hopefully the topics outlined above touch on the work you are interested in. I would be happy to pursue these
further using Fabric3. In addition, I think they merit discussion and exploration in the SCA Assembly TC. If they interest Huawei and China Shanghai Jiao Tong University let's work together to get them brought up for discussion in the TCs. [Michael] Thanks again for taking patient for answering our questions and sharing the valuable ideas, they are very helpful to us. We are really
hoping that our work can work out well and became useful in SCA. Jim On Wed, Jul 31, 2013 at 3:03 AM, Yanqiang (Michael) <michael.yan@huawei.com> wrote: Hi All, > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]