SCA of SOA standards

SCA (Service Component arichitecture)

effect : the separation of business components and transport protocols enables the integration of various platform components to be handled.

content: The specific implementation of SCA is the SCA Standard and SCA's container environment.

SCA containers enable the integration of complex service components within a container, and developers need to develop and integrate services in accordance with SCA standards, and eventually deploy them into SCA containers. The implementation of the SCA container is complex, and the composition and architecture of its container is also a trade secret.

Sca

SCA Service Components--service modules--service subsystem-->example1-helloworld-->example2-calling different technology components

1.1 Service Components

The service component is the basic constituent element and the basic building unit of SCA, where we implement the business logic concretely. We can think of it as building blocks for our application.

As shown above, each part of the service composition is described separately:

A), services (service), used to make calls to other components. is an interface. If it is Java-based SCA, it is the interface of Java, it can also be the Prottype interface of WSDL, there are only these two forms.

b), component implementation (implementation), the implementation of the service created, for Java, is the interface implementation class.

c), reference (Reference), a component may need to call other components and need to create a reference to the Igeqita component. For Java, it is the Java interface for other components.

d), property, an attribute parameter injection to the component implementation.

The portal that the serviced component provides to other service calls is called Interface (interface). The service component itself may also need to invoke other services, the call exit called Reference (Reference). The invocation specification is either a WSDL or a Java interface, whether it is an interface or a reference.

1.2 Service Modules

The SCA module is actually a more integrated set of SCA components (as parts), and the structure of SCA modules and SCA components is consistent from the overall perspective. From the part angle that makes up the component, the SCA module is reassembled as a new component (module) as a component.

In fact, the truth is very simple, the following is the basic principle of SCA Module diagram:

The module is also a component in its entirety. Modules are assembled through the SCA configuration file configuration and do not require the hard coding of the program.

Elevation (Promote): The interface, attribute, or reference of a component is assembled into the corresponding interface, property, or reference of a module.

Wire: Is the call relationship between components within the module. For example, the implementation of component A calls component B, so there is a connection between component AB.

When calls are needed between components, because of the diversification of current components (such as EJB, WS, JMS) transport protocols, it is necessary to bind different protocols to each other when called. These binding information includes the invocation method of the target service or the source service, location information, methods of invocation, and so on.

The service component in the module is not directly used by external Java code, for external Java code, such as Jsp/servlet using the service component in the module, the WID tool provides a special endpoint in the module called standalone Reference. This endpoint is only referenced (Reference), and there is no interface (Interface). As long as the reference to this endpoint is connected to the interface of the serviced component that needs to be invoked, the external Java code invokes the corresponding service component by the name of the reference.

1.3 Service Subsystem

In a large project, there may be a lot of service modules, multiple service modules if you need to call each other, then you can be a number of service modules through WS or JMS and other technologies to bind together to form a service subsystem.

1.4 Example-sca Implementation of the Hello World component instance

The Complete SCA component Hello World instance contains two parts:

1. Service-side code for SCA components

The server-side code consists of three parts:

Service interface, a Java interface----Helloservice.java.

Service implementation, the implementation class of the HelloService interface----Helloserviceimpl.java.

SCA's service component configuration file: Hello.composite.

Helloservice.java

/**
* Service Interface
*
* @author leizhimin 2009-6-2 15:31:49
*/
Publicinterface HelloService {
String Gethello (stringusername);
}

Helloserviceimpl.java

Package Hello;

/**
* Service Implementation
*
* @author leizhimin 2009-6-2 15:32:36
*/
Publicclass Helloserviceimpl implements HelloService {
public string Gethello (string username) {
Return "Hello" + Username + "! This is ASCA program! ";
}
}

Hello.composite

<!--SCA Service component configuration file--
<compositexmlns= "http://www.osoa.org/xmlns/sca/1.0" name= "Hello" >
<componentname= "Helloservicecomponent" >
<implementation.javaclass= "Hello. Helloserviceimpl "/>
<propertyname= "username" type= "xsd:string" default= "World"/>
</component>
</composite>

2. Client code for SCA components

Package Hello;

/**
* SCA client-side invocation
*
* @author leizhimin 2009-6-2 15:41:41
*/
Publicclass Helloscaclient {
Publicstaticvoid Main (string[] args) {
Scadomainscadomain = Scadomain.newinstance ("Hello.composite");
Helloservicehelloservice =
Scadomain.getservice (Helloservice.class, "helloservicecomponent");
Stringmsg = Helloservice.gethello ("vcom");
SYSTEM.OUT.PRINTLN (msg);
Scadomain.close ();
}
}

From the client's calling code, the client needs to know what service the service-side component provides and what pure Java interfaces are implemented. The implementation details behind the interface are not required.

As you can see from the development process above, there is no need to know the technical details of developing SCA components, both client and server.

When the client calls other components, it can be called only through a simple scadomain instance, and the responsible invocation and implementation are given to the SCA runtime environment.

1.5 example-calling different technical service components

