Engineering Communities of Web Services Sattanathan Subramanian1 , Philippe Thiran1 Zakaria Maamar2 , and Djamal Benslimane3 1 PReCISE,

2 CIT, 3 LIRIS,

University of Namur, Namur, Belgium Zayed University, Dubai, U.A.E

Claude Bernard Lyon 1 University, Lyon, France

Abstract: This paper discusses how communities of Web services are engineered. Web services providing the same functionality are gathered into one community, independently of their origins and the way they carry out this functionality. Two protocols namely Web Services Community Development and Enhanced Contract-Net frame the interactions inside a community. The rst protocol establishes a community including attracting/registering/withdrawing Web services to/with/from this community. The second protocol satises users' needs including selecting/contracting/triggering Web services.

1

Introduction

Web services are, nowadays, considered as the technology of choice to develop B2B applications. A Web service is an accessible application that can be discovered and triggered to satisfy various needs like loan approval and weather forecast [4]. To facilitate and accelerate the process of identifying Web services according to users' needs, we proposed in [6] along with other researchers in [2] and [8] to gather Web services with similar functionality1) into groups to be known as communities. In [2], community is a collection of Web services with a common functionality, although these Web services have distinct non-functional properties. In [8], community is used to cater for an ontological organization of Web services that share the same domain of interest. In [6], community is a means for providing a common description of a desired functionality without explicitly referring to any concrete Web service that will implement this functionality at run-time. In [3, 6] we extensively looked into the concepts and principles that contribute towards dening a community of Web services. For example we discussed the dynamic nature of a community: new Web services join, other Web services leave, some Web services resume operation after suspension, etc. In addition we discussed the conicts that could arise in a community. For 1) Web

services could oer the same functionality although independent bodies develop them.

example, a Web service that leaves a community without prior notice but its peers continue to believe it is still in the community. In this paper we emphasize on how to engineer communities of Web services. This consists of examining how a community is formed and populated, how a community functions, and how a community is dismantled. We advocate that engineering a community of Web services should revolve around three axes. The rst axis concerns the management of a community in terms of how to attract, retain, and "ush" Web services. To this purpose, we devise the Web Services Community Development Protocol (WSCDProtocol ). The second axis concerns the engagement of a community in providing services in terms of how to select, assign, and trigger Web services upon user requests. To this purpose, we devise the Enhanced Contract-Net Protocol (ECNProtocol ). Finally the third axis concerns the monitoring of a community in terms of how to detect, conrm, and assess the unavailability, the non-functional details, and the trustworthiness of Web services, respectively. To this purpose, we make use of both protocols. Section 2 discusses the architecture and functioning of a community. Section 3 details the internal structure of a master Web service. Section 4 is devoted to describing our prototype. Prior to concluding in Section 6, an overview of some related works is given in Section 5.

2 2.1

Community of Web services Architecture

We briey discuss the architecture that supports several communities of Web services. It is shown in Fig. 1. More details are given in [3, 6]. Users of Web services are not shown in this architecture, but could be added if needed. Other components include providers of Web services, UDDI registries, and communities of Web services. A community is dynamic by nature. It is established according to the WSCDProtocol (Section 2.2) and is dismantled as discussed in [6]. For leadership requirements we associated a master component with a community. This component is itself a Web service for compatibility purposes with the rest of the content of a community, namely Web services. These latter are now denoted as slaves and have in common the functionality of the community in which they reside. Master-Slave Web-services relationship is regulated using the ECNProtocol during user requests handling (Section 2.3). Needless to say that a single master Web-service constitutes a bottleneck for a community operation. An immediate solution would use duplicate masters to intervene upon request, but this is outside this paper's scope. A master Web-service takes over several responsibilities: it attracts Web services to sign up in its community, it nominates the slave Web-services that participate in providing services upon

Advertisments

Providers ofWeb services

Interactions

UDDI registries

Advertisments

Providers ofWeb services

Interactions

Consultations

Community 1 of Web services Master-WS

Community 2 of Web services Master-WS

1

Interactions Slave-WS11

2

Interactions Slave-WS1i

Slave-WS21

Slave-WS2j

Figure 1: Representation of communities of Web services

user requests, and it monitors their performance and takes actions in case of failure. Slave Web-service provide services to the master Web-service upon its nomination, and providing support to monitor its presence by the master Web-service.

2.2

The WS Community Development Protocol

