Implementation

From CoCoME

After requirement and design processes using rCOS, we build the implementation based on the Service Component Architecture (SCA) and its supporting platform Tuscany Java SCA.

SCA and Tuscany

We just give the definitions from SCA and Tuscany Websites to show what they are.

From http://www.osoa.org/display/Main/Service+Component+Architecture+Home:

• SCA is a set of specifications which describe a model for building applications and systems using a Service-Oriented Architecture (SOA). SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services.

From http://cwiki.apache.org/confluence/display/TUSCANY/Home

• SCA provides a language-independent way to compose and deploy service networks. SCA also defines language-specific programming models for service authoring including Java, Spring, C++ , and PHP.

From http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Subproject

• Tuscany Java SCA provides the infrastructure to develop and run SCA based applications. At the very high level, Java SCA can be divided into a core kernel and extensions. The kernel supports the SCA assembly model, Tuscany value-add features and simple extension point to add extensions. The kernel is designed to be embedded in, or provisioned to, a number of different host environments.

Why do we need it?

We think there are following reasons:

• Service Orientation is an important trend for software development. The main purpose of Service Oriented Computing (SOC) is to enable the interoperability between resources (such as program, data, etc.) on internet and make the maximum usage of them. From the perspective of software, service is a reusable component providing some special functions. So, after specifying requirements and designing system classes and components using rCOS, we attempt to find whether we can apply SOC concepts to enhance our approach.
• At the preliminary stage, we implement a standalone version of CoCoME, which is just for demonstration. From the requirements of CoCoME, we can see that it is a classical distributed system. In the given CoCoME implementation, RMI is used for communication between cashdesk and inventory, it try to simulate the real cases, in which the enterprise server and its store servers are hosted on different machines in different network environments, and the cashdesk applications are also located on different machines. We think it not very easy to build the real system based on the current version, such as enabling the interoperability, flexibility, maintainability, etc.
• CoCoME contest is for component technology. In our standalone version and even in the given CoCoME implementation, there is no explicit component programming entity. The component only appears during the modeling stage. Whether can we support the component-based system directly in the implementation?
• ...

Requirements (Enterprise System Architecture)

The supermarket enterprise system architecture is shown in the figure. There is an enterprise server that manages the enterprise's information, which include supermarkets, products sold in the supermarkets, exchanges, etc. Every supermarket has a store server which mange the local stockitems, orders, etc. Store server will communicate with enterprise service to update product information, request exchange, etc. The enterprise server will also communicate with store server to do some exchanges. There are many cashdesks in a supermarket. Each cashdesk will communicate with its store server to accomplish each selling process. The enterprise and each its supermarket have their own manage server, through which the administrator can mange enterprise or supermarket. Each manage server will communicate with its managed server to taken on management, and we omit these communicating parts in the figure. Otherwise, The supplier and bank are not included because of the simplicity.

How do we implement it?

We want to implement the system using Tuscany Java SCA. The enterprise server and store server will provide the services as the form of Web Services. The cashdesk will be a local Java application, the manage server will provide web application which can be used through explorer. After designing the system by rCOS, we can get the sale system components and their relations. For each different component, we can select the appropriate implementation language according to its function type.

• For each cashdesk, there are following components: SaleHandler, CashdeskUI, BushController, InputController. We omit BusController and InputController for the simplicity. For the SaleHandler, we decompose it into two components: Cashdesk and Sale. So, there are three atomic components in the cashdesk application. The component programming script is as follows. Because the components in cashdesk mainly handle the business logic, and will provide graphic user interface, we use Java to implement the components and build them based on our standalone version

<component name="CashDeskGUI">
 <implementation.java class="edu.unu.iist.rcos.cocome.cashdesk.gui.CashdeskGUIComponent" />
 <reference name="cashdeskService">CashdeskComponent</reference>
</component>
<property name="maxItem" type="xsd:int">10</property>
<component name="CashdeskComponent">
 <implementation.java	class="edu.unu.iist.rcos.cocome.cashdesk.CashdeskComponent" />
 <reference name="storeService">StoreService</reference>
 <reference name="bankService">BankService</reference>
 <reference name="saleService">SaleComponent</reference>
 <property name="max" source="$maxItem" />
</component>
<component name="SaleComponent">
 <implementation.java class="edu.unu.iist.rcos.cocome.sale.SaleComponent" />
 <reference name="bankService">BankService</reference>
