text:
<!-- toc -->

- [Architecture](#architecture)
- [Concept](#concept)
- [Implementation](#implementation)
  * [Service Invocation Enum](#service-invocation-enum)
  * [Service Invocation SOAP API](#service-invocation-soap-api)
  * [Service Invocation Java API](#service-invocation-osgi-event-api)
  * [Service Invocation Engine](#service-invocation-engine)
  * [Service Invocation Plugin Interface](#service-invocation-plugin-interface)
  * [Service Invocation SOAP/HTTP plugin](#service-invocation-soaphttp-plugin)
  * [Service Invocation REST/HTTP plugin](#service-invocation-resthttp-plugin)
- [Assumptions](#assumptions)

<!-- tocstop -->

> The service invoker abstracts from different technologies such as SOAP and REST

## Architecture
Figure 1 shows the architecture of the service invocation interface.
The main component of the service invocation interface is the SI Engine (see [SI Engine](#service-invocation-engine)).
It forms the central unit of the service invocation interface with its connection to the other  important components within the OpenTOSCA container.
Furthermore the Service Invocation APIs (see [SI SOAP API](#service-invocation-soap-api) and [SI OSGi event API](#service-invocation-osgi-event-api)) are an important part of the service invocation interface.

![Architektur des OpenTOSCA Containers mit Service Invocation Schnittstelle](graphics/ServiceInvoker/ArchitectureOpentoscaContainerWithServiceInvocationInterface.png)

Figure 1: Architecture of the OpenTOSCA container with service invocation interface

The SI engine has among other things the task to determine the implementation artifact that belongs to the invoke request, further required information, as well as the invocation type of the implementation artifact with the TOSCA engine.
Furthermore the SI engine uses the endpoint service to acquire the endpoints of the implementation artifact or plans.
An interface with the instance data service offers the option to invoke and use instance data of previously executed plans.

The invocations of implementation artifacts or plans happen through the so called SI plugins (see [SI Plugin Interface](#service-invocation-plugin-interface)).
These plugins offer support for different protocols and standards (invocation types), like for example sending a message with SOAP via HTTP or the invocation of an OSGi implementation artifacts and can be added and started during the runtime if necessary.
The administrator of the SI plugins is also the SI engine, with an extra designed OSGi based plugin system.

The functionality of the service invocation interface is provided with different service invocation APIs, like for example a SI SOAP API or a SI REST API.
With them other components, applications and implementation artifacts and especially plans can use the service invocation interface.
If for an example a plan wants to invoke a management operation declared in TOSCA, which is implemented with a SOAP/HTTP implementation artifact.
The plan sends a message to the service invocation SOAP API which contains all the necessary information.
The contents of this message are passed to the SI engine.
There further data like the endpoint is acquired and subsequently all information is passed on to a suitable plugin where the invocation is executed.
The exact processing process is explained in more detail in the following chapter.

## Concept

In this chapter the concept of the service invocation interface and the options of the concept are explained.

![Konzeptioneller Aufbau der Komponenten](graphics/ServiceInvoker/ConceptualStructureOfComponents.png)

Figure 2: Conceptual structure of the components

Figure 2 shows that the SI engine constitutes the central component within the service invocation interface.
It enables the communication with existing and required components of the OpenTOSCA container (TOSCA engine, endpoint service, instance data service) and provides the connection between the service invocation API and the different SI plugins, it therefore takes on the routing of messages within the service invocation interface.
Figure 3 illustrates this with a layer diagram.

![Service Invocation Schnittstelle als Schichtendiagramm](graphics/ServiceInvoker/ServiceInvocationInterfaceAsLayerdiagram.png)

Figure 3: Service invocation interface as layer diagram

Figure 2 shows the usage of the exchange object.
Within the service invocation interface and the components the exchange object provided by [Camel](http://camel.apache.org/) is used to pass data and messages.
The communication between the SI engine (and therefore the service invocation interface) and the other components of the OpenTOSCA container happens trough passing individual parameters.
This has the advantage that within the service invocation interface the advantages of the exchange objects can be used, the other components of the container however can stay independent of Camel and therefore independent of the service invocation interface which means they do not have to be adapted.

Figure 2 also features an Enum.
This Enum (see [SI Enum](#service-invocation-enum)) is defined and specifies the keys of the headers and the message object.
This ensures that the messages passed from the service invocation API to the SI engine and the messages passed from the SI engine to the SI plugin are uniform in there make up regarding the parameters contained in the headers.
This enables the componentwise identical and reliable read out of all necessary information like CsarID or ServiceTemplateID.
It would also be possible to make an object with fields for the required parameters (CsarID, ServiceTemplateID, OperationName, ...).
The HashMap as object for the headers simulates such an object together with the Enum to pass the required parameters.
But the solution with the enum, which determines the keys for the required parameters in the header HashMap, is more flexible and intended in Camel.

Figure 4 shows the sequence of an exemplary processing sequence inside the service invocation interface beginning with the invocation trough a plan, processing of the query in the SI engine and the invocation of the implementation artifact, and the response back to the plan.

![Bearbeitungsablauf zum Aufruf eines Services](graphics/ServiceInvoker/WorkflowServiceInvocation.png)

Figure 4: Processing sequence to invoke a service

First the plan invokes the service invocation SOAP API with a SOAP message containing all the data required to invoke the implementation artifact.
The service invocation SOAP API unmarshalles this SOAP message, reads the passed data, writes it into a exchange object and forwards this to the SI engine.
The parameters in the headers to determine the implementation artifacts are in a format comprehensible to the SI engine because of the defined Enum.

The SI engine collects information about the to be invoked implementation artifact, like name and invocation type, with the TOSCA engine and the received data.
Furthermore it determines the message exchange pattern (MEP) of the implementation artifact, from the in the TOSCA definition specified values for the to be invoked operation.

As part of the service invocation interface we differentiate between the two WSDL 2.0 based MEPs, [In-Out](http://en.wikipedia.org/wiki/Request-response) and In-Only.
The In-Out pattern specifies that for an incoming message (Input) an answer has to be given (Output).
Listing 1 shows an example of the In-Out pattern in a TOSCA definition.
In contrast the In-Only pattern specifies that for a query no answer is sent.
An example for this is displayed in Listing 2.

```
01 <Operation name="createDB">
02 	<InputParameters>
03 		<InputParameter name="Size" type="xs:string"/>
04	 	<InputParameter name="Host" type="xs:string"/>
05 		<InputParameter name="User" type="xs:string"/>
06 		<InputParameter name="Password" type="xs:string"/>
07 	</InputParameters>
08 	<OutputParameters>
09 		<OutputParameter name="URL" type="xs:string"/>
10 	</OutputParameters>
11 </Operation>
```
Listing 1: Example In-Out Pattern
```
01 <Operation name="deleteDB">
02 	<InputParameters>
03 		<InputParameter name="URL" type="xs:string"/>
04 		<InputParameter name="User" type="xs:string"/>
05 		<InputParameter name="Password" type="xs:string"/>
06 	</InputParameters>
07 </Operation>
```

Listing 2: Example In-Only Pattern

Subsequently the SI engine determines with the additional information the endpoint of the implementation artifact with the help of the endpoint service (see 4).

Optionally, if during the invocation of the service invocation SOAP API the ID of an CSAR instance is given, the SI engine examines if saved instance data exist for this CSAR instances and if that is the case uses it.
The instance data can have been saved by any previous plan.

Afterwards the SI engine determines with the invocation type of the implementation artifact a suitable SI plugin and sends all collected data to it with an exchange object.

The plugin creates an request message from the received information and sends it to the implementation artifact (see 7).
The invocation can happen synchronous or asynchronous depending on the implementation of the implementation artifact and the responsibility lies with the respective plugin.

The response of the implementation artifact is sent from the SI plugin to the SI engine and from there to the service invocation SOAP API (see 8).
There it is unmarshalled and converted in a SOAP message.
Finally the service invocation API sends this SOAP message back to the plan (see 9), which can now work with the data received from the implementation artifact.

In this example the invocation of a as a SOAP web services implemented implementation artifact happens through a plan.
Naturally other invocation scenarios are possible.
For example the invocation of an implementation artifact implemented as a RESTful web service of an OSGi service.
Furthermore there is the possibility to invoke a plan, initiated with the plan invocation engine or another plan.

![Beispielhafte Nachrichten / Aufrufe](graphics/ServiceInvoker/ExamplaryMessagesInvocations.png)

Figure 5: Exemplary messages / invocations

Figure 5 shows the described scenario - the invocation of a SOAP web service implementation artifact with a plan - in an example with concrete messages und values.
The messages and invocations are truncated in the figure.
The complete messages and invocations are explained below.

Listing 3 shows the extensive SOAP invocation of the plan to the service invocation SOAP API.
Goal of the invocation is to invoke the implementation artifact, specified in rows 8 to 18 with the operation createDB and the parameters specified in rows 22 to 40.
The specification of ReplyTo in row 19 tells the service invocation interface at which address the callback with the response should be sent.
The MessageID is sent back to the plan from the service invocation interface, because it is required by the workflow engine to be able to assign the query response as well as the correct plan instance.

```xml
 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.
 									org/soap/envelope/" xmlns:
 									sch="http://siserver.
 									org/schema">
 		<soapenv:Header/>
 		<soapenv:Body>
 			<sch:invokeOperation>
 			<CsarID>DBCsar</CsarID>
 			<!--Optional:-->
 			<ServiceInstanceID>Instance5</ServiceInstanceID>
 			<ServiceTemplateIDNamespaceURI>
 				http://CsarDBCreator.org/DB/
 			</ServiceTemplateIDNamespaceURI>
 			<ServiceTemplateIDLocalPart>
 				DBCreator\_ServiceTemplate
 			</ServiceTemplateIDLocalPart>
 			<NodeTemplateID>DB\_NodeTemplate</NodeTemplateID>
 			<OperationName>createDB</OperationName>
 			<ReplyTo>http://localhost:1337/callback</ReplyTo>
 			<MessageID>A7ZD70AH</MessageID>
 			<!--Optional:-->
 			<Params>
 				<!--1 or more repetitions:-->
 				<Param>
 					<key>Size</key>
 					<value>5</value>
 				</Param>
 				<Param>
 					<key>Host</key>
 					<value>Azure</value>
 				</Param>
 				<Param>
 					<key>User</key>
 					<value>admin</value>
 				</Param>
 				<Param>
 					<key>Password</key>
 					<value>p8ilR6N9</value>
 				</Param>
 			</Params>
 		</sch:invokeOperation>
 	</soapenv:Body>
 </soapenv:Envelope>
```
Listing 3: SOAP message of a plan to the service invocation interface to create a database

The SOAP message is converted by the service invocation SOAP API, illustrated in figure 6, and forwarded to the SI engine.
This is done using the exchange object that is provided by Camel.
The parameters for the implementation artifact (size, host, user, password) are saved in the message body.
The data to determine the implementation artifact and its invocation are in the message header.
Further values like ReplyTo and MessageID are also put in the header.
Those values however are not defined by the SI Enum, because they are not needed by the SOAP API or other SI components.

The SI engine gets the required data from the header, uses it to determine the implementation artifact with the help of the TOSCA engine and acquires the endpoint with the endpoint service.
This is also put into the header of the message object under the key defined by the SI Enum.

Furthermore the SI engine checks per instance data service if instance data for this invocation is saved and if so gets it from there.
This is however optional and only happens for ServiceInstanceIDs specified by the invoker.
Subsequently the input parameters in the message body are replaced with the values from the instance database and updated.
Like this IP addresses of a previously setup virtual machine can be used for example.

![Von der Service Invocation SOAP API an die SI-Engine gesendete Message](graphics/ServiceInvoker/MessageFromInvocationApiToSiEngine.png)

Figure 6: Message from the service invocation SOAP API to the SI engine

Finally after the invocation type of the implementation artifact has been determined with the TOSCA engine a fitting plugin is chosen and the exchange message supplied with all necessary information is forwarded to it.

![Sequenzdiagramm SI-Engine](graphics/ServiceInvoker/SequencediagramSiEngine.png)

Figure 7: Sequence diagram of the SI engine

Figure 7 displays the communication of the SI engine with the TOSCA engine, endpoint service, instance data services and a SI plugins as a sequence diagram.
It shows how the SI engine determines an invokable implementation artifact with the parameters and the TOSCA engine.
First the NodeType that belongs to the parameters CsarID, ServiceTemplateID and NodeTemplateID is determined (NodeTypes categorize NodeTemplates). Subsequently all NodeTypeImplementations for this NodeType are queried.
The list of NodeTypeImplementations is iterated and all implementations artifacts are determined.
This list of implementation artifacts is also iterated and each implementation artifact is checked if it offers the required operation.
If the name of the operation is unique within a NodeType, only the specification of the name is required.
If however the operation is not only offered by the interface of one NodeType the name of the interface has to be specified as well to uniquely identify it.
If the operation is offered it is also checked if a invocation type was specified in the TOSCA definition and if a plugin is available.
If that is the case the endpoint service check if an endpoint for this implementation artifact is saved and if it was deployed by the container.
If that is also the case a invokable implementation artifact has been found.
The sequence diagram shows furthermore the communication with the instance data service (if a ServiceInstanceID has been provided) as well as the invocation of an SI plugin.

In Figure 8 the message enriched by the SI engine is shown.
The endpoint of the implementation artifact was determined and added as header, a parameter in the body was replaced by a value from the instance database.
In this example the implementation artifact is told to create a database at Amazon Web Services (AWS) instead of at Microsoft Azure.
A previously executed plan could have this saved and after checking that the prices for databases at AWS are better then at Azure.

![Durch die SI-Engine angereicherte und an ein SI-Plug-in gerichtete Message](graphics/ServiceInvoker/ExpandendMessageFromSiEnginToSiPlugin.png)

Figure 8: A message directed to a SI plugin enriched from the SI engine

After the message has been passed to the SI plugin suitable to the invocation type, it reads the information required (OperationName, Endpoint) for the invocation of the implementation artifact from the header and gets the parameters from the body.
What happens afterwards with this data and how the actual invocation of the implementation artifact happens is plugin specific and therefore can differ from plugin to plugin.
In the case of the SOAP/HTTP plugin for example further information is read from the WSDL belonging to the implementation artifact, a SOAP message corresponding to the WSDL is created and this is sent to the implementation artifact.
From the response, in the case of a SOAP message this would be the body, the output parameters are extracted and those are put into the body of the message object which gets returned to the SI engine.

```xml
 <soap:Envelope
 xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
 soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 	<soap:Body xmlns:m="http://www.DBIA.org/DBCreator">
 		<m:CreateDBRequest>
 		<m:Size>5</m:Size>
 		<m:Host>AWS</m:Host>
 		<m:User>admin</m:User>
 		<m:Password>p8ilR6N9</m:Password>
 		</m:CreateDBRequest>
 	</soap:Body>
 </soap:Envelope>
```

Listing 4: SOAP message created with the SOAP/HTTP plugin

Listing 5 shows the answer of the implementation artifact.
In this example on the query to create a database the address of the database is returned as response.

```xml
 <soap:Envelope
 xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
 soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 	<soap:Body>
 		<CreateDBResponse>
 			<URL>http://s3.amazonaws.com/my-5GB-DB</URL>
 		</CreateDBResponse>
 	</soap:Body>
 </soap:Envelope>
```
Listing 5: Response of the implementation artifact

Figure 9 shows the exchange message from the SI engine and forwarded from there to the service invocation SOAP API.
The body contains the information received from the implementation artifact which has been encoded as a HashMap by the SOAP plugin.
To do this in the incoming SOAP message the name of the element is assigned as key and the content of the element as value.
It is assumed that the names of the elements returned by the implementation artifact is identical to the return values specified by the TOSCA definition.

![R𣫧abe des SI-Plug-ins mit enthaltenen Informationen des Implementation Artifacts](graphics/ServiceInvoker/ReturnFromSiPlugin.png)

Figure 9: Return of the SI plugin with the received information of the implementation artifact

The service invocation SOAP API (see [SISOAP API](#service-invocation-soap-api)) takes the body of the exchange message and the MessageID from the header for the SOAP message directed at the plan (see Listing 6).
The HashMap with the returned data of the invoked implementation artifact contained in the body is converted as follows: The key-value pairs of the HashMap are pairwise transferred as key and value elements of the SOAP message (see Listing 6).
The plan receives a uniform answer which is consistent with the parameters specified in TOSCA and is independent of the technology of the invoked implementation artifact.
Because the invocation of the service invocation interface is done through the parameters specified in TOSCA, this results in a generic and uniform interface for the invoker to invoke services.
A plan to invoke an implementation artifact only requires the information specified in TOSCA und does not have to know anything about its implementation.

Finally the created SOAP message that was passed in the beginning from the plan to the service invocation interface is sent to the address (ReplyTo) in the header.

```xml
 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.
 									org/soap/envelope/" xmlns:
 									sch="http://siserver.
 									org/schema">
 	<soapenv:Header/>
 	<soapenv:Body>
 		<sch:invokeResponse>
 			<MessageID>A7ZD70AH</MessageID>
 			<Params>
 				<Key>URL</Key>
 				<Value>http://s3.amazonaws.com/my-5GB-DB</Value>
 			</Params>
		</sch:invokeResponse>
 	</soapenv:Body>
 </soapenv:Envelope>
```
Listing 6: Message from the SOAP API back to the invoker

Until now the concept of the service invocation interface has only been explained with the service invocation SOAP API and SOAP/HTTP SI plugin.
That this concept of the service invocation interface offers much more options is explained in the following paragraph.

Figure 10 shows the option to realise an OSGi plugin.
This plugin enables the invocation of implementation artifacts implemented as OSGi services.
It should be noted that the OpenTOSCA container currently, because a suitable IA plugin is as of yet missing, is not yet able to deploy OSGi implementation artifacts, those are therefore not yet supported by the container.
The service invocation interface was implemented with further implementation of artifact types in mind and has concepts in store to deal with those.

![Beispiel f𲠤ie Umsetzungsm򧬩chkeit eines weiteren Plug-in Types](graphics/ServiceInvoker/UsecaseOtherPluginType.png)

Figure 10: Example for the possibilities of more plugin types

The OSGi plugin uses, equivalent to the SI engine and its plugins, the option of declarative services provided by OSGi.
This means that OSGi implementation artifacts implement a set interface and have to offer it as a service.
This is required for the implementation of declarative services, also enables adding and starting implementation artifacts during the runtime.
Based on the implemented interface and the so specified service the OSGi SI plugin can bind and use the OSGi implementation artifact.
The endpoint of the implementation artifact in this case has to be the ID of the respective OSGi service.
Listing 7 shows the methods set by the interface.

```java
 public void invoke(String operationName, HashMap<String,
 					  String> params);

 public Object invoke(String operationName, HashMap<String,
						String> params);

 public getID();
```
Listing 7: Methods of the OSGi implementation artifact interface

The two invoke methods are necessary to realise the two MEPs request-response and one-way.
The method getID is used during the binding of the OSGi implementation artifact to get its ID and save it.
The SI plugin can then choose and invoke the correct OSGi service based on the endpoint.

As mentioned earlier it is also possible to extend the service invocation interface with further service invocation APIs.
This makes it possible to make the functionality of the service invocation interface available to more technologies.
The addition of further service invocation APIs can, equivalent to the plugins, be done during the runtime.

Figure 11 shows the service invocation interface exemplary running on service invocation SOAP as well as service invocation REST API.
As the names of the APIs suggest, this makes it possible to invoke the service invocation interface and therefore the invocation of implementation artifacts and plans with SOAP and REST at the same time.

![Beispiel f𲠥ine weitere Service Invocation API](graphics/ServiceInvoker/MoreServiceInvocationApi.png)

Figure 11: Example of a further service invocation API

In the scope of this bachelor thesis implemented components of the service invocation interface will be presented in the following chapter.

## Implementation

In this chapter the implementation of the service invocation interface and its components is explained.
The Enum to specify the headers of the exchange message is presented first.
Followed by the service invocation API for SOAP and OSGi events.
Lastly the SI engine is explained with a closer look at the SI plugins and the interface.

### Service Invocation Enum

This section illustrates the SI Enum.
It is used to pass the parameters required for a implementation artifact or plan in a specified way.

Listing 8 shows the set SI enum and the so defined values.
The values serve as the key for the key/value pairs in the header.
This enables the components of the service invocation interface to read out parameters.
CSARID serves as identifier of the correct CSAR file.
SERVICEINSTANCEID_STRING is required if data is to be retrieved with the instance data service and is used to determine the instance.
If present NODEINSTANCEID_STRING is used to transmit the ID of a specific instance.
This value is not used by the SI engine to recall instance data with the instance data service but is passed as a parameter to a implementation artifact.
The implementation artifact gets the required data itself with the instance data service.
SERVICETEMPLATEID_QNAME serves to determine the service template of a TOSCA definition.
Equivalently NODETEMPLATEID_STRING determines the node template.
OPERATIONNAME_STRING specifies the operation to be invoked of the implementation artifact or plan.
If the operation name is not unique within a node type the name of the interface has to be specified as well.
This is done with the INTERFACENAME_STRING.
PLANID_QNAME is used if a plan is to be invoked and serves to identify the plan.

```java
public enum SIEnum {
CSARID, SERVICEINSTANCEID_STRING, NODEINSTANCEID_STRING, SERVICETEMPLATEID_QNAME, NODETEMPLATEID_STRING,
INTERFACENAME_STRING, OPERATIONNAME_STRING, PLANID_QNAME, ENDPOINT_URI, SPECIFICCONTENT_DOCUMENT
}
```
Listing 8: SI-Enum

All values mentioned so far are already being passed to the SI engine from the respective service invocation API.
Only the values of ENDPOINT_URI and if applicable SPECIFICCONTENT_DOCUMENT are set by the SI engine.
ENDPOINT_URI is determined with the endpoint service and specifies the endpoint of an implementation artifact or plan.
SPECIFICCONTENT_DOCUMENT is determined with the TOSCA engine (if specified in the TOSCA definition) and can contain important information for the plugin, like for example information about the mapping of the parameters (see [Service Invocation REST/HTTP plugin](#service-invocation-resthttp-plugin)).

### Service Invocation SOAP API

In this chapter the service invocation SOAP API to invoke the service invocation interface with SOAP messages is explained.
Also more details on the usage of Camel.

Listing 9 shows conceptually the implemented route and its endpoints of the service invocation SOAP API.
The strings defined in rows one to 16 INVOKE, CALLBACK, ENGINE_AI and ENGINE_PLAN represent the endpoints of the route.
The route itself is defined in rows 17 to 22.

The string INVOKE, rows one to six, serves as endpoint to invoke the service invocation SOAP API.
With it a SOAP web services is started on http://localhost:8081/invoker per CXF component.
The invoker.wsdl serves as WSDL of the web service.
The service and port are defined by the WSDL.

```java
 String INVOKE = "cxf:http://localhost:
                  8081/invoker?wsdlURL=META-INF/invoker.
                  wsdl&serviceName={http://siserver.org/wsdl}
                  SIServerInvokeService&portName={http:
                  //siserver.org/wsdl}
                  SIServerInvokePort";

 String CALLBACK = "cxf:${header[ReplyTo]}?wsdlURL=META-
                  INF/invoker.wsdl&serviceName={http:
                  //siserver.org/wsdl}
                   SIServerCallback&portName={http://siserver.
                  org/wsdl}CallbackPort";

 String ENGINE_IA = "bean:siengineinterface.
                  SIEngineInterface?method=invokeOperation";

 String ENGINE_PLAN = "bean:siengineinterface.
                  SIEngineInterface?method=invokePlan";

 from(INVOKE).unmarshal(requestJaxb).process(requestProcessor)
       .choice().when(this.header(CxfConstants.OPERATION_NAME).
      isEqualTo("invokeOperation")).to(ENGINE_IA).when(this.header(
      CxfConstants.OPERATION_NAME).isEqualTo("invokePlan")).
      to(ENGINE_PLAN).end().process(responseProcessor).
      marshal(responseJaxb).recipientList(this.simple(CALLBACK));
```

Listing 9: Route of the Service Invocation SOAP API

The string CALLBACK defines the endpoint required for asynchronous invocations to send reply messages to the invoker.
This also uses the CXF component as well as the invoker.wsdl.
The respective service and port is also given.
The address where the SOAP message should be sent is determined dynamically.
${header[ReplyTo]} means the value of ReplyTo from the header of the exchange message should be read and used as address for the response message.
This value has to be transmitted by the invoker at the time of invocation of the service invocation SOAP API.
The service invocation SOAP API supports the transfer, as shown in Listing 3 as parameter in the body or as WS addressing header.
Correspondingly the MessageID can be transmitted with both methods.

In rows 12 and 13, as well as 14 and 15 the two methods of the SI engine are set as endpoints.
One endpoint to invoke implementation artifacts (ENGINE_IA) and one endpoint to invoke plans (ENGINE_PLAN).

Rows 16 to 21 show the route that is processed after an invocation.
From(INVOKE) defines the INVOKE endpoint as entry point of the route.
The SOAP message of an invocation is unmarshalled (unmarshal(requestJaxb)) and then processed in requestProcessor.
During processing all parameters defined with the SI enum as well as all headers from the SOAP message are applied as header of the exchange message.
Then the header OPERATION_NAME is read and used to determine if an implementation artifact or plan should be invoked and accordingly the method of the SI engine is invoked (ENGINE_IA or ENGINE_PLAN).
After the SI engine or respectively a suitable plugin has executed the invocation and the exchange message with the reply from the implementation artifact or plan has been returned to the service invocation SOAP API, this is processed again (process(responseProcessor).
The reply is read from the body of the exchange message and, if possible, converted into a marshallable object.
Subsequently the response object is marshalled and sent as SOAP message to the CALLBACK endpoint.

###  Service Invocation OSGi event API

This chapter presents the implementation of the service invocation OSGi event API.
Special focus lies on the general functionality of OSGi events and the collaboration with the plan invocation engine.

The service invocation OSGi event API enables the usage of the service invocation interface with the OSGi event admin service.
With the OSGi event admin services events can be sent and received with the **publish and subscribe** pattern.
This technology enables asynchronous communication between the service invocation interface and for example the plan invocation engine.

Figure 12 shows the service invocation interface with service invocation OSGi event API and plan invocation engine.
Furthermore the function of the publish and subscribe pattern is shown.
The plan invocation engine sends the message enriched with the required information to a list (Request Topic).
The service invocation OSGi event API receives the message, because it is subscribed to this list, and can process it further.
Transmitted information like CSAR ID or plan ID, familiar from the service invocation SOAP API, are set as header and the transmitted payload as body of an exchange message object.
The payload can be for example a HashMap with parameters as key/value pairs, or as is the case with the plan invocation engine be of the type org.w3c.com.Document.
Subsequently the exchange message is passed to the SI engine to be processed further.
After the response from the SI engine returns, the service invocation OSGi event API sends the response message to more lists (Response Topic).
The plan invocation engine is subscribed to this list and can so receive the response messages and process them.

![Aufruf eines Plans initiiert durch Plan Invocation Engine](graphics/ServiceInvoker/PlanInvocationWithPlanInvocationEngine.png)

Figure 12: Invocation of a plan initiated with the plan invocation engine

Listing 10 shows based on the service invocation OSGi event API how OSGi event services are used.
First, like in every OSGi XML configuration file (Component Description), the name (row two to four) and the class (row five and six) of the respective component are set.
The EventAdmin service has to be bound so that the components can send events to lists (rows seven to eleven).
bindEventAdmin (row seven) sets the method to bind the service and has to be present in org.opentosca.siengine.api.osgievent.SIEventHandler, the class specified in rows five and six and implemented correspondingly.
Rows twelve to fifteen specify that the class mentioned above offers the service EventHandler.
The class has to implement the interface EventHandler and the corresponding method to receive events handleEvent(Event event).
The names of the lists (event.topics) the component is subscribed to have to be specified.
In this example this is the list org_opentosca_plans/request which is used for example by the plan invocation engine to send query for the invocation of plans.

```xml
 <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.
 							0" immediate="false" name="org.
							opentosca.siengine.api.osgievent.
							SIEventHandler">
 	<implementation class="org.opentosca.siengine.api.
 						 osgievent.SIEventHandler"/>
 	<reference bind="bindEventAdmin" cardinality="1..1"
 					interface="org.osgi.service.event.
 					EventAdmin" name="EventAdmin"
 					policy="static"
 					unbind="unbindEventAdmin"/>
 	<service>
 		<provide interface="org.osgi.service.event.
 							EventHandler"/>
 	</service>
 	<property name="event.topics" type="String"
 					value="org_opentosca_plans/requests"/>
 </scr:component>
```

Listing 10: Usage of the OSGi event service

Equivalently the plan invocation engine is subscribes to the list org_opentosca_plans/responsnes, which is used to send the responses messages with the service invocation OSGi event API.
The sending of an event is done with the method postEvent(Event event) offered by the EventAdmin service.

### Service Invocation Engine

In this section the implementation of the SI engine is presented.
The focus lies on the methods offered by the SI engine and the system to administrate the SI plugins.

The SI engine provides two methods.
First InvokeOperation(Exchange exchange) to invoke implementation artifacts and second invokePlan(Exchange exchange) to invoke plans.
Although implementation artifacts and plans can be viewed as services the queries for their invocation has to be handled differently.
Figure 13 illustrates the processes of both methods.

Identical in both methods is that they have the read the headers relevant for them from the exchange message.
In the case of invokeOperation this would be the values CSARID, SERVICEINSTANCEID_STRING, NODEINSTANCEID_STRING, SERVICETEMPLATEID_QNAME, NODETEMPLATEID_STRING, INTERFACENAME_STRING and OPERATIONNAME_STRING.
In the case of invokePlan CSARID, SERVICEINSTANCEID_STRING, NODETEMPLATEID_STRING and PLANID_QNAME.
Subsequently, if invokeOperation was called, the TOSCA engine is used to determine a suitable implementation artifact, its message exchange pattern and the corresponding properties.
The corresponding sequence diagram (Figure 12) was already presented before.
The query for instance data, if a ServiceInstanceID is available and a HashMap as payload happens in both cases.
If the method was invokeOperation it is also checked if a NodeInstanceID was specified.
If this is the case and the Payload is in form of a HashMap the NodeInstanceID is taken in as parameter of the HashMap.
This enables implementation artifacts to determine current values from the instance data themselves.
Independently of the two methods the respective endpoint of the implementation artifact or plan is determined with the endpoint service.
For the invocation of implantation artifacts the invocation type of a suitable plugin is determined with the properties queried earlier.

![Flussdiagramme der beiden SI-Engine Methoden invokeOperation und invokePlan](graphics/ServiceInvoker/FlowchartInvokeoperationInvokeplan.png)

Figure 13: Workflow diagram of both SI engine methods invokeOperation and invokePlan

If a plan is invoked the exchange message is directly passed to the SOAP plugin (see [Service Invocation SOAP/HTTP plugin](#service-invocation-soaphttp-plugin)) because the OpenTOSCA container so far only supports BPEL plans.
If more plan types are supported in the future the invocation type and therefore the choice of plugin has to be determined based on the management plan language.

Listing 11 shows how the invocation type of an implementation artifact is specified within the TOSCA definition.
The option to define properties (row three to twelve) provided by the artifact templates is used for this.
The rows eight to ten in this example are relevant for the service invocation interface.
With the InvocationType element the invocation type of the implementation artifact is set.
In this case SOAP/HTTP.
The SI engine would then forward this request for the invocation of this implementation artifact to a plugin that can handle SOAP/HTTP.

```xml
<p:ArtifactTemplate id="EC2VMService" type="toscatypes:
                    WAR">
    <p:Properties>
        <opentosca:WSProperties>
            <opentosca:ServiceEndpoint>
                    /services/EC2VMIAService
            </opentosca:ServiceEndpoint>
            <opentosca:InvocationType>
                    SOAP/HTTP
            </opentosca:InvocationType>
        </opentosca:WSProperties>
    </p:Properties>
    <p:ArtifactReferences>
        <p:ArtifactReference reference=
                "IAs/EC2VMService/EC2-VM-Service.war" />
    </p:ArtifactReferences>
</p:ArtifactTemplate>
```

Listing 11: Example ArtifactTemplate with invocation type specification

Furthermore another property (ServiceEndpoint) is defined in Listing 11.
This is used by the IA engine to determine the correct endpoint of the implementation artifact.
This ensures that the IA engine stores an endpoint with the endpoint service that is usable by the service invocation interface.

An important requirement on the service invocation interface is the option that the spectrum of invocation types can be extended.
This is achieved with a plugin system, which is now explained in more detail.

The plugin system is realized with declarative services.
The SI plugins implement the specified interface SIPluginInterface (see [SI Plugin Interface](#service-invocation-plugin-interface)) and respectively provide the service ISIEnginePluginService.
This is shown in rows four and five in Listing 12.

```xml
 <scr:component ...>
 	<implementation class= .../>
 	<service>
 		<provide interface="org.opentosca.siengine.plugins.
 							service.ISIEnginePluginService"/>
 	</service>
 </scr:component>
```
Listing 12: Providing a service per OSGi XML configuration file
```xml
 <scr:component ...>
 	<implementation class= .../>
 	<reference bind="bindPluginService" cardinality="0..n"
 					interface="org.opentosca.siengine.plugins.
 					service.ISIEnginePluginService"
 					name="SIPluginInterface" policy="dynamic"
 					unbind="unbindPluginService"/>
 </scr:component>
```
Listing 13: Binding a service per OSGi XML configuration file

Because the SI engine binds all these services (see Listing 13, rows three to seven), during the start of an SI plugin the SI engine automatically calls a method to bind this plugin.
In this example the method is called bindPluginService (see row 3 in Listing 13).

Furthermore the SI plugins have a method getType(), specified with the interface, which returns the invocation type as string.
This method is called by the SI engine when a plugin is bound and the return value (the invocation typ) together with the respective plugin is stored in a map (see Listing 14, rows three to six).
Row one and two show the map to administrate the SI plugins.
The key is the invocation type and the value is the plugin.
During the stopping of a plugin the unbind method is executed and the plugin is removed from the map (row 8 to eleven).
Because of this system the SI engine always has a current list of available SI plugins and can choose a suitable plugin based on the invocation type of the implementation artifact.

```java
 Map<String, ISIEnginePluginService> pluginServicesMap = Collections.
 synchronizedMap(new HashMap<String, ISIEnginePluginService >());

// . . .

 public void bindPluginService(ISIEnginePluginService plugin) {

 		pluginServicesMap.put(plugin.getType(), plugin);
 }

 public void unbindPluginService(ISIEnginePluginService plugin) {

 		pluginServicesMap.remove(plugin.getType());
 }
```

Listing 14: Implementation of the plugin system

## Service Invocation Plugin Interface

This chapter presents the interface for the SI plugins.
As mentioned earlier all plugins usable by the service invocation interface have to implement this interface and provide the service ISIEnginePluginService.

```java
 public interface ISIEnginePluginService {

    Exchange invoke(Exchange exchange);

    String getType();
}
```
Listing 15: Interface of the SI plugins

Listing 15 shows the interface specified for the SI plugins.
The interface defines two methods.
The method getType() explained earlier, that retrieves the supported invocation type of a plugin, and the method invoke(Exchange exchange) to transmit the exchange message to the SI plugins.
The invoke method returns the exchange message, with which it was called, together with the response message of the invoked implementation artifact or plan as return value in the body.

### Service Invocation SOAP/HTTP plugin

This chapter presents an implementation of the SI plugin interface.
Specifically it presents a SOAP/HTTP plugin, meaning a SI plugin that can invoke implementation artifacts and plans with a SOAP message via HTTP.

After the invocation of the invoke method and the transmission of the exchange message through the SI engine, the SOAP/HTTP plugin reads the endpoint of the implementation artifact or plan from the header.
Endpoints can differ depending on the required plugin.
In the case of the SOAP/HTTP plugin the endpoint has to either point directly to the WSDL definition of the implementation artifact or plan, or has to achieve this by attaching "?wsdl".
If for example the WSDL definition of an to be invoked implementation artifact is available under the address http://localhost:8080/EC2IA/services/EC2Service?wsdl either this address or this one http://localhost:8080/EC2IA/services/EC2Service has to be provided as endpoint.
This is necessary because the WSDL definition describes the interface to invoke the webservice and the information contained to create and send the invocation message and therefore the plugin has to read it.
The MEP is detzermined like this for example, or if a HashMap is transmitted with the input parameters as body of the exchange message, the WSDL definition is used to generate a correct SOAP message from it.

The SOAP/HTTP plugin supports in the current implementation three exchange types of messages.
Those will be explained in the following paragraph and Figure 14.

**One-Way (In-Only)**: The service is called with a SOAP message, does not send a response message.
Listing 16 shows an exemplary One-Way operation in a WSDL definition.

```
01 	<wsdl:operation name="one-wayOperation">
02 		<wsdl:input message="tns:inputMessage">
03 		</wsdl:input>
04 	</wsdl:operation>
```

Listing 16: One-Way Operation

**Request-Response (In-Out)**:  The client (the plugin) sends a SOAP message to the service and waits for the response message.
An example of a request response operation is in shown in Listing 17.

```xml
<wsdl:operation name="request-responseOperation">
    <wsdl:input message="tns:requestMessage">
    </wsdl:input>
    <wsdl:output message="tns:responseMessage">
    </wsdl:output>
</wsdl:operation>
```

Listing 17: Request-Response operation

**Request-Callback (asynchronous Request-Response)**: The client sends a SOAP message to the service, does not require a immediate response.
Instead it is informed when the response from the service arrives.
The service has to be given an address for the callback and a MessageID.
The MessageID has to be contained in the response message of the service, so that a correlation between the invocation message and the response message is possible.

The SOAP/HTTP plugin enables the transmission of callback addresses and MessageIDs as parameters in the SOAP body of the message and with WS addressing header.
The request callback however is realized from the WSDLs point of view as two one way operations and is not specified by the WDSL definition alone.
To finally determine the information gotten from the WSDL additional MEPs from the TOSCA definition have to be used.
Accordingly an In-Only operation (from the TOSCA definition) and an In-Only operation (from the WSDL definition) make a One-Way SOAP message (without response message) to the service.
In contrast an In-Out operation (from the TOSCA definition) and an In-Only operation (from the WSDL definition) make a message exchange through request callbacks.

![Darstellung der drei von dem SOAP/HTTP-Plug-in unterst𴺴en MEPs](graphics/ServiceInvoker/SupportedMeps.png)

Figure 14: Presentation of the three MEPs supported by the SOAP/HTTP plugin

### Service Invocation REST/HTTP plugin

This section explains the implementation of the REST/HTTP plugin.
Special focus lies on how mapping information of the passed parameters can be specified in the TOSCA definition.

HTTP allows the passing of parameters inside the URL (query string) as well as in the message body.
To enable the plugin to create the message according to the implementation of the implementation artifact, information about the mapping of the parameters can be given in the TOSCA definition.
This information is determined in the SI engine with the TOSCA engine and passed to the plugin.
Listing 18 shows the schema to describe mapping information, which have to be defined inside the implementation artifact (as artifact specific content).

```xml
<DataAssign>
    <Operations>
        <Operation name="String" ?
                    interfaceName="String" ?
                    endpoint="no | yes" ?
                    params="queryString | payload" ?
                    contentType="urlencoded | xml" ?
                    method="POST | GET" ? >
        </Operation> +
    </Operations>
</DataAssign>
```

Listing 18: Schema to describe the parameter mapping

Implementation artifacts implement the interfaces and operations offered by a NodeType.
Because an implementation artifact can implement a single operation of an interface, all operations of an interface, or all interfaces with their operations the attributes name and interfaceName are required.
They specify for which operations the respective mapping information is valid.
If the implementation artifact only implements a single operation name and interfaceName are not required.
Similarly the interfaceName is only required if the implementation artifact implements multiple interfaces.
The endpoint attribute specifies that the name of the operation and the interface are to be attached (with / as separator) to the endpoint received from the endpoint service.
The params attribute specifies if the parameter should be transmitted as part of the URL (queryString) or in the body (payload).
If it is part of the body the content type can be specified.
Currently the two content types application/x-www-form-urlencoded (urlencoded) as well as application/xml (xml) are supported.
The required HTTP method (GET or POST) can be specified with method-Attribute.

Additionally to the mapping information the plugin has its own assumptions or rather requirements on the structure of a message.
For example if the parameter is passed as a query string the key value pairs are separated with & and the key value values are separated with =.
The first key value pair is appended a ? to separate tge endpoint from the parameters.
Listing 19 shows an example of the specification for such a mapping definition and the resulting query.
Identical (with & and = as separators) the parameters are encoded in the body if they are passed urlencoded.
For the passing with XML the parameters are converted as follows: The names of the parameters become elements with the value of the respective parameter as content.
The name of the operation is used as root element.
Listing 20 shows an example for this.

```
<DataAssign>
	<Operations>
		<Operation name="createDB"
					endpoint="yes"
					params="queryString"
					method="GET" >
		</Operation>
	</Operations>
</DataAssign>

GET /DB/services/DBCreator/createDB?Size=5&Host=AWS&User=
		admin&Password=p8ilR6N9 HTTP/1.1
Host: localhost:8080

...
```
Listing 19: Example for the parameter passing with query string

```
<DataAssign>
	<Operations>
		<Operation name="createDB"
				params="payload"
				contentType="xml" >
		</Operation>
	</Operations>
</DataAssign>

POST /DB/services/DBCreator HTTP/1.1
Host: localhost:8080

...

<createDB>
	<Size>5</Size >
	<Host>AWS</Host >
	<User>admin</User >
	<Password>p8ilR6N9</Password >
</createDB>
```

Listing 20: Example for the parameter passing as content type xml

In the future it could be possible to use web application description language (WADL), equivalent to WSDL in the SOAP plugin, to acquire required information.
But because it is rarely used and is much more complex this prototype implementation of the plugin has its own, specifically created schema to specify information.

# Assumptions

Some assumptions have to be made and requirements put on the creators of TOSCA definitions and plugin developers (of the service invocation interface) so that the concept and the implementation based on it can work correctly.
These are explained in this chapter.

**Accuracy of the passed parameters**
The parameters passed to the service invocation interface can be put in two groups.
On one hand the data required to determine the implementation artifact or plan and on the other hand the data required to invoke the implementation artifact or plan.

The parameters passed to the service invocation interface to determine a fitting implementation artifact or plan, have to be correct and known within the OpenTSCA container.
Known within the OpenTOSCA container means, that this data, like for example the CSARID or ServiceTemplateID has to be invokable with the TOSCA engine and therefore exist as Java objects.
If this is not the case required information like the name of the implementation artifact and so the its endpoint cannot be determined and the invocation cannot be made.

The input parameters required for the invocation of the implementation artifact plan have to correspond to the parameters specified by the implementation artifact or plan.
This means that the names and the number (after additional parameters like instance data has been added) of passed parameters have to be identical.
The operations to be executed also have to match with the implementation artifacts or plans as well as their input parameters.
If an operation is present in different interfaces of one NodeType the name of the interface has be specified as well.
If this is not specified it is assumed that the operation is unique within the NodeType and the implementation artifact is determined only with that.

**Existence of an endpoint**

Without information under which name or which address a specific implementation artifact is reachable it cannot be invoked.
Therefore implementation artifacts deployed with the IA engine or rather its plugins, or similarly deployed plans, have to have a correct endpoint, stored with the endpoint service.

These endpoints can differ based on the type of implementation artifact.
The endpoint of a SOAP web service implementation artifact would be saved as a URL which specifies the address to the WSDL file of the SOAP web service.
The endpoint of an OSGi service implementation artifact would be represented with the ID of this OSGi service.
The different plugins of the service invocation interface know how to interpret the different endpoints.

The deployed implementation artifacts and plans (for invocations) have to be available from the OpenTOSCA container environment.

**Usage of specified interfaces**
New, to be developed SI plugins, have to implement the interface specified by the existing plugin.
This is necessary to ensure correct functionality of the plugin system based on OSGi.

Furthermore the invocation types, which are used to identify plugins, have to differ from each other.

For the concept of the OSGi plugin the implementation artifacts have to implement this interface as well.

**Required information within the TOSCA definition**

Required information, like for example the invocation type of an implementation artifact, has to be specified in the TOSCA definition.
This information is used by the service invocation interface among other things to determine a suitable SI plugin.
Without this data no suitable plugin can be found and the invocation of the implementation artifact fails.

The optional input and output values of the NodeType operations to determine the message exchange pattern (MEP) have to be specified as well.
If they are not specified request-response is assumed.

**Usage of the Enum**

The SI enum explained in 4.4.1 is required for the exchange of the required information.
It defines the header of the exchange message and so ensures a standardised format.

New service invocation APIs have to use this enum, equivalently to the existing service invocation SOAP API.
Otherwise the SI engine cannot read the information and the invocation of the implementation artifact of plan can not be executed.

redpajama_set_name: RedPajamaGithub


Jesus Lopez summed up the collective feelings of the Glenbard East wrestling team as the awards ceremony wound down Saturday afternoon at the Newbill Invitational in Geneva.
"We champed out," the Rams' victorious 220-pounder said.
Lopez and fellow seniors Alex Posada, who checks in at 145 pounds, and 195-pounder Ben Pham all defended individual championships at the 20-team tournament.
Reese Martin, who had to settle for third last year, began the Rams' complete sweep in their four championship matches with a dominant first period in an 11-6 victory over Wheaton Warrenville South sophomore Aidan Waszak at 120 pounds.
Even more important, Glenbard East defended its team title with a convincing 176-152.5 victory over (Woodstock) Marian.
Addison Trail had three finalists, including a pair of champions, in placing third with 141 points.
WW South, fourth at 124, and West Aurora, fifth with 113.5 points, each had an athlete ascend to the top of podium.
Dundee-Crown edged the host Vikings by a point as the two teams finished out of the top 10.
"This is great, especially since we lost (our) dual with Marian Central," Lopez said.
The Tigers' Waszak was looking to even his season series with Martin after the latter won by pin in the schools' nonconference dual meet.
But Martin, a returning state qualifier, had a pair of takedowns and an equal number of near-falls in the opening period to score 9 of his 11 points in the match.
Posada is also a returning state qualifier for the Rams who is currently wrestling through a partially torn kneecap.
"I just try to do my best and to get back to where I was," said Posada, who defeated Stillman Valley junior Logan Lagerhausen 7-5 in the final. "I'm limited. We usually have two (dual) meets a week. I wrestle in one and take the other off."
Pham also had a second regular-season encounter as he literally reversed West Aurora sophomore Dzhabrail Khurshidov for a 4-3 victory.
Khurshidov had taken a 3-2 lead with his own reversal with 56 seconds remaining in the final period.
"I didn't think he had the reversal," Pham said of his Upstate Eight Conference rival. "I wasn't panicking. I knew I was in control."
"I was surprised the ref gave me the 2 points," Khurshidov said. "I didn't want to get hit with locked hands (a penalty), so I didn't have a good grip."
Addison Trail senior Guillermo Juarez kicked off the finals by claiming a second straight Newbill championship over Marian freshman Josh Glover.
The Blazers' senior prevailed in a 11-9 nail-biter.
"I have had a few bumps this season," said Jaurez, who had a technical fall and pin to reach the finals. "I have proved that I am still one of the best wrestlers in the state."
Patience is often a must in an invitational showdown.
Addison Trail sophomore Jake Matthews' 4-0 whitewashing of Marian junior Daniel Valeria was achieved with a second-period reversal and takedown in the third.
"I kept my composure," Matthews said. "I kept my pace. I thought he might be gassed. I have a pretty large gas tank to go through."
The Blazers' Nick Skamra fell in the 182-pound final.
WW South senior Dominic Duve emerged victorious at 126 pounds with the only offensive points of the final -- a pair of takedowns -- in his 5-3 win over Alton junior Garrett Sims.
"(The difference) was all about the mentality," Duve said. "It all comes down to practice. My coaches, teammates and parents (David and Heather) told me I had to believe in myself."
West Aurora is renowned for its multicultural student body.
Runner-up Khurshidov emigrated to Aurora from Russia.
But the Blackhawks' crowning achievement came from heavyweight Abbas Abdulkadhim.
Born in the war-ravaged Middle East to an Iraqi father and Iranian mother, Abdulkadhim had three falls and a 14-13 dogfight in claiming the lone West Aurora championship at 285 pounds.
Abdulkadhim needed barely more than 60 seconds to vanquish Champaign Centennial junior Lavell Fleming.
"This is the biggest thing I have ever won in wrestling," the Blackhawks' senior said. "It was just my mindset. (The takedown and pin move) was an overhook-underhook and then just a trip."
Dundee-Crown and Geneva were both short-handed in finishing in the No. 12 and tied for 13 slot.
The Chargers were paced by Colin Mayes and Carter Fitch with their fourth-place finishes at 152 and 195, respectively.
D-C junior Gabriel Scales' 32nd win on the year in the fifth-place match at 138 pounds leads the team.
Ian Heck and Hank Smith both won third-place matches for Geneva.
"I did better than I expected to do," said Smith, a 182-pound junior. "I am real happy with how I performed."
Huck prevailed for the major-consolation title at 120 pounds.


All languages of subtitles for Wild Wild West movie at Justsubtitles.com.
Subtitle for movie Wild Wild West are avaliable in these languages, select preferred language by flag bellow.
Secrets, lies, unspoken truths... there's no place like home.
Or you can search more related Wild Wild West subtitles for free download.
Do you find subtitles ? You can find more Wild Wild West subtitles at Justsubtitles.com search engine.


Thank you to everyone who entered and congrats to the winner! Be sure to check out High Gloss Fashion to see all their new inventory. Keep your eyes peeled or subscribe to the Adored Austin newsletter for a very special 50% off High Gloss Fashion flash sale soon.


text:
Brockton has quarantine site for first responders on front lines of coronavirus fight
Marc Larocque Enterprise Staff Writer @Enterprise_Marc
Apr 9, 2020 at 5:50 PM Apr 9, 2020 at 5:51 PM
Brockton Mayor Robert Sullivan said the gymnasium at North Middle School has been designated as a site for first responders on the front lines of the coronavirus fight.
BROCKTON – What if a first responder from Brockton who has been exposed to the coronavirus wants a place to stay away from their family?
Where can they go?
Brockton Mayor Robert Sullivan said the city designated the gymnasium at North Middle School as a place for firefighters, police officers and other city employees on the front lines of the coronavirus fight to isolate themselves and sleep each night. The isolation center was established recently by the Brockton Emergency Management Agency, Sullivan said.
We can deliver news just like this directly to your inbox. You can sign up for This Just In (a daily 7:30 p.m. newsletter with items we've posted that day), News Alerts (so you don't miss anything important) and more. It's customized to your preferences -- and it'll only take a few seconds.
However, as of this week, nobody has taken the city up on the offer, the Brockton mayor said.
"We have cots set up in the gymnasium. We do have it operational if need be, if people choose not to go to their homes," said Sullivan, during an interview with the Enterprise on Tuesday. "No one is using it as of yet. "
(Editor's note: This content is being provided for free as a public service to our readers during the coronavirus outbreak. Please support local journalism by subscribing to The Enterprise.)
Sullivan said he has a weekly phone call with unions representing the firefighters, police officers and others on the front lines, and wanted to make sure they have a place to go outside of their homes.
"I think most people if they are indeed confirmed or highly likely (to have the coronavirus), they would opt to go into confines of their own home," Sullivan said.
If the city would ever require additional quarantine space, the Brockton High School gymnasium is available, Sullivan said.
"That has showers, and all the facilities if need be," Sullivan said. "We already have the places picked out if need be. As of yet, we haven't needed to utilize those for city employees."

redpajama_set_name: RedPajamaCommonCrawl


text:
Cesc Fabregas: Arsenal need FA Cup final win more than Chelsea FC
Cesc Fabregas discusses Arsenal's FA Cup final clash with Chelsea FC at Wembley on Saturday afternoon
By The Sport Review
Saturday 1 August 2020, 04:50 UK
Mikel Arteta (Photo: YouTube)
Cesc Fabregas has claimed that Arsenal "need" a win over Chelsea FC in the FA Cup final on Saturday more than the Blues do.
The north London side head into Saturday's showdown at Wembley looking to end the season on a positive note under Mikel Arteta.
The Gunners have shown some signs of improvement under their new boss in recent weeks but they have still struggled to find consistent form in the league all season as they ended up in eighth place in the Premier League table.
Chelsea FC, meanwhile, head into Saturday's game fresh from having secured their place in the Champions League for next season thanks to a fourth-placed finish in Frank Lampard's first campaign in charge.
Fabregas, who played for both London clubs, feels that a win in the FA Cup final would be more important for Arsenal, as both Arteta and Lampard look to win their first major trophies as managers.
Speaking in an interview with the Daily Telegraph, Fabregas said of Saturday's game: "Arsenal need it more.
"Chelsea basically every year has won a trophy, so it's a different animal in this case.
"In terms of trophies, Arsenal needs it more and for confidence for next year and getting into Europe.
"Chelsea are in the Champions League and Arsenal has nothing at the moment."
Arsenal last lifted the FA Cup trophy back in 2017, when they beat Antonio Conte's Chelsea FC side in the final at Wembley under Arsene Wenger.
The north London side have won the FA Cup more than any other team in history, with the Gunners having lifted the trophy a record 13 times before.
MORE: Latest Arsenal news and views
Michael Owen reveals his prediction for Arsenal v Chelsea FC
Pundit admits he 'cannot wait' to see Leeds United in the Premier League


text:
Should You Refrigerate Flour?
Anna Fedorova_it/Shutterstock
By Michelle Welsch/Sept. 25, 2022 1:00 pm EST
First by hand and then by mills, humans have been grinding grain into flour since prehistoric times. Flour production quickly escalated when automatic mills were built in 1784, and novice and professional cooks alike have been dipping into packages of a variety of flours ever since (via How Products are Made).
Most flour is made from wheat kernels. Wheat flour contains gluten, those stretchy, elastic proteins that help create the chewy bread loaves you take out of your oven (via How Products are Made). Different kinds of wheat result in different kinds of flour: hard wheat has more protein and is usually used for bread-making, while soft wheat flour is better suited for cakes, and durum for pasta (via Food Source Information). All-purpose flour is most commonly found in household kitchens, as the blend of hard and soft wheat can be easily incorporated into recipes, but other starchy plants can be made into flour. Almond, amaranth, barley, buckwheat, corn, chickpea, flaxseed, oat, millet, peanut, potato, rice, and spelt flours can also be found in markets (per Food & Nutrition).
Flour is considered a raw agricultural product, according to Food Source Information, and can be enriched, fortified, or bleached. As with all food ingredients, how its stored can impact shelf life.
Fresher flour for longer
Ermolaeva Olga 84/Shutterstock
The goal is to keep flour cool, dry, and protected from small insects called flour weevils. The Flour Advisory Bureau recommends keeping flour in the packaging it came in or placing it in an air-tight container. According to Healthline, white flour can stay fresh for up to one year in the fridge, as compared to six to eight months on the shelf. Whole grain flours, on the other hand, won't stay fresh as long because the oils from the germ and bran in wholemeal flour accelerate the aging process.
To keep flour fresher for longer, Taste of Home suggests storing it in the freezer or refrigerator, especially if you live in a warm, humid environment or don't get around to making as many recipes as you'd like. Then, the next time you want to make a flaky pie crust, Masterclass advises home bakers to let the flour return to room temperature before incorporating it into any recipe — particularly if you're setting out to bake bread — as you want to make sure the flour will rise.


Record of a Spaceborn Few is the latest (but not the last!) in Becky Chambers' Wayfarers series. It follows a handful of humans as they struggle with questions of mortality, community, relationships, home and life beyond the horizons of what we call home.
The lives of the characters interweave loosely in this one, and only touch on the events of the previous two novels, such that initially I found myself hoping characters from the previous books would show up in this new context. But it wasn't long until I fell in love with the new characters as well: as multilayered, flawed and vulnerable as any of Chambers' protagonists.
The story, too, takes place largely on a single space station – a tiny geographic area considering the previous two books literally spanned planets. And it's this limited scale that ironically brings brings home just how expansive and intricate the world of Wayfarers really is. As loosely as the stories told in this book lace into the previous ones, this is unequivocally a Wayfarers novel: it's told in Chambers' earnest, "up-lit" style storytelling that is uplifting but never saccharine, and the scale of the story feels utterly organic.
This scale was one of my favourite things about the book. Rather than culminate in a giant dramatic space gunfight, as is the wont of so many books these days, the conclusion to Record of a Spaceborn Few is much more introspective. The biggest, most violent event in the book occurs in the prologue, and sets in motion expanding ripples of internal development for each of the point of view characters. The individual plot arcs are all internal, and the conflicts grow out of what the characters themselves find important and difficult: human connection, community, home, individual fears rooted in past trauma.
This may be a different kind of storytelling than today's readers are used to, recalling the stories of Ursula le Guin more than, say, Star Wars or Star Trek, but it is, I think, a necessary one. So often the sci fi stories we are told are so wrapped up in large-scale conflicts, wars, ecological disasters, planetary destruction, and so obsessed with glorifying imaginative technology and flashy effects, that we lose sight of the human struggle, the everyday detail and collateral damage of the progress humanity has made in these tales. But these stories, for me, are the more interesting ones.
Record of a Spaceborn Few tells a small story rooted indelibly in a larger world and a collective invented history spanning generations. Chambers once again proves herself a keen student of language and culture, deftly and tenderly portraying the complex and often fraught relationships between her characters, in a book that left me feeling deeply contemplative and ultimately hopeful.


As an American, I've long been curious about exactly how many countries my own country has invaded and been involved with militarily around the world.
How many countries do you think the United States invaded over our history? Thirty? Forty? How many countries do you think we've been involved with militarily. Ninety? A hundred?
A couple of years ago, I read a book called All the Countries We've Ever Invaded: And the Few We Never Got Round To (The History Press, 2012) by a British author, Stuart Laycock, asking the same questions about Britain. His answer was that Britain has invaded or fought conflicts in almost 90 percent of the world's countries. I thoroughly enjoyed his book, and eventually we met for a pint in London, and a friendship blossomed. We decided to team up, using Stuart's passion for world history and my passion for American history to answer the questions about my country that I'd wondered about for so long. This book is the result.
This book is full of interesting historical "tid-bits" which make it a good read. Author Christopher Kelly has taken the time to add the human interest side along with the historical information. Not a dull text book, but rather a great account of how America has been invading, been involved with or occupying almost every country in the world one way or another. I like the format of each country organized alphabetical because it is a quick reference and field guide. I give this book 5 stars.
Obviously, when you set out to write a book like this, you first have to define what you're researching. It's fairly easy to decide what "militarily involved with" means (not a mere posting of US marines to an embassy for security), but what about "invading"?
If satellite reconnaissance counts as an "invasion," then clearly the answer is a very large figure. Ditto for NSA telephone surveillance. If you count American cultural invasions such as Elvis, McDonald's, or Hollywood, for example, we could include nearly every country in the world. That, however, seems a bit of a linguistic stretch.
The nature of what constitutes an invasion has, of course, changed dramatically over the years. The old cry of "Send in the Marines!" could, in the days of cyber-warfare, be replaced by "Send in the nerds!" Should the introduction of a computer virus be considered an invasion?
In the end, we decided to define an "American invasion" as an "armed attack or intervention in a country by American forces." That still leaves a few countries where the question is open to some debate, but by the time we'd finished doing the research, we'd come up with some pretty amazing results.


As you go through the registration process, fill in all your details according to your chosen Business Plan. Describe your business, tell users where you are located, how you can be contacted. Build a listing which stands out!
Once we've approved your content and your payment has been cleared (if you've chosen a business package) your listing will go live for the world to see.
You'll receive an account login and password so you can modify your business details subject to the package type you have chosen.
As soon as it goes online, your business listing page becomes visible to our users.
Your company gets visibility and ranking both on our website and on all search engines.
Your business listing page is also available on mobile phones & smart devices.


Every year the novices visit our communities throughout the Province, on a southern tour in the spring, and a northern tour during the summer. During these tours, the brothers share their stories of discernment and learn about the various ministries the friars are involved in. Check out the schedule below to see where you can meet the novices, hear their stories and learn about a Dominican vocation.
Click here to read more about the novices before they arrive in your neighborhood.


text:
Q: SSH tmux terminal lines unreadable due to wrong overlap, interleaving I am not sure what to search for. "Terminal lines overlap" mostly brings up posts where that is the desired behavior.
Let me demonstrate what I am experiencing over SSH to Raspberry Pi running dietpi. jq -h is just an example.
dietpi@tv22-rpi1:~$ jq -h
jq - commandline JSON processor [version 1.5-1-a5b5cbe]
Usage: jq [options] <jq filter> [file...]
jq - commandline JSON processor [version 1.5-1-a5b5cbe]
Usage: jq [options] <jq filter> [file...]inputs, applying the
        given filter to its JSON text inputs and producing the
        jq is a tool for processing JSON inputs, applying the
        given filter to its JSON text inputs and producing the,
        filter's results as JSON on standard output.(except for
        The simplest filter is ., which is the identity filter,
        copying jq's input to its output unmodified (except forq")
        formatting).://stedolan.github.io/jq
        For more advanced filters see the jq(1) manpage ("man jq")
        and/or https://stedolan.github.io/jq
         -c             compact instead of pretty-printed output;
jq - comSome of the options include:sion 1.5-1-a5b5cbe]value;
Usage: j -coptions] <jq compact instead of pretty-printed output;put;
         -n             use `null` as the single input value; output;filter to it;
         -eis a tool forset the exit status code based on the output;filter to it;
         -sen filter to read (slurp) all inputs into an array; apply filter to it;
         -rter's resultsoutput raw strings, not JSON texts;
         -R simplest filread raw strings, not JSON texts;ilter,
         -Cying jq's inpcolorize JSON;n't colorize JSON);pt for
         -Mmatting).tabsmonochrome (don't colorize JSON);
         -Stabreuse tabssort keys of objects on output; ("man jq")
         --tab ause tabs for indentation;o value <v>; <v>;
         --arg a v a v fset variable $a to value <v>; <v>;y of JSON texts read from <f>;
         --argjson a v fset variable $a to JSON value <v>;y of JSON texts read from <f>;
dietpi@t --slurpfile a ffor moreset variable $a to an array of JSON texts read from <f>;
dietpi@tSee the manpage for more options.
dietpi@tv22-rpi1:~$

Old lines don't get cleared or moved up as they should. Instead, new lines just interleave with the old line creating an unreadable "soup".
I wonder if tmux on dietpi is to blame. I did a quick check and couldn't reproduce the behavior without tmux yet.
dietpi@tv22-rpi1:~$ tmux -V
tmux 2.8

Many other posts revolve around these settings so I include them. They don't look problematic to me.
dietpi@tv22-rpi1:~$ shopt | grep checkwinsize
checkwinsize    on
dietpi@tv22-rpi1:~$ echo $PS1
${debian_chroot:+($debian_chroot)}\u@\h:\w\$

Clarifying TERM variable, as suggested in the comments.

*

*Outermost TERM=xterm-256color (Linux laptop GNOME Terminal 3.18.3; note putty on Windows behaves similarly)

*TERM=screen in local tmux

*TERM=screen after connecting over ssh

*TERM=screen inside tmux over ssh

A: tmux is (re-)drawing the display on its rendered-upon terminal in a way that that terminal does not understand.
tmux is emitting terminal control sequences, in order to redraw its display after its (rendered) terminal displays scroll up, that do not match the actual terminal that is in use.
This is because you've lied to tmux about the type of that rendered-upon terminal.

TERM=xterm-256color (Linux laptop GNOME Terminal 3.18.3 […] putty […]

This is wrong.

*

*The correct terminal type for GNOME Terminal, and other terminal emulators that use the VTE widget library (including GNOME Terminator), is vte or vte-256color.

*The correct terminal type for PuTTY, and programs based upon it such as KiTTY and (the misleadingly-named) MobaXTerm, is likewise putty, putty-256color, or putty-sco.

*The correct terminal type for Kovid Goyal's kitty, not to be confused with the PuTTY derivative KiTTY, is kitty or kitty-direct.
(kitty itself provides a terminfo record by a different name, the very misleading "xterm-kitty" that does not follow the long-established terminfo naming conventions.
kitty and kitty-direct are the names of the vanilla records in the Dickey terminfo database, following those naming conventions.)

*The correct terminal type for MacOS iTerm is iTerm.App and for George Nachman's iTerm2 is iTerm2.App.

*The correct terminal type for MacOS Terminal is nsterm or nsterm-256color, "ns" indicating its heritage as NeXTSTEP Terminal.

*The correct terminal type for Terminator (the Java one, not the GNOME one) is terminator.

*The correct terminal types for the terminal emulators that are built into the Linux, OpenBSD, NetBSD, and FreeBSD kernels themselves, are linux, linux-16color, pccon, pcvt25, and teken.  (My nosh toolset provides an additional teken-256colour termcap record, as it comes with a terminal emulator that intentionally behaves as the FreeBSD kernel's one but adds Indexed and Direct colour capabilities.)

These are what the TERM environment variable inherited by tmux should be in order to correctly describe the rendered-upon terminal to it.
The correct terminal types for the rendered (interior) terminals, in the TERM environment variables inherited by processes using those terminals for I/O, are tmux, tmux-256color, and tmux-direct, although one can get away with screen.
It is a widespread incorrect assumption that terminal emulators are all compatible with XTerm, and that the xterm and xterm-256color entries in the terminfo database correctly describe them.
This erroneous thinking is called out in Thomas Dickey's XTerm FAQ and it is worth observing that the xterm and xterm-256color entries do not even describe all versions of XTerm itself, let alone other terminal emulators.
The only time that you should set the TERM environment variable to xterm, xterm-256color, or indeed "xterm-anything", are when the terminal emulator actually is the XTerm program.
Telling a full-screen TUI program, like tmux, the wrong terminal type can have all sorts of effects: from parts of the screen not being refreshed, through things being drawn in the wrong places and background colours going awry, to box drawing coming out as letter characters.
Further reading

*

*Jonathan de Boyne Pollard (2019). "TERM".  Miscellany.  nosh toolset.

*Thomas E. Dickey (2018). "What versions are available?". XTerm FAQ. invisible-island.net.

*https://unix.stackexchange.com/a/515517/5132

*How and where is $TERM interpreted?

*How to get rid of the annoying characters in `tmux` panes and menus

*https://unix.stackexchange.com/a/579165/5132

redpajama_set_name: RedPajamaStackExchange


text:
Home » TV News » Hasbro Star Wars Galaxy Adventures Figures Revealed
Hasbro Star Wars Galaxy Adventures Figures Revealed
By Matt McGloin / Friday, November 30, 2018 - 5:36PM Friday, November 30, 2018 - 5:36PM
Following the release of the new trailer, Hasbro reveals their new line of Star Wars Galaxy Adventures figures.
Each 3.75-inch figure features a mini-comic and QR code for young Padawans to learn more about their favorite characters.
The figures will be available exclusively at Walmart on December 1st and then nationwide in January 2019. The first wave of figures is available for pre-order now (Darth Vader, Luke Skywalker, Chewbacca, R2-D2).
Star Wars Galaxy of Adventures is a new series of animated shorts that will introduce the classic themes, pivotal moments, and iconic characters from the Star Wars saga to the next generation. The first six shorts debuted today on the newly created Star Wars Kids Website (www.StarWarsKids.com) and YouTube channel (www.YouTube.com/StarWarsKids), with additional shorts debuting in December and then on a weekly basis starting in 2019.
Hasbro Star Wars Galaxy Adventures info:
STAR WARS fans new and old can discover the exciting action from a galaxy far, far away with figures and more from STAR WARS GALAXY OF ADVENTURES! Learn about the most iconic characters from the STAR WARS movies or scan the included QR code to join in on the adventures of fan favorites like DARTH VADER, HAN SOLO, PRINCESS LEIA, LUKE SKYWALKER, and more! With STAR WARS GALAXY OF ADVENTURES, the galaxy far, far away comes home!
New STAR WARS GALAXY OF ADVENTURES products for Fall 2018 include:
STAR WARS GALAXY OF ADVENTURES DARTH VADER Figure and Mini Comic
(HASBRO/Ages 4 years & up/Approx. Retail Price: $9.99/Available: Fall 2018)
DARTH VADER is a Sith lord who uses the powers of the Dark side to battle Rebel forces and help the evil Galactic Empire keep control of the galaxy. Learn about DARTH VADER and other STAR WARS characters with figures from GALAXY OF ADVENTURES. Each pack contains 1 3.75-inch figure, 1 mini comic, and 1 QR code that kids can activate with your smart device to discover more stories online about the character! Includes figure, accessory, mini comic, and digital code. Available exclusively at Walmart.
STAR WARS GALAXY OF ADVENTURES LUKE SKYWALKER Figure and Mini Comic
A farm boy from Tatooine, LUKE SKYWALKER becomes a hero when he trains as a Jedi and uses the Force to help save the galaxy. Learn about LUKE SKYWALKER and other STAR WARS characters with figures from GALAXY OF ADVENTURES. Each pack contains 1 3.75-inch figure, 1 mini comic, and 1 QR code that kids can activate with a smart device (smart device not included) to discover more stories online about the character! Includes figure, accessory, mini comic, and digital code. Available exclusively at Walmart.
STAR WARS GALAXY OF ADVENTURES CHEWBACCA Figure and Mini Comic
CHEWBACCA is a legendary Wookiee warrior and the loyal copilot of the Millennium Falcon, one of the fastest ships in the galaxy. Learn about CHEWBACCA and other STAR WARS characters with figures from GALAXY OF ADVENTURES. Each pack contains 1 3.75-inch figure, 1 mini comic, and 1 QR code that kids can activate with a smart device (smart device not included) to discover more stories online about the character! Includes figure, accessory, mini comic, and digital code. Available exclusively at Walmart.
STAR WARS GALAXY OF ADVENTURES R2-D2 Figure and Mini Comic
A loyal droid and skilled starship mechanic, R2-D2 witnesses some of the galaxy's greatest battles as he serves alongside legendary pilots and rebels. Learn about R2-D2 and other STAR WARS characters with figures from GALAXY OF ADVENTURES. Each pack contains 1 3.75-inch figure, 1 mini comic, and 1 QR code that kids can activate with a smart device (smart device not included) to discover more stories online about the character! Includes figure, 2 accessories, mini comic, and digital code. Available exclusively at Walmart.
New STAR WARS GALAXY OF ADVENTURES products for Spring 2019 include:
STAR WARS GALAXY OF ADVENTURES PRINCESS LEIA Figure and Mini Comic
(HASBRO/Ages 4 years & up/Approx. Retail Price: $9.99/Available: Spring 2019)
More than just a princess, LEIA is one of the greatest leaders in the galaxy and joins the Rebel forces in their efforts to defeat the evil Galactic Empire. Learn about PRINCESS LEIA and other STAR WARS characters with figures from GALAXY OF ADVENTURES. Each pack contains 1 3.75-inch figure, 1 mini comic, and 1 QR code that kids can activate with a smart device (smart device not included) to discover more stories online about the character! Includes figure, mini comic, and digital code. Available exclusively at Walmart.
STAR WARS GALAXY OF ADVENTURES YODA Figure and Mini Comic
A Jedi master and mentor to many Jedi in training, YODA proves through his impressive use of the Force that one should never judge another's power based on size alone. Learn about YODA and other STAR WARS characters with figures from GALAXY OF ADVENTURES. Each pack contains 1 3.75-inch figure, 1 mini comic, and 1 QR code that kids can activate with a smart device (smart device not included) to discover more stories online about the character! Includes figure, mini comic, and digital code. Available exclusively at Walmart.
STAR WARS GALAXY OF ADVENTURES IMPERIAL STORMTROOPER Figure and Mini Comic
STORMTROOPERS are the blaster-carrying soldiers of the Empire whose biggest mission is to destroy the Rebellion and protect the Imperial cause. Learn about an IMPERIAL STORMTROOPER and other STAR WARS characters with figures from GALAXY OF ADVENTURES. Each pack contains 1 3.75-inch figure, 1 mini comic, and 1 QR code that kids can activate with a smart device (smart device not included) to discover more stories online about the character! Includes figure, mini comic, and digital code. Available exclusively at Walmart.
STAR WARS GALAXY OF ADVENTURES HAN SOLO Figure and Mini Comic
A smuggler and a scoundrel, HAN SOLO proves that he can also be a hero when he rescues his friends and helps in the Rebellion against the Galactic Empire. Learn about HAN SOLO and other STAR WARS characters with figures from GALAXY OF ADVENTURES. Each pack contains 1 3.75-inch figure, 1 mini comic, and 1 QR code that kids can activate with a smart device (smart device not included) to discover more stories online about the character! Includes figure, mini comic, and digital code. Available exclusively at Walmart.


QUE.com CyberSecurity. Artificial Intelligence (ML/DL). Virtual Reality. Robotics.
Visiting Washington DC Top 5 Beaches in Europe 3D Video Cameras: The Perfect Holiday Addition QUE.com is 20 years old today! QUE T-Shirt is now available.
Add your blog or business website here.


Mark your calendars and join us for a weeklong adventure into the Bible. Plan on spending July 8th - 12th with us as we engage in games, music, crafts, and of course scripture in this year's Vacation Bible School. We look forward to a great week with children in grades kindergarten (entering fall of 2019) through 4 th in the morning. Kids in grades 5-6 th are invited to help in the morning and stay in the afternoon for a special, age appropriate program all their own!


text:
Norwich City must beware the bloopers in January transfer market business
Luciano Becchio, left, and Vadis Odjidja-Ofoe - Becchio never got much further than the bench. Picture: Paul Chesterton/Focus Images Ltd - Credit: Paul Chesterton/Focus Images Ltd
Sean Morrison. Scott Hogan, Conor Hourihane. Bailey Wright. All touted as good, possible, signings for Norwich City a year ago.
Morrison stayed at Cardiff, manager Neil Warnock rejecting a £3m summer bid from Sheffield Wednesday by saying it "wouldn't even buy one of Morrison's legs". Hogan joined Aston Villa from Brentford for £12m, Hourihane cost Villa £3m and Wright joined Bristol City for around £500,000. Which explains why Norwich weren't in with a shout for at least three of them.
With the January transfer window open, the purse strings are even tighter and it looks like recruitment will be restricted to freebies or loans. Cash deals may happen only if someone is sold, although selling the big assets this month would simply be an acknowledgement of the season ending right now.
There are so many names bandied around that it is impossible to be accurate on incomers – who's has dinner with Daniel Farke, who's applied for a loyalty card at the local supermarket?
Recruitment is arguably the hardest part of the job, and City have come up with some bloopers over the years – free signings or otherwise. While Manchester United wasted millions on Angel Di Maria and Juan Veron, City had a Luke Chadwick or a Luciano Becchio. Chadwick was half decent, but hardly ever wore a City shirt: injured on his scoring debut against Ipswich, he started 16 league games in two years.
Becchio joined from Leeds in a deal which saw Steve Morison head the other way – the Argentine was an Elland Road hero but his move to Norfolk was effectively a career-ender. He started two league games in two and a half years and never scored. What on earth was manager Chris Hughton thinking?
Tony Andreu followed Alex Neil down from Hamilton and did nothing, but Ricky van Wolfswinkel will go down as the biggest flop of them all – City paid £8.5m for his services but over-hyped him. So much was expected, but the lad never stood a chance and scored once in 16 league starts in three years before he was sold to Vitesse Arnhem for half a million.
And that's part of the reason we are here today, pondering a cashless January...


text:
Tags Bollywood
Tag: bollywood
Bollywood civil suit not against select channels media houses
A new statement, issued on Wednesday on behalf of Bollywood production houses that filed a civil suit against certain media houses a few days...
Multiplexes to reopen with 50% seating from Oct 15
In its latest guidelines for further reopening, the Union Home Ministry has allowed certain activities such as functioning of cinemas, theatres and multiplexes with...
Bollywood condemns father-son's custodial death in Tuticorin
Glamsham Editorial - June 27, 2020 0
Bollywood has condemned the alleged police brutality on a father-son duo and their eventual death in judicial custody, in Tamil Nadu's Tuticorin district.
Indian music has to look beyond Bollywood
Indian music is a vast ocean, yet all our attention seems to be focussed on the one small pond that is Bollywood Music. It is time that changed
Bollywood cine workers bodies allege non-payment of dues by producers
Bollywood's cine workers bodies have issued a statement to clear pending payments of actors and technicians
Actors 'sceptical' to shoot as Bollywood reopens shop
With lockdown regulations being relaxed and the Maharshtra government giving a go-ahead, a slew of filmmakers in Bollywood have decided to resume shooting
Bollywood promoting unhealthy behaviours among kids: Study
Glamsham Editorial - June 8, 2020 0
It's been a tipsy two decades in Bollywood with a rise in alcohol and fast food product placements in films, according to a study. People,...
Maha permits films, teleserials shootings to resume
Glamsham Editorial - May 31, 2020 0
In a significant decision, the Maharashtra government on Sunday permitted resumption of shootings for films, teleserials, advertisements, OTT, etc with immediate effect, an official...
The Baadshah of Bollywood – Shah Rukh Khan completes 27 years entertaining us
Shah Rukh Khan who had a very humble beginning right form the 1989 serial "Fauji" to his latest film "Zero." Shah Rukh Khan who is now not only an national icon but also an International icon too.
Kasautii Zindagii Kay actor Karan Singh Grover speaks on experimenting for growth
After a decade-long successful career on the small screen, Karan Singh Grover made his Bollywood debut in 2015 with the film "Alone" and then did "Hate Story 3". The switch didn't pan out well for him, but he says experimenting must never stop.
Desire to win more important than result: Suman Rao
The result of the Miss India pageant was announced over the last weekend. Suman took some time to believe that she had achieved one of her dreams by winning the crown.
Bollywood's MC Sher at the Grazia Millennial awards 2019
Ever since his debut, he has been the talk of the town. Siddhant Chaturvedi who has taken over the world like a storm with his promising debut as MC Sher was recently felicitated with the title of the 'Breakthrough star of the year' award at Grazia Millennial awards.
See what Ranveer Singh has to say about Virat Kohli
Ranveer, who on Sunday made his commentary debut with Star Sports alongside cricket stars Sunil Gavaskar and Virender Sehwag. Ranveer is currently tied up with "83."
When Ranveer Singh hugged, consoled a Pakistan fan
Ranveer Singh's on-field hug of Indian skipper Virat Kohli is not the only moment that created a social media frenzy. The Bollywood star also embraced a Pakistan fan and told him not be upset after his country's team lost to India in a ICC Cricket World Cup 2019 match in Manchester.
Salman Khan pulls off a stunt to wish nephew
Superstar Salman Khan pulled off a stunt to wish his nephew Yohan, the son of his brother Sohail Khan. Salman tweeted a video in which we see Yohan and his father Sohail Khan.
Big filmmakers don't want TV face as lead: Shaheer
Yeh Rishtey Hain Pyaar Ke actor Shaheer Sheikh has been part of the telly world since 2009 and been offered roles in movies too. He has acted in Indonesian films though.
Anshuman Jha ensures sensitivity in playing this role
Actor Anshuman Jha, who features with Zarine Khan in a unique story of love with two central homosexual characters, says he wanted to steer clear from the conventional "Bollywoodisation" of such a role.
Foreigners dance on Bollywood numbers at World Cup
India have started their campaign in the ongoing World Cup in England and Wales in an emphatic manner winning both their opening encounters against South Africa and Australia.
Sanjay Dutt is on a film signing spree with back to back projects!
One of the most talented and versatile actors of Bollywood, Sanjay Dutt, is on a spree as he is signing a lot of projects. Looks like the star is in a complete work mode with a bundle of scripts reaching him.
When Cowboys changed the phase of film industry
Put your hats on and get ready to sit on horseback because we are going to take you on a ride with the Cowboys. The Cowboys were the natives of North America almost dating back to the 19 century.
First song of Hrithik Roshan's Super 30 to be a romantic number
Hrithik Roshan's Super 30 which is creating the right stir amongst the audience is going to release a new song. Udit Narayan, who had given playback for some of the iconic songs has lent his voice to the song.
What is it for Taapsee to be amongst stars
Bollywood actress Taapsee Pannu feels like a sandwich stuffing when she found the poster of her upcoming film. The actress is going to face tough competition at the box office with one Hollywood film and a big canvas Bollywood film.
Malaika Arora teases Arjun on social media
Arjun Kapoor and Malaika Arora have refrained from talking openly about their much-speculated relationship. Arjun recently took to social media in which he posted an image of him sitting on a toy horse.
Ranveer Singh thrilled to try out Bingo's unique flavour
With the quirky youth icon and Bollywood superstar Ranveer Singh on board as the brand ambassador for Bingo! Bingo launched a creative TVC to announce this anticipated contest.
Is Gulshan Grover a part of Akshay Kumar's SOORYAVANSHI?
Actor Gulshan Grover, who is fondly known as the "badman" of Bollywood, is set to treat his fans with his villainous role in Rohit Shetty's upcoming film "Sooryavanshi". He says his role in the film is a new version of an antagonist.
Trolls dub Mouni 'plastic', compare her to Rakhi Sawant
Actress Mouni Roy's appearance at the premiere of BHARAT got the social media world talking about the possible plastic surgeries she may have undergone, and some Instagram users compared her to Rakhi Sawant and late King of Pop Michael Jackson.
Bhandarkar shares photograph with Yogi Adityanath
National Award-winning filmmaker Madhur Bhandarkar took to social media where he shared a picture of himself along with Uttar Pradesh Chief Minister Yogi Adityanath, who turned 47 on Wednesday.
Suhana Khan's selfie with ATM card grabs attention
Superstar Shah Rukh Khan's daughter Suhana Khan's latest mirror selfie with her ATM card showing, has grabbed the attention of social media users. The photograph in news is the profile photograph of Suhana's private Instagram account.
Kajol pens emotional note for Veeru Devgan
Actress Kajol shared a photograph of herself with the late action director Veeru Devgan on social media. Kajol also has penned an emotional note, remembering her late father-in-law.
Know who gave a thumbs up to Deepika's post
Deepika Padukone rooted for the importance of sleep with a quirky social media post, which got a thumbs up from actors Hrithik Roshan and Abhishek Bachchan.
Comedian Dinyar Contractor dead at 79
Veteran model, comedian, film and theatre actor Dinyar Contractor died on Wednesday, family sources said. He was 79. Dinyar had been suffering from various age-related illnesses since sometime.
Mohammad Kaif meets Katrina Kaif
Former cricketer Mohammad Kaif shared his "finally the Kaifs meet" moment with actress Katrina Kaif, sending fans in a tizzy. He shared a photograph in which the two of them are all smiles for the camera.
Anubhav Sinha's ARTICLE 15 faces Brahmin ire in UP
Anubhav Sinha's much awaited Ayushman Khurana starrer ARTICLE 15 which is reportedly inspired from the Badaun rape and murder case, seems to be heading for trouble. The film, slated for a June 28 release, has earned the ire of the Brahmin community in Uttar Pradesh.
Why was KABIR SINGH exciting for Shahid Kapoor
Actor Shahid Kapoor says getting into the KABIR SINGH avatar for the film with the same name was a challenging task. The film is a remake of the popular Telugu hit film ARJUN REDDY which originally starred Vijay Deverakonda and Shalini Pandey.
Shah Rukh attends wedding of his hairstylist's sister
Superstar Shah Rukh Khan attended the wedding of his hairstylist's sister, leaving his fans gaga about his humility. A throwback video has been doing the rounds on Internet in which SRK is seen arriving at the wedding along with his manager and greeting the bride and groom on stage.
See why Shekhar Kapur doesn't need cars
Acclaimed filmmaker Shekhar Kapur who has made films like BANDIT QUEEN, MASOOM and MR. INDIA, finds it silly to own a car in Mumbai and says he does not need them to prove his self esteem.