The main purpose of the WSCDProtocol is to frame the operations that result in establishing a community and managing its content of Web services. This establishment is initially triggered by a designer who identies the functionality (e.g., LoanApproval ) of the future community, denes and sets-up the master Web-service. Afterwards the master Web-service handles the rest of community establishment operations automatically by inviting slave Webservices to join this community. Upon invitation acceptance, the master Web-service checks the credentials (e.g., protection mechanisms, interaction protocols, exception policies) of each slave Web-service that enter the community. This checking has a dual advantage: boost the security level among the peers in a community and enhance the trustworthiness level of a master Web-service towards the slave Web-services it manages. The rst advantage avoids dealing with malicious Web services that could attempt to alter peers' behaviors. The second advantage shows how much the master Web-service relies on the slave Web-services in completing the prescribed operations. It should be noted that slave Web-services could turn out to be "lazy"2) , which calls for their immediate ejection from a community. UDDI Slave Web-service

4,5,7,8 3,6,7,8

Master Web-service

Chronology 1. Lookup request; 2. WSDL's URL 3/4. WS community membership request/response 5/6. WS registration request/response 7/8. WS withdrawal request/response

1 2 Legend

WS 1 | WS n

Continuous operation WS: Web service

Figure 2: Chronology of operations in the WSCDProtocol

Fig. 2 shows the interactions between master Web-service, slave Web-service, and UDDI reg2) Web

users.

services that do not satisfy the QoS that a master Web-service advertises and guarantees to potential

istry during the WSCDProtocol deployment. These interactions are grouped into three categories: WS-Attraction with operations 1 to 4, WS-Registration with operations 5 and 6, and WS-Withdrawal with operations 7 and 8. A slave Web-service could decide to leave a community for various reasons like lack of business opportunities in a community or when it receives a departure notice from the master Web-service due to poor performance.

2.3

The Enhanced Contract-Net Protocol

The main purpose of the ECNProtocol is to frame the operations that result rst, in identifying the slave Web-service that will handle user's request and second, in following the performance of this request (Fig. 3). The interactions that happen during the ECNProtocol deployment are grouped into two categories: ContractAgreement with operations 1 to 4, and ContractCompletion with operations 5 and 6. The ECNProtocol is mainly built upon the contract-net protocol that uses the idea of contracting and subcontracting jobs between two types of agents known as initiator and participant [11]. Note in our case that "initiator" is master Web-service and "participant" is slave Web-service. Applying the contract-net protocol to a community of Web services occurs as follows (Fig. 3). When a user (through some assistance) selects a community because it has the functionality that satises her needs (Op. 1), the respective master Web-service continues next by identifying a specic slave Web-service out of this community. The master Webservice sends a call for bids out to the entire slave Web-services about the implementation of the functionality (Op. 2). Prior to getting to the master Web-service back with responses, the slave Web-services assess their status by checking ongoing and forthcoming participations in other composite Web services [5]. Only the slave Web-services that are interested in bidding interact with the master Web-service (Op. 3). This latter screens all the bids before choosing the best one (based on Web service's execution cost and reliability level, for example). The winning slave Web-service is notied so, it gets ready for execution when requested (Op. 4). The rest of the slave Web-services that expressed interest but were not selected, are notied as well (Op. 4).

User

1 6

2,4 Master Web service 2

Chronology 1. Service request; 2. Call for bids; 3. Expression of interest 4. Contract awarded and peer notification; 5. Result submission; 6. Service response

3,5

3

Slave Web service1 Slave Web service2

Figure 3: Chronology of operations in the ECNProtocol

On top of the four aforementioned operations that are intrinsic to the contract-net protocol, the ECNProtocol includes two additional operations: tracking Web service execution (Op. 5) and guaranteing result delivery (Op. 6).

2.4

Interactions between both protocols

We recall that WSCDProtocol and ECNProtocol manage communities in terms of attracting Web services to these communities and supporting their engagement in providing services related to users' needs. These protocols run in parallel and can be initiated from two points: Start/WSCDP is the beginning of a community-management scenario and Start/ECNP is the beginning of a user-need-satisfaction scenario. In addition to the transitions that are intra to WSCDProtocol and ECNProtocol respectively, these protocols connect with one another as depicted in Fig. 4. On one hand, the transition from WSCDProtocol to ECNProtocol shows the Web services that are interesting in bidding to satisfy users' needs (i.e., requested Web service). On another hand, the transition from ECNProtocol to WSCDProtocol shows the Web services that need now to be evaluated following users' needs satisfaction. Inter- and intratransitions are supported with appropriate mechanisms like WS-Registration, WS-Withdrawal, and ContractCompletion as depicted again in Fig. 4. Start/WSCDP

