Creating MyBank Web Service Demo Application

Infologica Fusion Framework provides business analysts and programmers with the clear design and development methodology and sophisticated toolset allowing to streamline the web service development cycle and rapidly deliver new solutions that create, validate, enrich, transform, route and process Xml messages with minimum disruption of the existing systems and maximum leveraging of existing assets and skills.
There are 7 main steps in the Infologica web service development cycle:
  • Design of the service interface specification using Infologica XSD Editor
  • Generation of the interface serialisation classes using Infologica XSD Editor
  • Implementation of the interface specification in the component service using Infologica Service Templates integrated with Visual Studio 2005
  • Debug of the component service using Infologica Application Services Test Bench and Visual Studio 2005.
  • Publishing of the web service end point by mapping to the component service using Infologica Enterprise Services Management Console.
  • Test of the web service operations using Infologica Web Services Test Bench.
  • Remote deployment of the web service and infrastructure adapters configuration settings to the environment cluster using Infologica Enterprise Services Management Console.
In the current demo we will try to show how business analyst and developer follow the above methodology through the design and implementation of the MyBank Web Service using Infologica Fusion System Capabilities.
Infologica XSD Editor transforms the complex and routine job of schema generation in to the trivial task, allowing business analyst with no XML/XSD knowledge to create or edit the type library and web service definition using the treeview interface with the simple drag/drop manipulation. XSD Editor allows Business analyst to create the separate library of common types and further reuse it by importing generic types to the specific schema. Infologica XSD Editor Visual interface supports XML and XSD view modes allowing business analyst to drag XSD schema types to the operation canvas and immediatelly visualise them in the readable XML format. Any changes to the types, their attributes or referenced types are also immediatelly reflected on the operation canvas.
Below is the Xml view of the Xsd schema created by business analysts for the MyBank Demo Web Service. It defines the CreateAccount, SignOn and GetBalance operations and all assosiated data types, their restrictions and extensions.
The finalised schema is sent to the programmer who is using the same XSD Editor to generate the interface serialisation classes with a click of a button.
The CodeDomCompiler generated C# code contains all schema types and operations converted to the classes and saved in the Bank.cs file for further reference. The code snippet below is a sample of the generated Account class:
Using Visual Studio 2005 the programmer creates the new project from the Infologica Fusion Application Service Template.
Once the project is created the programmer adds the New Item to the project by selecting the Fusion Serializable Operation from the Visual Studio Installed Template Dialog. Operation template provides the basic implementation of the Infologica Fusion component service public interface. For this demo the programmer creates 3 public classes, each per operation defined in the MyBank.Xsd. Finally the programmer adds to the project the previously generated MyBank.cs file with the interface serialisation classes.
Each template-generated C# class contains the generic code for logging, performance monitoring, deserialisation, serialisation and exception handling. After adding the "Using" directive referencing the namespace of the MyBank interface serialisation classes developer gets access to the MyBank object model.
The special "Developer code Area" in the Infologica Fusion operation template is allocated for code customisation. This is the region where developer writes the message processing code and invokes infrastructure service adapters. Instead of using the XPath query developer easily manipulates with the deserialised request and response objects using visual studio intellisense capabilities:
Infologica Fusion Framework provides developers with the sophisticated debugging tool - Application Services TestBench. The testbench should be registered with the Visual Studio project as a start external programm:
The test bench uses reflection to dynamically list all operations implementing the Infologica Fusion IRequestHandler interface. Infologica Fusion Framework architecture allows developers to create multiple test scenarious using test bench and debug their application services locally while invoking all back-end infrastructure services using the .NET Remoting.
Once all operations of the component service are successfully debugged on the developer machine, a compiled .NET assembly and XSD schema file are being deployed to the Infologica Fusion development server:

The component services are placed under the Infologica Fusion Framework\Bin folder.
The location of the schema definition files is under the Infologica Fusion Framework\Schemas folder.

