.. Server, synchronous services
When developing a Weda endpoint, a developer may either start from a web-service implementation class generated from a WSDL file. He can use existing tools for skeleton from WSDL generation and use HTTP endpoint to point the tool to the right direction. A WSDL (Web Services Description Language) document describes the contract between the web service endpoint and the client. Legacy webservice generated stub typically implements request-reply pattern.
The basic process for deploying a web service throught Weda endpoint con-sists of 5 steps:
1. At the application start, the Weda gateway MUST be bootstrapped. Its main responsibility is to configure and run WebSocket server, so the frames become accessible by the implementation of WebSocket API and transformed into messages. Configuration of address must conform to physical Weda endpoint address (Via) as described in chapter 3.3.3.
Listing 5.1: Starting the Weda gateway
WedaGateway.Start(configuration);
2. Host service and configure it for creation of instances per session. Each service instance creates its own connection channel.
Listing 5.2: Service host
host = new ServiceHost(typeof(CalculatorService), new Uri(”ws://mydomain.com:80/Calculator”));
3. Add all logical endpoints to the service with applying Weda binding and referencing the running gateway. Give the unique name to each end-point. Names must conform to logical address of Weda endpoint (To).
Endpoints of the service share the channel and implementation performs routing to the right endpoint from the wire.
Listing 5.3: Adding logical endpoints
host.AddServiceEndpoint(typeof(ICalculatorServiceContract), new WedaBinding(WedaGateway), ”soap12”);
4. Optionally add behavior to the endpoints. For example to configure dis-patcher to deal with the WS-eventing format.
Listing 5.4: Optional behavior to the endpoints
foreach(var endpoint in host.Description.Endpoints) {
endpoint.Behaviors.Add(new WedaDispatchEndpointBehavior());
}
5. Listen on endpoint
Listing 5.5: Listen on endpoint
host.Open();//listen for incoming
These steps are to be applied on legacy service as well as duplex service such as Weda eventing services.
.. Synchronous consumer
Synchronous clients don’t have to modify the generated stub to be able to make requests to the Weda endpoint and receive appropriate responses. Because we want to make a connection before the requests, we don’t want the client proxy to deal with channel creation. Channel Factory enables us to create a communication channel to the service without a proxy. We will configure the channel to use Weda binding and point it to the right physical and logical address.
Listing 5.6: Configure client side for Weda channel
ChannelFactory<ICalculatorServiceContract> dchfCalc = new ChannelFactory<ICalculatorServiceContract>(
new WedaBinding(),
new EndpointAddress(”ws://localhost:2016/”, ”weda://Calculator/soap12”));
calculatorServiceProxyChannel = dchfCalc.CreateChannel();
After that we can call remote methods by proxy as usual.
Listing 5.7: host
var result =calculatorServiceProxyChannel.Add(1, 2);
.. Asynchronous services
A service operation can be implemented in an asynchronous fashion using BeginOperation and EndOperation methods. This allows us to lock on instance effectively. If asynchronous services are to be implemented, programming language must support them. If asynchronous operations in service con-tract allowed, developer should use programming language’s tools to gener-ate Begin/End pairs. Such an approach gives us more flexibility to maximize throughput which is balanced against interactivity and doesn’t have any im-pact on calling or message exchange pattern.
.. Asynchronous consumer
If we plan to use other MEP than request-reply or we don’t want to block UI while server is processing our request, we can create methods that use a duplex (two-way) contract. A duplex contract consists of two one-way contracts be-tween the client and the server. These are corelated in Weda for request-reply MEP. But definitelly they are not required to. For example Weda eventing services make use of push callbacks initiated by server.
All methods MUST be set as one-way operations. Service contract MUST be correlated with so called Callback contract. Developer should create the callback interface that defines the set of operations that the service can invoke on the client by the same way as he does with services contract. Server will call client’s method using callback variable.
Listing 5.8: Server invoking methods at the client side.
callback = OperationContext.Current.GetCallbackChannel<ICalculatorDuplexCallback>();
callback.Equals(3);
Example of such a duplex service WSDL can be found in the appendix C.
When eventing is added to the application, Notification manager service MUST be present with duplex contract and should contain domain spe-cific operations. If no domain spespe-cific operations are defined, one method PushingToClient(IEvent) MUST be implemented for sending the notification to client when event (complex event) occurs.
. Conclusion
In this chapter we show, how applications can be adapted to Weda API with a very small configuration. Whole architecture style should have such a min-imal interface so that webservices could be easily adapted and are not forced
to be refactored. We show that end-developer only can assign binding class of Weda API (Gateway bootstrapper) and optionally add eventing dispatcher be-haviour to the initialization part. The next chapter describes how we achieved such a minimal interface by taking a look behind the scenes of Weda API im-plementation.
. Implementation
. Overview
In previous chapters we presented (informal and formal) specification of Weda architectural style. Weda implementations rely on that specification. Its key concepts must be understand before implementing Weda into language spe-cific Weda API. We transformed Weda architectural style into reference im-plementation Weda API in C# programming language with the use of WCF library. Interface provides a number of classes and configurations for perform-ing operations that are independent of any particular instance of service. When planning for the API we wanted to achieve the goal that millions of existing web-services don’t have to be completely rewritten. They should only be ex-tended into Weda architectural style with small configuration. Because of that, the interface is as minimal as it can be (only assignable binding class and Weda Gateway bootstrapper or optionally dispatcher for WS-eventing) as we show in chapter5, but this means, that internally the implementation itself must be a very robust and self-containing.
Server and client should reference Weda API, both sides are covered in the library. If size will be issue, assembly can be divided into two assemblies in the future. C# API is available at the moment only.