WSCDProtocol WS-Withdrawal

WSs performance evaluated

More WSs needed

ContractCompletion

WS-Attraction

Contract details assigned

WSs confirmed joining

WS-Registration

ContractAgreement

WSs interested in bidding

ECNProtocol Legend Intra-protocol transition

Start/ECNP Inter-protocol transition

Figure 4: Intra- and inter-protocol interactions

3

Master Web-service: internal structure

We present the main functions that embody master Web-service. WSCDProtocol and the ECNProtocol trigger these functions at run-time. In the following, M/SWS stands for M aster/S lave W eb S ervice. Fig. 5 presents the main functions of a master Web-service. They are grouped into three modules: (i) MWS-Development consists of MWS-Attraction, MWS-Registration, and MWSWithdrawal functions; they are devoted to the WSCDProtocol, (ii) MWS-RequestHandler consists of MWS-Request, MWS-Response, MWS-ContractEstablishment, MWS-ContractResult, and MWS-DataMediation functions; they are devoted to the ECNProtocol, and nally (iii) MWSMonitoring consists of MWS-Liveness, MWS-QoS, and MWS-Trust support functions; they are devoted to both protocols. In Fig. 5, two interfaces exist. MWS-Community-Interface provides an external interface to the slave Web-services for the following functions: MWSRegistration, MWS-Withdrawal, and MWS-ContractResult. MWS-Abstract-Interface provides an external interface to an user for triggering Web services.

1) MWS-Development module. In this module, MWS-Attraction function implements Op. 1 through Op. 4 of the WSCDProtocol (Fig. 2). Initially, this function submits to an UDDI registry the name of the functionality that labels the master Web-service's community (Op. 1). Upon reception, the UDDI-registry returns details like WSDL les on some Web services that could be potential candidates to join in this community because of the matching between their respective functionalities and this community's functionality (Op. 2). Afterwards, MWS-Attraction function extracts the URLs from these WSDL les and makes an explicit call to the appropriate Web services. The objective of this call is to invite the candidate Web services to be part of the community of the master Web-service using arguments like reputation and benets (Op. 3). The Web services that show interest get in touch with the master Web-service (Op. 4). In addition if they accept the invitation, MWS-Registration function gets triggered (Op. 5 and Op. 6). Master Web-service SOAP

UDDI Interface

UDDI

SOAP

MWS-Abstract Interface

User

MWS-Registration

MWS-Withdrawal

MWS-RequestHandler MWS-Request

MWS-Response

MWS-ContractEstablishment

MWS-DataMediation MWS-ContractResult

MWS-Monitoring MWS-QoS

MWS-Trust

MWS-Community Interface

MWS-Development MWS-Attraction

SOAP

Slave Web-service1

SOAP

Slave Web-servicen

MWS-Liveness

Figure 5: Master Web-service architecture

MWS-Registration function identies as well the required mappings, i.e., data mediation via MWS-DataMediation of MWS-RequestHandler module, that need to be established during master-slave Web-services communications. For instance, we consider where the master Web-service oer a service called getZipCode as a community, but the slave Web-service oers the same functionality with the dierent name called lookupZipCode. This requires a mediation to establish master-slave Web-services communications, it is taken care by the MWS-DataMediation function. These mappings are later submitted to MWS-ContractEstablishment function of MWS-RequestHandler module and MWS-QoS function of MWS-Monitoring module. The objective is to keep them updated about the new Web service that will shortly be considered as a slave. In MWS-Development module, MWS-Withdrawal function pulls a slave Web-service out of a community (Op. 7 and Op. 8 of WSCDProtocol ) if for instance, the trust level between a master Web-service and a slave Web-service goes below a certain predened threshold. Trust level is obtained using MWS-Trust function of MWS-Monitoring mod-

ule. To withdraw a slave Web-service, a master Web-service uses SWS-Withdrawal function that a slave Web-service provides. MWS-Withdrawal function also supports the slave Web-service when it withdraws itself from the community.