At this stage the component service can be registered and invoked by any service from the Infologica Fusion Services Family.

The next task is to expose the MyBank component service as a web service. All we need is to create a new web service end-point and simply map it to our component service assembly. Infologica provides you with the Enterprise Services Management Console to do this task.
Infologica Enterprise Services Management console allows the web services administrator to create/edit the new webservice end-point and enforce the client authentication and schema validation policies. Administrator can also :
  • dynamically load the operation definition from the XSD schema
  • configure operation processing mode (syncronous, queued, workflow-bound)
  • define the operation context role (initialiser, consumer, terminator, browser)
  • specify logging level (information, warning, error)
  • register an XSL transformation templates for the request and response messages
Next, the Infologica Fusion Web Services Adminstrator needs to configure the client access policy, choosing IP filtering or certificate authentication and define the client subscription policy. In this demo the client with the alias name "TravelAgent" identified by IP Addresses 127.0.0.1 and 169.254.25.129 was subscribed for the MyBank service.
Finally the Web Services Adminstrator deploys the modified web services configuration settings to all boxes registered with the Infologica Fusion development cluster.
Now the web service MyBank became published and available for the web services discovery. Infologica Fusion SOAP Listener will dynamically generate the MyBank webservice WSDL on every client request.
The last step is to invoke the component service as a web service using the Infologica Web Services Test Bench. If required the test bench allows to digitally sign and encrypt the message request as well as to decrypt the message response using X.509 certificates.
So far we have successfully designed, built and tested the CreateAccount Web Service. Up to this point we did not take into consideration the Account Provisioning Process which stays behind the Create Account Request.

The real life scenario could take a few hours or days which makes impractical the synchronous type of web service request.
Infologica Web Services Framework allows to change the type of service request from synchronous to queued with a click of a button.

With the help of Infologica Web Services Administration console we modify the CreateAccount operation configuration and invoke it again using the Infologica Web Services test bench. This time the web service response contains the ticket issued by the Infologica Fusion Framework:

The Infologica Fusion Framework saves original web service request with its message queuing middleware and processes it on the background by the job scheduler or workflow engine. We are just using the issued ticket to periodically invoke the generic Web Service Operation and query status...
...and eventually getting the service response containing the AccountCreation Details.

In the last scenario the actual job of Creating the Bank Account was executed by the same component service we've implemented on the first stage for the web service synchronous operation. This is a classic example where the component service was simply reused and invoked by another trigger (job scheduler) implementing Infologica Fusion IRequestHandler Interface.

Now it's a good time to tighten up the security and modify the client subscription policy replacing the IP Filtering with X.509 Certificate Authentication. Administrator can do this with a click of a button by selecting the client public certificate file. It is a client responsibility to provide his valid public certificate.

Because the "CreateAccount" operation contains some sensitive data we would like to also enforce the message encryption policy. Infologica Web Services Administration console gives us the flexibility to encrypt the SOAP envelope for request and/or response:

After deploying the configuration changes we can do the final test of the "CreateAccount" operation using Infologica Web Services test Bench. Our first attempt to call the web service without digital signing of the SOAP request is rejected by the framework with the following SOAP Exception:

Infologica Web Services Test Bench allows us to select the private certificate from the digital store and sign the SOAP request.

According to the subscription policy we also have to encrypt the data using Infologica Fusion Server Public certificate. The test bech makes this task very straightforward. This time the test is successfull as framework returns us the message response containing the ticket Id:

In this example the Infologica Fusion Framework completely abstracts both developer and administrator from the complexity of digital authentication and data encryption providing intuitive interface for tuning the client subscription policy and service invocation mode, making the component service an infrastructure-agnostic.

Infologica Fusion Framework also eliminates such cross-cutting developer's concerns like transaction logging and performance monitoring. All calls are automatically logged into the Infologica Fusion database and can be searched and analysed over the Web using Infologica Fusion LogViewer.

Back to demos and tutorials