</component>

• The store server and enterprise server mainly provided data management service. Their implementations will frequently access database (MySQL is used). So we use ruby activerecord to implement these two services. Following is the component programming script for store component:

<service name="StoreWebService">
 <interface.wsdl interface="http://www.iist.unu.edu/rcos/cocome/store#wsdl.interface(Store)" wsdli:wsdlLocation="http://www.iist.unu.edu/rcos/cocome/store wsdl/store.wsdl">
 </interface.wsdl>
 <binding.ws endpoint="http://www.iist.unu.edu/rcos/cocome/store#wsdl.endpoint StoreService/StoreSoapPort)" location="wsdl/store.wsdl" />
 <reference>StoreServiceComponent</reference>
</service>
<component name="StoreServiceComponent">
 <rb:implementation.rb script="storews.rb" class="StoreWS"></rb:implementation.rb>
</component>

• After finished component definition, the implementation work contains two parts: defining WSDL file and writing ruby implementation. Ruby activerecord is very powerful to handler database operations, and we use Eclipse to develop all of our applications. Eclipse STP provides a convenient way to develop WSDL file. Two code snippets of store component WSDL file and Ruby source are listed as follows:

...
<wsdl:binding name="StoreSoapBinding" type="tns:Store">
 <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
 <wsdl:operation name="getProduct">
  <wsdlsoap:operation soapAction="http://www.iist.unu.edu/rcos/cocome/store/getProduct" />
  <wsdl:input name="getProductRequest"><wsdlsoap:body use="literal" /></wsdl:input>
  <wsdl:output name="getProductResponse"><wsdlsoap:body use="literal" /></wsdl:output>
  </wsdl:operation>
  ...
  <wsdl:service name="StoreService">
   <wsdl:port binding="tns:StoreSoapBinding" name="StoreSoapPort">
   <wsdlsoap:address location="http://localhost:8080/storews-ruby/services/StoreWebService" />
   </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

require 'rubygems'    
require_gem 'activerecord'

ActiveRecord::Base.establish_connection(
:adapter => "mysql",    
:host => "127.0.0.1",     
...
:database => "store")

class StockItem < ActiveRecord::Base
  set_table_name 'stockitems'
  belongs_to :product,
             :class_name => "Product",
             :foreign_key => "product_id"
end
...

require 'store'

class StoreWS

  def getProduct(barcode)
    return Product.find_by_barcode(barcode)
  end

  def getStockItem(barcode)
	return StockItem.find_by_product_id(getProduct(barcode).id)
  end
  ...
end

• For the manage server, we use JavaServer Page (JSP) and Java Servlet to implement the application. The servlets and jsps will use the client component deployed on the manage server. The client component will use the enterprise server or store server Web Services using SOAP protocol binding on HTTP.
• We also use the above method to implement a bank application that provides a bank Web Services. The sale component in the cashdesk application can use this service to process CardPay.

What do we get?

We have developed all applications very quickly using Tuscany Java SCA framework on Eclipse IDE (about 2 days). The developed applications and components are shown in the following figure.

In the figure, the bold box represents the application, and the box contains the components running in the application, the supporting framework and the platform. For each component, the green arrow represents the provided service and the blue arrow represents the reference (required service). The implementation technologies are given in the bottom of component box. The dotted line represents the connection between two applications or components. And, the text in the box on the line indicates the communication method.

Conclusion

After using rCOS for designing the system, we successfully use SCA concepts and its supporting framework Tuscany Java SCA to implement the supermarket enterprise system in the CoCoME. We have developed six applications for the different parts of the system. These six applications can be deployed to different machines and the communication setup is easy. In addition, the creation of a new supermarket is very direct, and other companies can process some businesses using all the web services provided by the system.

During the development process, we can use the most appropriate implementation technology for different parts of the system, and we also can build the application based on our pervious version. For that reason, our development only need few time. This also corresponds to the spirits of Agile Software Development (Extreme Programming and Adaptive Software Development).

Future Work

We think there are much work to do in the future.

• Some functions in the applications are not finished, and some need to be polished.
• In the 1.0 version of Tuscany, Tuscany Java SCA does not support general conversation management except HTTPSession in the web application. We think this need to be much improved.
• During the implementation process, we can see much correspondence between SCA and rCOS. So, we believe that we can do some work in this direction.
• ...