2) MWS-RequestHandler module. Its various functions are in charge of running the ECNProtocol (Fig. 3). MWS-Request function implements Op. 1 by receiving and passing the user's request like hotel booking on to MWS-ContractEstablishment function. This one performs Op. 2 through Op. 4 by sending a call for bids out to all slave Webservices (Op. 2) and waiting for responses from interested slave Web-services (Op. 3) by using SWS-CallForProposal function that a slave Web-service provides. Following bestbid selection, MWS-ContractEstablishment function assigns a contract to the slave Webservice of the best bid and informs the rest of slave Web-services about this assignment as well (Op. 4) by using SWS-AwardWithContract function that a slave Web-service provides. After a while, the slave Web-service nishes processing the user's request and provides results to MWS-ContractResult function (Op. 5 and Op. 6) that forwards these results to MWS-Response function. The purpose is to format and modify results using MWS-DataMediation function so the user's requirements (e.g., preferred language) are met. In addition MWS-ContractEstablishment and MWS-ContractResult functions provide performance details on the slave Web-service that completed the functionality to MWS-Trust function of MWS-Monitoring module. MWS-ContractResult(Results) illustrates how Op. 5 of the ECNProtocol is called by a slave Web-service, where

• MWS-ContractResult is the name of the function which is used by a slave Webservice to provide the contract results to a master Web-service. • Results is the message to be sent out to an user. It has a complex data type and is business-driven.

3) MWS-Monitoring module. It mainly contains functions that support the performance of the functions of MWS-Development and MWS-RequestHandler modules. MWS-QoS function receives details from MWS-Registration and MWS-Withdrawal functions of MWS-Development module on a slave Web-service that is about to enter or leave a community, respectively. MWS-Trust function receives details from MWS-ContractEstablishment function and MWS-ContractResult function of MWS-RequestHandler module on the current QoS of a slave Web-service after performing a user's request. The objective is to rate the performance of this slave Web-service. How to rate is beyond this paper's scope, interested readers are referred to [7]. Finally, MWS-Liveness function is the ping utility that a master Web-service uses to check the liveness of a slave Web-service by using SWS-Liveness function that a slave Web-service provides. This function provides as

well details to MWS-Trust function so it can compare between the agreed QoS of a Web service and the assessed QoS during performance.

4

Prototype development

We developed a prototype to experiment WSCDProtocol and the ECNProtocol using (1) XML for request and response specication between users and Web services and between master Web-services and slave Web-services; (2) JDK 1.4 for operation processing, and (3) Eclipse 3.2 as an integrated development environment. We are using WeatherCommunity for illustration purposes, it can have many Weather Web services. Initially the content of WeatherCommunity is null. So, the master Web-service triggers MWS-Attraction function to interact with an UDDI registry. The master Web-service receives later details on Weather Web-service1 . Following invitation reception and acceptance, Weather Web-service1 registers as a slave Web-service in the community of the master Webservice. This one approves the registration request by assigning an identier to Weather Webservice1 . Similarly Weather Web-services2/3/4 join WeatherCommunity (Fig. 6).

Figure 6: Scenarios of Web services registration

When the master Web-service receives a request about weather forecast, this request is passed on to the four slave Web-services of the community. Each slave Web-service in Weather community assesses its status and checks its capacity of handling the request [5]. slave Web-services's report back (Fig. 7) to master Web-service depends on the initial time-slot commitment.

(a) Weather-1

(b) Weather-2

(c) Weather-3

(d) Weather-4

Figure 7: Responses from the slave Web-services to the master Web-service's call for bids

Once the availabilities of the community members are known, the master Web-service selects a slave for example Weather Web-service2 and the rest of Weather Web-service1/3/4 get notied as well (Fig. 8). Once the notication messages are received, the slave-weather Web service2 updates its commitment information.

(a) Weather-2

(b) Weather-3

(c) Weather-4

Figure 8: Selection of slave Web-service

5

Related work

