OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [sca-bindings] Recent SCA interest

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!

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.

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".

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. 

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   
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).

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.


On Wed, Jul 31, 2013 at 3:03 AM, Yanqiang (Michael) <michael.yan@huawei.com> wrote:
Hi All,

My teammates and I are working in a research project for SCA implement on enterprise unified communication (UC) products, especially for its service open layer. I am from Huawei, and most of my teammates (Prof. and Ph.D.) are from China Shanghai Jiao Tong University http://www.sjtu.edu.cn/. In the developing of various open business gateways, it is necessary to provide a frameworks which maintain programming language and application environment neutrality  for a high degree of programmer productivity. And SCA-based framework is a suitable choice for us, when facing the wide range of disparate technologies and a pile of complex business logics in UC service open layer.

We *think* SCA could help to work with our products that concern a large amount of legacy services from various service providers. Obviously the SCA (as a model for composing applications that follow Service-Oriented Architecture principles) has solutions for the following concerns:
1. Decoupling of application business logic from the details of its invoked service calls 2. Deal with services in a multitude of languages 3. Work with various communications constructs including "One-Way", "Asynchronous", "Call-Return", and "Notification"
4. The ability to "bind" to legacy components or services, accessed normally by technologies such as Web Services, EJB, JMS, JCA, RMI, RPC, CORBA and others 5. The ability to declare (outside of business logic) the quality of service requirements, such as security, transactions and the use of reliable messaging

However, we *notice* developers still need to take much time to organize and invoke services from various service providers, when facing the legacy services in UC field, even through SCA reduces the complexity and removes the business logic programmer concerns above . As the target services are provided by different providers with various backgrounds (including different understanding of the domain concern, different naming style, different dependency on other services, etc), much more efforts are needed to deal with the service incorporate. Here are several typical cases:

1. Different *naming styles* in different legacy services. As target services are provided by several groups, the same conception might have different name or structure in different services. Thus some services might look different while they perform the same behavior. Take sendMessage() as example. The operation we need to use might be like #1 case. However, due to different concern (to distinguish Email address with actual post address), the provided operation might be like #2 case.
        1) SendMail (MailAddress from, MailAddress to, Message contant)
        2) SendMail (EMailAddress from, EMailAddress to, Message contant) As we can see, both interfaces are actually the same meaning, except that they don’t have unified naming. In a complex business environment as in UC filed, this kind of situation happens a lot. Thus lots of work have to do to handle this kind of problem.

2. Different *behavior* in different legacy services. As the target services might be defined to face different situation, some services might look the same, while they are actually not. Here is another example: In persistence level, an operation "deletePerson (Person person) " is used to delete some data in database. But in higher level, say in conference control mid-ware, an operation with the same exists, except that this "deletePerson" is used to remove a person from the conference attend list. These two interface are exactly the same in the sight of interface matching. So the programmer need understand all the services from different providers in order to distinguish them correctly.

In another word, the programmers takes a lot of time to handle different understanding between various sources of services when declaring SCA compositions. So we noticed that interface-based service composition might not perform very well in some situation, due to lack of information of services.

We *try* to use semantic model (which is widely used in semantic web area) to add additional information in SCA composition, so that the target service declared in assembly model can be *auto-binded* according to service behavior information rather than just interface matching. In our implement, extra semantic information added in SCA Assembly Model to provide more information for service auto-binding. Based on current SCA model, more elements are added in "Service" and "Reference" part despite of "Interface" element. Here, an element "SemanticReference" could be added to describe the semantic model references as a sub-element of "service" and "reference". This new element contains a mapping information of involving data and behavior with OWL ontology classes, so that the implement of the spec. can recognize the same services with different names and different services by the same names.

Comments on the above are of course welcome and appreciated.


