The proposed approach is based on Semantic Web Services. It is assumed that services are registered at a matchmaker with semantics descriptions in a given ontology. Service brokers are also services that are registered with matchmakers. They also invoke the matchmaker to fulfil its functionality. 1. Communicator: It provides an interface to submit service requests in the form of tasks and receive results of the service invocation, if the task is performed successfully. It transforms messages into the internal representations for further processing. The results are also assembled into SOAP messages as responses to the requester. 2. Knowledge-base: It contains codified knowledge on how a task can be fulfilled by a number of subtasks. Each type of tasks is defined by a set of parameters. There are two kinds of parameters: descriptive parameters and functional parameters. The former describes the functionality of the task, such as the activity of the task, the execution environment of the task, and so on. The latter gives the data to be transformed by the task, including input and output data. The values of these parameters are concepts defined in the ontology of the application domain. 3. Planner: It analyses the requested service and searches the registry to determine if it can be fulfilled by services existing in the registry directly. If not, it searches the knowledge-base to find how it can be decomposed into subtasks and generates abstract service composition plans. For a given requested service, there may be multiple plans that can fulfil it. In particular, it compares the requested service with the rules in the knowledge-base. The parameters of the corresponding subtasks of the rule will then be instantiated with the corresponding values assigned to the parameters of the task. An abstract composition plan is thus generated. 4. Search Engine: Given an abstract service composition plan, the search engine calls the matchmaker of semantic WS registry to find appropriate services for each subtask. The search request is constructed according to the description of the subtasks generated by the task planner as in the abstract service composition plan and submitted to the matchmaker. The search result returned by the matchmaker may include multiple candidates. Each of them is tagged with a score that represents its fitness to the searched capability. The higher the score is, the more suitable to fulfil the subtask, and hence the higher priority to be selected to perform the corresponding subtask. Through selecting service candidates to fulfil the subtasks, the abstract service composition plan is instantiated into an executable concrete service composition plan. To achieve a higher flexibility and fault tolerance, the candidates that have lower scores but above a threshold are also preserved. When the selected service fails later on in the invocation, the candidate with the second highest score, if any, is then selected. 5. Coordinator: It is responsible for the invocation of selected services for the subtasks with appropriate parameters and for the coordination of these services. In particular, the results of previous services are re-assembled as parameters for the following services according to their dependency. 6. Controller: It controls the execution of the broker. Once it receives a request of a task from the communicator, it invokes the planner to generate a set of abstract service composition plans according to the knowledge-base. Then, it selects a plan and invokes the service search engine to search for appropriate services registered in the matchmaker for each subtask in the selected abstract composition plan. If succeed, one service will be selected for each subtask. Subsequently, it informs the coordinator to invoke and coordinate the selected services according to the concrete composition plan.