Business Ecology Initiative & Service-Oriented Solution

I have wrote about SCA once before when it was in the development phase. Now, I see IBM and Oracle promote this set of specifications to the consumer companies. I know that IBM is a big company and, unfortunately, it suffers from the known 'illness of size' - one hand does not know what another hand does. Particularly, we have exceptionally progressive work performed by Marc Fiammante AT AL that treats service orientation as the business-to-technology means and, simultaneously, we have a work conducted by Barry Ruzek and Dr. Bob Pratt who used SCA as the core technical "SOA" solution for their project.

I've put SOA in quotes because SCA may be a second cousin to SOA in the best case. Why? Because SCA does not define Service based on SO Principles. If you think I am bluffing, read the spec yourself :

"34 A Java implementation type may specify the services it provides explicitly through the use of @Service. In
35 certain cases as defined below, the use of @Service is not required and the services a Java implementation
36 type offers may be inferred from the implementation class itself.
37
38 1.2.1.1. Use of @Service
39 Service interfaces may be specified as a Java interface. A Java class, which is a component implementation,
40 may offer a service by implementing a Java interface specifying the service contract. As a Java class may
41 implement multiple interfaces, some of which may not define SCA services, the @Service annotation can be
42 used to indicate the services provided by the implementation and their corresponding Java interface
43 definitions."

So, according to the SCA Java Component Implementation V1.00 specification, service is a Java class or inherited from a Java class (as what?). Moreover, Java class, to become a service, needs only to get association with a Java interface that someone considers a service contract. It seems that SCA has been written in total isolation, inside the Java 'church', with no idea about surrounding world and SOA standards (from the same OASIS). For years, SOA experts say and write that an interface - SCA interface or Web Service - cannot change the nature of the SW entity, i.e. cannot make it a service. If a Java class does not behave as a service, it is not a service. Period.

The use of annotation is fine and we can name the annotations 'Service' or 'Truly Service' - this does not make the code a service. A very old Mid-Asia saying teaches: "Does not matter how many times you say 'raisin', there will be no sweet in your mouth" (Pardon my clumsy translation).

Following quote is even more classy in this context:

"143 1.2.1.3. Introspecting services offered by a Java implementation
144 In the cases described below, the services offered by a Java implementation class may be determined
145 through introspection, eliding the need to specify them using @Service. The following algorithm is used to
146 determine how services are introspected from an implementation class:
147 If the interfaces of the SCA services are not specified with the @Service annotation on the implementation
148 class, it is assumed that all implemented interfaces that have been annotated as @Remotable are the
149 service interfaces provided by the component. If none of the implemented interfaces is remotable, then by
150 default the implementation offers a single service whose type is the implementation class."

This means: it does not matter what you have or do - any Java class is a service. It is not all yet - introspection can give us the names of the methods, attributes and returned types in the Java class and we have to believe that the names mean to us the same as to those who developed the Java class and that the methods provide business functionality depicted in their names... What justifies this enormous level of trust to unknown developer and alien code that claims to be a service to me? Well, philosophically, everyone serves everyone but practically an interpretation of any Java class as a service, i.e. a fundamental part of service-oriented ecosystem, is reckless. Furthermore, it is unacceptable because such interpretation, IMO, carries an ambiguity and tremendous risk of failure in 'serviceability '.

To explain my position, let me point to several SO Principle that, I believe, are violated in the SCA's treatment of the notion of service (see the link below).

View image

If this list of violations still has not convinced you in that SCA fakes SOA services, I would offer you a trivial example.

Based on only common knowledge, please, answer what do you think about (at the first moment) when one asks you to develop a service? In your place, I would think about three things: a) what the service should deliver; 2) for/to whom the service should deliver; 3) how many consumers the service should deliver to. Now, we take a Java class, which may be accompanied by an annotation @Service later on, and try to answer all three questions. The answers to questions 1) and 2) are simple: to 1) - the class behaviour/functionality, and to 2) - whatever other Java classes (or run-time objects) that would call out Java class' methods. However, the question 3) is not trivial. Those who designed our Java class may not necessary considered any invocation concurrency. It is not a fault of the Java class developer. This concurrency had surfaced only when we looked at the Java class as at the service (a service for a single user is a valid service but it is rather an exception than a typical form of the service).

An arbitrary Java class may be not thread protected and, itself, may be not capable of multithreading. Thus, if dealing with such "service" as a consumer, who is unaware about implementation "nuances", you can get into troubles. But you are not alone. The SW that provides this "service" can get into troubles itself - if this Java class is used by other classes within the surrounding SW, multiple 'requests for service' can block the access to related object and/or screw the data values modified concurrently.

How can this happen? Easily - one person writes code, another person (later) annotates the code as a service, and the third person announces this "service". Who suffers from this "SOA" implementation? Correct, it is the service consumer.

SCA, as it is defined today, neglects fundamental things about SOA Services for the sake of development convenience; it ignores the nature of a service as a function and places it as an object (well, maybe I have missed a new Nobel Prize discovery like 'function=object'...). The only excuse I have for SCA is that it was written in 2007. Now is the time for the serious review and compliance with SOA standards.