> From: sca-bindings@lists.oasis-open.org [mailto:sca-bindings@lists.oasis-open.org] On Behalf Of Wolfgang B?ck
> Sent: Thursday, July 18, 2013 12:35 AM
> To: sca-bindings@lists.oasis-open.org
> Subject: Re: [sca-bindings] Recent SCA interest
> Hi,
> Some questions have been raised about market interest in SCA. I would like to share our experiences.
> In the past several years, I have worked on a hugh government project that uses SCA for a highly-available tax processing system. The system also uses a very large Oracle RAC installation for data availability. The success of the project has been a direct result of capabilities provided by SCA. Without them, the project would have taken much longer and been a lot more complex, making it more likely to fail.
> Here are some of the SCA features that we have found invaluable:
> 1. Web Services and security policy. 
> The tax processing system connects to many legacy systems that are accessed using secure web services (WS-*). The SCA Web Services binding and capability to define security policy resulted in our application being able to connect to those systems without having to write complex Java code. We have tried JAX-WS and .NET for other applications and SCA was much easier and simpler to use. We also completed our tasks in record time.
> 2. Asynchronous services with callbacks.
> The legacy systems are often very slow and offline for maintenance (some are mainframe). We did not want to tie up application threads waiting for responses since this would not scale. As a solution, we used SCA asynchronous services with callbacks. This has made our application very performant and able to handle latencies efficiently. While .NET has a callback feature (duplex services), I am not aware of one provided by a Java standard without having to write custom application code. Without callbacks, would have had to develop a solution ourselves.
> 3. Modularity
> The application uses SCA composition (promotion) and OSGi integration for modularity. The module that connects to the legacy systems is an SCA composite that composes a number of services. After a year, we created another implementation of the composite that has different logic and connects to an ESB instead of the legacy systems. Modularity was so successful that we did not have to modify any other parts of the system when we made the switch. We are also able to switch implementations at deployment. Without composites, we would not have this modularity.
> 4. Wire re-injection
> Part of the application is a rules engine we implemented using SCA Java components. Rules are services that are wired to the engine. An important business requirement is that tax rules can be updated without taking the system down. We do this by relying on re-injection and deploying new composites with additional rules.
> 5. Custom bindings
> The tax system receives requests and publishes responses as files over a highly available geographically distributed SAN. We use SCA's feature to create a custom file binding to handle this. I am not aware of any other standard that specifies custom communications extensions. 
> Wolfgang
>> 2013/7/12 Eric Johnson <eric@tibco.com>
>> Hi Jeff,
>> On 7/12/13 1:11 PM, Jeff Mischkinsky wrote:
>> yeah, but if it doesn't CONFORM, i.e. meet ALL the conformance requirements as set out in the spec(s), then its not SCA, it's something that is maybe kind of like SCA --
>>   I haven't looked at this specific project to know how close it comes to conforming, just making a general comment about the confusion created when someone say they have implemented part of a spec, and somehow that means that there is now an implementation of that spec.
>> So? It doesn't conform? It doesn't conform to what - oh, that's right, its an as-yet-to-be-completed standard.
>> The implied question that Jim answered was whether there was any interest in the set of specifications, not the question you're answering. You've argued on the phone that the exit criteria specified were a minimum. OK, an allowable position. Jim is noting that more than the minimum has been achieved. And you continue to do try to disqualify his evidence by various means - in this case by trying to change the question. Color me not impressed.
>> note: i'm just not being pedantic here. If you carefully read the IPR policy, the IPR protections ONLY kick in for implementations of the complete spec(s), as defined by the conformance clauses. An IPR holder is not required to grant licenses/non-asserts to an implementation that does not conform.
>> As one possible way to change the situation, we could adjust specification and the conformance clauses, for example, making it possible to conform to assembly without requiring all of bindings, implementation types or policy, and therefore make it easier for more products to conform to the individual parts of the SCA suite. Unfortunately, the opportunities we've given for Oracle TC members to step forward and suggest alternate paths forward have yielded no options from Oracle participants.
>> Thus, I conclude that the actions of the TC members from Oracle all point in the direction of Oracle having made a business decision to keep SCA from ever becoming a standard. Based on statements made, Oracle has concluded the market has moved on. We could - instead - let the market decide.
>> As I've said before, I will be alerting my company that Oracle's behavior with the SCA standards has been nothing short of toxic, and will be advising that we stay away from any further standards involvement with Oracle, unless we feel that possible toxicity can be neutralized.
>> Eric.
>> --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to 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]