Paik et al. [10] present, the WS-CatalogNet system, which aims at cataloguing Web services communities and creating peer relationships between them. The dierent communities can then collaborate for the need of a query processing. Communities are described in terms of category denitions represented with class description languages. The relationship between communities can be created when their categories are similar to a certain extent. The WSCatalogNet system also provides monitoring functionality in terms of logging community events, and analyzing community interaction. In [9], Medjahed et al. propose the WebBIS system as a generic framework for dening and managing Web service composition in dynamic environments. One of the main idea of the proposed framework is to semantically organize the Web services space in terms of pull-communities and push-communities. These two kinds of communities are used to gather Web services with static and dynamic relationship respectively. A WebBIS-SDL language is proposed to monitor and advertised Web services. OASIS standard [1], WSDM's Management of Web Services specication extends MUWS to dene how to specically manage a resource that is a Web service. Web services, like other resources, have identity, metrics, conguration, and other capabilities to enable management3) . But it didn't establish the view of Web service community, so it didn't dene the following: (i) how to attract new Web-services, (ii) how to register/withdraw a Web service to/from a community, (iii) how to establish ContractAgreement and ContractCompletion towards providing services to the users, (iv) last but not the least, how to monitor the performance of a slave Web-service in a community. Our proposed approach to engineer Web services communities is dierent from the aforementioned approaches, where we looked into communities from two perspectives: content management and content performance. Content means Web services. To this end, we developed the WSCDProtocol and the ECNProtocol that are, in fact, not tied to any specic community model. 3) http://www-128.ibm.com/developerworks/webservices/library/ws-wisdom/

6

Conclusion and future work

We discussed how to engineer communities of Web services. The primary role of a community is to gather Web services with similar functionalities regardless of who developed them and how they carry out these functionalities. We structured the architecture of a community by identifying two types of Web services, namely master and slave. A master Web-service leads a community and interacts with users and providers of Web services. And a slave Webservice is in charge of satisfying users' needs as per the master Web-service's request. The interactions between master and slave Web-services were regulated using WSCDProtocol and the ECNProtocol. As future work we plan to examine how to monitor the performance of a community of Web services.