This sample demonstrates the evolution of a simple business application. Although the example SCA application is conceptually simple, its implementation is quite complex. The calculator application involves 4 different services. Each service is implemented or accessed through different technologies (Java technology, Web Services, HTTP, JScript, and Groovy).

The only requirement for this business service is to add two numbers. Publish the calculator service for the client to invoke. This computer is connected to an add service with only one feature: Add two numbers and return the sum (for example
Double Add (double O1, Double O2)). Assume that the interface is specified in the Java language, and that the service is implemented in the Java language. Figure 3 shows this SCA collection. Figure 3: The SCA Calculator component that calculates the addition

After specifying the calculator component and its implementation, this component will reference the Add Service component and its implementation. Listing 1 shows the SCA composite file for this business application. You can download the source code for this component and other components. Listing 1. Calculator Compound file

<composite xmlns= "http://www.osoa.org/xmlns/sca/1.0" 
   xmlns:sample= "Http://sample" name= "Calculator" 
   >

   <component name= "calculatorservicecomponent" >
      <implementation.java class= "calculator. Calculatorserviceimpl "/>     
      <reference name=" AddService "target=" addservicecomponent "/>
   </ component>
  
   <component name= "addservicecomponent" >
      <implementation.java class= "calculator. Addserviceimpl "/>
   </component>
</composite>

The

assumes that the customer needs are growing and requires a new service that calculates the subtraction. However, there is a WEB service that can designate an interface as a WSDL document and be implemented as a Java program. This Web service can be accessed through a Web service access binding. Therefore, by adding a component that references and accesses the subtraction service, you can easily add new requirements to the SCA composite file. Listing 2. Calculator compound file containing the new service

<composite xmlns= "http://www.osoa.org/xmlns/sca/1.0" xmlns:sample= "Http://sample" name= "Calculator" > &lt ; component Name= "calculatorservicecomponent" > <implementation.java class= "Calculator. Calculatorserviceimpl "/> <reference name=" AddService "target=" addservicecomponent "/> <referen Ce name= "subtractservice" target= "subtractservicecomponent"/> </component> <component name= "Addservic Ecomponent "> <implementation.java class=" Calculator. Addserviceimpl "/> </component> <component name=" Subtractservicecomponent "> <implementati On.java class= "Calculator. Subtractserviceimpl "/> <service name=" Subtractservice "> <interface.wsdl interface=" http://calcul Ator#wsdl.interface (subtractservice) "/> <binding.ws uri=" Http://localhost:8080/SubtractServiceComponent "/&
      Gt </service> </component> </composite>

To realize the evolution of the business example, we need to add the need for multiplication and division services. These services can be obtained in the form of JScript and Groovy implementations. Tuscany allows you to easily add these services to a composite file. The application representation should now be shown in Figure 4. Figure 4: An SCA calculator with 4 services

In the final SCA composite file for the application, note that the JScript and Groovy components that are added are Tuscany-specific extensions to the SCA specification. Therefore, a new namespace attribute introduces Tuscany-specific syntax for these components. Listing 3: Calculator compound file with 4 services

<composite xmlns= "http://www.osoa.org/xmlns/sca/1.0" xmlns:sample= "Http://sample" xmlns:tuscany= "Http://tuscan y.apache.org/xmlns/sca/1.0 "name=" Calculator "> <component name=" calculatorservicecomponent "> <impl Ementation.java class= "Calculator. Calculatorserviceimpl "/> <reference name=" AddService "target=" addservicecomponent "/> <referenc E name= "Subtractservice" target= "subtractservicecomponent"/> <reference name= "Multiplyservice" target= " Multiplyservicecomponent "/> <reference name=" Divideservice "target=" divideservicecomponent "/> </compo nent> <component name= "addservicecomponent" > <implementation.java class= "Calculator. Addserviceimpl "/> </component> <component name=" Subtractservicecomponent "> &LT;IMPLEMENTATION.J Ava class= "calculator. Subtractserviceimpl "/> <service name=" Subtractservice "> <interface.wsdl interface=" http://cAlculator#wsdl.interface (subtractservice) "/> <binding.ws uri=" http://localhost:8080/ Subtractservicecomponent "/> </service> </component> <component name=" Multiplyserviceco

  Mponent "> <tuscany:implementation.script script=" calculator/multiplyserviceimpl.js "/> </component> <component name= "Divideservicecomponent" > <tuscany:implementation.script script= "Calculator/DivideServic Eimpl.groovy "/> </component> </composite>

This scenario allows you to make two quick changes and add three components to the initial business application. The new components will be implemented and accessed using different technologies based on the initial components. SCA can respond to changing and different kinds of business needs.

To run an SCA business application, the SCA runtime (such as Tuscany) first needs to load and configure the SCA compound file. Each compound file artifact is checked, and then the different objects are instantiated in memory using the factory method. The second step is to instantiate the run-time connection used to connect the component (Runtime wire)

Reference:

http://www.ibm.com/developerworks/cn/webservices/ws-sca/#ibm-pcon

Http://www.ibm.com/developerworks/cn/opensource/os-apache-tuscany-sca/index.html