##CONTINUE##
I am writing this BLOG to worn developers about another huge ambiguity coming this time with SCA. It is not a specification for implementation of service-oriented architecture but rather a good specification of component-oriented architecture with Java or WSDL interfaces, i.e. it is Interface-utilising Component Architecture. SCA is about components, not about services. The magic word 'service' is, probably, borrowed form Web Service, which itself is not necessary about Web and definitely not about service but presents a service interface of special type. As we know, SOA is not equal to Web Service though the latter may be used for SOA implementation (among others like RMI, Jini, CORBA, DCOM, etc.).
So, let us leave SOA and services aside and look at the Assembly Model Specification: Extensions for Event Processing and Pub/Sub specification because it is released recently. First, that I am interested in, is to find out how the specification extends Event Processing in the component-oriented implementation. Believe it or not but the specification defines
"• event - a message sent to zero or more parties that contains information about a situation that has occurredThat is, according to SCA, we can send events, receive events and even filter events. Is this the Extension? Am I reading a SW specification or extracts from Matrix? The Event Processing is associated with event-driven architecture (EDA), for me, at least. I looked into several basic resources about EDA and the only one that mentioned word 'message' was Wikipedia, which said "The first category of sinks can be based upon traditional components such as message oriented middleware". I think that mixing events with messages is very inaccurate and dangerous terminology: some people can take it literally and start 'sending' events... It is odd that the authors of SCA Specification were able to agree on such complex matter as SCA being working for four different global organisations with unique cultures but were not able to avoid a 'bird' language in the standard.
• producer - entity that creates events
• consumer - entity that receives events"
Unfortunately, event/message mess is not anole. According to the SCA Specification "In SCA event processing, component implementations may have zero or more producers and zero or more consumers". If 'zero' producers and 'zero' consumers happen, what may be the state of such component - coma?
Also, the explanation of 'Promotion' such as
"1059 Composite services involve the promotion of one service of one of the components within the
1060 composite, which means that the composite service is actually provided by one of the
1061 components within the composite. Composite references involve the promotion of one or more
1062 references of one or more components. Multiple component references can be promoted to the
1063 same composite reference, as long as all the component references are compatible with one
1064 another" is not very comprehensive, at least, to me. One more example: "When CompositeX is used as an implementation by a higher-level component, the consumer and producer elements..." does not define what "a higher-level component" is and what the other levels are.
The more serious concerns relate to the SCA component implementation abilities. In particular, statement "An implementation can provide services and it can make references to services provided elsewhere" looks OK at a glance but where this 'elsewhere' is? Is it in the same implementation or in another one? If it is another implementation, don't we have a risk that the implementation can operate under different authority and a direct reference to it is known as a not really good practice (remember directory services in JEE and CORBA)?
Another implementation ability, which totally deviates SCA from SOA, is an aspect of configuration. The SCA Specification declares that the component defines service (even if it is just a service interface) and reference (to another potential service) via component configuration. In SOA, service is the first class 'citizen', component is not, while in SCA the SCA component is the first class 'citizen'.
Besides, I've found additional argument that separates SCA from SOA; it is the aspect of 'reference' of the SCA component. The 'reference' is a real reference to another component, i.e. to its interface. Since reference '...may define the interface, binding(s), target URI(s), intents, policy sets, including details of the bindings', it is the point of full coupling between components. That is, we can forget the principles of service orientation here. An SOA service differs from a component (SCA component in this case) by that the SOA service operates based on the principles of service orientation while the component does not have such constraints.
Finally SCA presents quite interesting concept of 'intent'. It is defined as 'an abstract assertion about a specific Quality of Service (QoS) characteristic that is expressed independently of any particular implementation technology. An intent is thus used to describe the desired runtime characteristics of an SCA construct.' Intent is very "delicate" and important concept and I am glad that SCA expresses it via policies. However, in many places in the SCA Specification, the intents and policies are listed next to each other giving an impression that they are quite different things. It is confusing, especially when intents are mentioned as service-interface elements and policies are mentioned as reference elements; moreover, the intents may be defined by the policy administrators. What intents an interface may have if they are not a set of policies exposed to the user of this interface? Whose policies a reference can specify, its own ones (what for?) or the ones that belong to another service-interface (why they have to be specified in two places?) ?
Reading the SCA Assembly Model Specification: Extensions for Event Processing and Pub/Sub, I could not rid of a feeling that it was written in a hurry to get to the code part as fast as possible. The code is good but it is a hazardous motion in the standard when the entities that described in code are defined with a negligence; it opens a door to all things that can screw any good intentions of the authors, I am afraid.-----------------------------
BY Michael Poulin
Source：ebizQ
Copyright © ebizQ. All rights reserved.
Posts
0 comments:
Post a Comment