References [1] Web Services Distributed Management: Management of Web Services (WSDM-MOWS) 1.0. OASIS Recommendation, December 2004. [2] B. Benatallah, Q. Z. Sheng, and M. Dumas. The Self-Serv Environment for Web Services Composition. IEEE Internet Computing, 7(1), January/February 2003. [3] D. Benslimane, Z. Maamar, Y. Taher, M. Lahkim, M. C. Fauvet, and M. Mrissa. A Multi-Layer and Multi-Perspective Approach to Compose Web Services. In Proceedings of The IEEE 21st International Conference on Advanced Information Networking and Applications (AINA'2007), Niagara Falls, Ontario, Canada, 2007. [4] F. Daniel and B. Pernici. Insights into Web Service Orchestration and Choreography. International Journal of E-Business Research, The Idea Group Inc., 1(2), 2005. [5] Z. Maamar, S. Kouadri Mostéfaoui, and H. Yahyaoui. Towards an Agent-based and Context-oriented Approach for Web Services Composition. IEEE Transactions on Knowledge and Data Engineering, 17(5), May 2005. [6] Z. Maamar, M. Lahkim, D. Benslimane, P. Thiran, and S. Sattanathan. Web Services Communities - Concepts & Operations -. In Proceedings of The 3rd International Conference on Web Information Systems and Technologies (WEBIST'2007), Barcelona, Spain, 2007. [7] M. Maximilien and M. Singh. Toward Autonomic Web Services Trust and Selection. In Proceedings of The 2nd International Conference on Service-Oriented Computing (ICSOC'2004), 2004. [8] B. Medjahed and A. Bouguettaya. A Dynamic Foundational Architecture for Semantic Web Services. Distributed and Parallel Databases, Kluwer Academic Publishers, 17(2), March 2005. [9] M. Medjahed, B. Benatallah, B. Bouguettaya, and A. Elmagarmid. Webbis: An Infrastructure For Agile Integration of Web Services. International Journal of Cooperative Information Systems, 13(2), 2004. [10] H. Y. Paik, B. Benatallah, and F. Toumani. Toward self-organizing service communities. IEEE Transactions on Systems, Man, and Cybernetics, Part A, 35(3), 2005. [11] R. Smith. The Contract Net Protocol: High Level Communication and Control in Distributed Problem Solver. IEEE Transactions on Computers, 29, 1980.

Engineering Communities of Web Services

2CIT, Zayed University, Dubai, U.A.E. 3LIRIS .... nity for various reasons like lack of business opportunities in a community or when it receives a departure notice ...

262KB Sizes 0 Downloads 237 Views

Recommend Documents

web services communities
May 14, 2006 - Web services offering the same functionality are gathered into one community, ..... namic Foundational Architecture for Semantic Web. Services.

Reputation of Communities of Web services ...
ties needs to be looked into from two perspectives: provider and user. ..... A reputation model would here support providers of Web services identify the ...

Reputation of Communities of Web services
based Web services community architecture and define some of the performance .... In addition to support the selection of the best Web ser- vices, a reputation ...

Google+ Communities Services
Communities provide a forum for you and your audience to share relevant content about your brand. Below are two key strategies for how to establish communities and examples of how brands are making the most of these strategies. Give your followers a

Checklist for Creating Successful Communities - Services
Add a 200-pixel-wide by 250-pixel-tall photo that captures your community's spirit and makes a good impression. Add a clear and descriptive tagline to attract the right members. In the 'About' section, add additional information relevant to your comm

Overview of business models for Web 2.0 communities
type of Web 2.0 communities as for example: social networking communities ... Based on the answers of the two questions, the paper tries to provide a more ... next step a list of potentially popular Web 2.0 services was adopted from the website of ..

Overview of business models for Web 2.0 communities
be video, data or text content, as well as enriching this content through metadata, annotations or history. .... 08/04, S. 44-48. [Guha91] Guha, R. V., Bray, T., 1997"An Meta Content Framework (MCF) Tutorial", ... Big profits is tougher", New York ..

Catalog
18: Studio Visit: SEO. 17: Terry Haggerty: Angle ...... 19: Interview with Vera Cortês / Vera Cortês Art Agency / ARCO 2008 Madrid, Spain. 18: Dan Perjovschi: Stu ...

DataCite2RDF
Feb 4, 2016 - class pro:Role in PRO, or of its sub-classes in SCORO: • scoro:contact-person. • scoro:data-creator. • scoro:data-curator. • scoro:data-manager. • pro:distributor. • pro:editor. • scoro:funder. • scoro:host-institution.

negative
Jun 3, 2016 - Oil near USD50/bbl but industry players not excited ... should disconnect oil services players' stock price with oil price as ..... Software Technology • Telcos ..... constituting legal, accounting or tax advice, and that for accurate

negative
Jun 3, 2016 - stronger confidence on oil price sustainability, there is little hope for a .... year, the sentiment from oil companies remains negative and capital .... Automotive • Semiconductor • Technology ..... Structured securities are comple

Catalog
18: Studio Visit: SEO. 17: Terry Haggerty: Angle of Response / Kuttner Siebert Gallery, Berlin. 14: Interview with Dan Perjovschi at Fumetto Festival Lucerne.

Catalog
10: Urs Fischer: Service à la Française (2009) / Luma Westbau / Pool etc. ...... 10: Claes Oldenburg & Coosje van Bruggen: The European Desktop / Ivorypress ...

Behavioral Compatibility of Web Services | SpringerLink
Part of the Lecture Notes in Computer Science book series (LNCS, volume ... better evaluation of compatibility by quantifying the degree of compatibility as a ...

DataCite2RDF
Feb 4, 2016 - Changes the examples used for 6 Subject, and for 11 AlternateIdentifier. 5. Corrected an RDF term duplication in 7.2 contributorName. 6. Improvement to the formatting of the exemplar RDF statements, to enhance clarity. 7. Added “data

Open Web of Things Expedition Services
A description for this result is not available because of this site's robots.txtLearn more

Java Web Services
It uses technology available from Apache, IBM, BEA, Sonic .... By using XML as the data representation layer for all web services protocols and .... However, one of the big promises of web services is seamless, automatic business integration:.

Output file
Mar 2, 2015 - segments except for PC & Data Storage achieved top-line growth, with ... Note: Industry universe defined as companies under identical GICS ...

Mark I
returned directly to our Southport Service inepartment for repair. See the Service ..... are prohibited by Federal law from shipping a handgun by Mail. Handguns ...

Greater Connected
I was delighted to accept the invitation from fellow business leaders to chair an independent business led review of the submissions to. Government by the five ...

Morning Note
Nov 6, 2015 - We attended a site visit to Green Build Technology (GBT) in Harbin, ... sharing of the new business direction by venturing into energy ...

R&D
Research and Development (R&D) Projects. Applying Logic ... 2)National Institute of Advanced Industrial Science and Technology (AIST). Evaluation 2007( AEA ...

Mark I
models have the same basic operating mechanism. WARNING: ...... customers through its membership and participation in the programs of the. National Rifle ...