Step FSolution Demonstration

& Design Approach

Agenda

o Demonstration of Step Fo Scopeo Architectural Designo Participantso UAT Set upo Testing Scenarios (End to End)o Test Results

o Design Approach for Step Fo Design solutiono Advantages & Limitationso Design Benefits to HE sectoro Value Adds

Step-F: Overview

ESB

StudentRecord

(Aggresso Student)

De Montfort

HECSU

StudentRecord

(Graduate Prospects)

(SITS)

Web Data Form

To Show the impact of a Cloud-based ESB

1. Create an open source-based ESB in a cloud with documented policies, procedures etc.

2. Develop the connectors between a national application (HECSU) to the ESB

3. Develop connectors from the Student Record systems of three different Universities and link them to the ESB

4. Develop the Web Form and business process flows to demonstrate the application working.

BCU

StudentRecord(BANNER)

University of Leeds

1

2

3

4

Web-Services & SOA

Registry5

Step F: High Level Scope

Open Integration

Layer

Step F: Solution Architecture

Step F: Solution Architecture

• Connectors are exposed as WCF services (not directly accessible to each of institutions)

and are made available in the UDDI repository only.

• The ESB will pick up the services from the UDDI repository. Similarly any other

application accessing the UDDI repository can also reuse the created services.

• The external system or HEDD app will access the STEP-F solution through a common

end point using the HTTP SOAP or RESTful protocols which ensures that solution is SOA

compliance.

• Apart from this the Itineraries of BizTalk are used which makes the solution more

loosely coupled by making independent flows. Rule engine feature is used to achieve

this.

• For secured communication we have proposed the security mode

"TransportCredentialOnly" with basic (Username/Password) credential type.

University of Leeds

(BANNER)

BCU(SITS)

DMU(Agresso System)

Internet

HEDD

RULES

STEP F ESB

FrameworkNew

University

STUDENT INFORMATION

SYSTEMMeta Data

InfoUDDI

ServicesBRE (Rule

Engine)

Biz Talk Services

Biz Talk Server

SYNC

Data Flow

Integrations

Solution Overview

Step F: Participants

• HEFCE, JISC, CETIS

• Graduate Prospects

• DMU

• University of Leeds

• Birmingham City University

• City University of London

• Fulcrum Worldwide

• HE Vendors – Agresso, Tribal, Sungard

Step F Solution Testing

Step F: UAT Set-up

Windows Server 2008 R2 Microsoft .NET Framework 3.5 SQL Server 2005 & 2008 Editions BizTalk server 2010

BizTalk ESB 2.1 Toolkit LOB Adapter Pack for BizTalk server MS Visual Studio 2008 with Visual C# .NET Microsoft Itinerary Designer

Technology Stack

Compliance to DPA

Step F: Connector Testing

Agresso Student Detail Validation( DMU)

Agresso Course extractor (DMU)

BANNER Student Detail Validation(University of Leeds)

BANNER Course extractor (University of Leeds)

SITS Student Detail Validation(Birmingham City University)

SITS Course extractor Connector(Birmingham City University)

Student Validation Service flow

1. HEDD post the file “CourseDetailsRequest.xsd” file to the SOA framework 2. Depending on “InstitutionCode” (e.g. D26 for DMU) in the input file, the path

of the file is decided at run time as which connector/service Or Course Extractor needs to be selected or invoked

3. The UCAS governed “Institution Codes” are unique for each University ensures the primary key logic

4. The application will retrieve all the course details of that university and send the total file to HEDD application.

Course Extractor Service flow

Course Extractor Service flow

Step F: Program Schedule

The program followed CMMI norms to ensure quality and process compliance

Step F: Program Artifacts

Artifacts produced, reviewed during the project lifecycle

oSystem Requirement Specification • HEDD Data Collection & Patterns Matching Document

oDetailed Design Document • ESB Client Creation Guidelines

• Design Details on usage of “Part Type”

oUAT Testing Approach Document

oWeekly Status Review

Completion of STEP F

STEP F

Solution Design

Step F: Solution Design

oDesignoAdvantages & LimitationsoBenefits to HE sectoroValue Adds

Step F: Solution Architecture

The Message Flow in Architecture:

• Request message from HEDD application to the WCF end point which is exposed.• After receipt of this message by that end point it is handed over to the ESB where the

validation of the message is done. Appropriate flow for that message is also selected using the underlying Business Rules and then the route of the message is decided.

• Once the route is defined then the connector, which is required to communicate with the Agresso Student, BANNER or SITS system is in action for further process.

• The connector returns the result back to the ESB end point and feed back to HEDD through the WCF service which is linked with the ESB.

Connector Message Types

Message1:

• This message is sent by HEDD to the WCF service which contains the header where type="xsd:anyType”.

• The Agresso Student, BANNER or SITS connectors do not use this message.

<wsdl:message name="ProcessRequestResponse_SubmitRequestResponse_InputMessage">    <wsdl:part name="part" type="xsd:anyType" /></wsdl:message><wsdl:message name="ProcessRequestResponse_SubmitRequestResponse_OutputMessage">    <wsdl:part name="part" type="xsd:anyType" /></wsdl:message>

Message 2:

• This message that will be sent to the Agresso Student, BANNER and SITS connectors.• The message has the type="xsd:string" and not the type="xsd:anyType” • This is a common message that will be sent and received from the ESB connectors. 

Public Vs Private Cloud

Private Cloud Benefits: • One Consumer & Multiple Applications/Services (Graduate Prospects – HEDD)• Single End point exposed to outside world• Optimisation of available Resources• Secure Access

Public Cloud Benefits:

• Multiple Consumers & Multiple Applications/Services• Multiple Endpoints to access various services• Effective utilisation of available resources

Public Vs Private Cloud

Advantages & Limitations

The SOA framework is exposed to the outer world as a single URL in the cloud.

Usage of the type=“anytype” in the WSDL’s

make the solution an universal acceptor.

The Agresso Student details connectors are

built using dynamic binding concepts, due

to which the rollout time required to

include any new University will be very

minimal.

Provision of direct access to database to

validate the records (The Agresso Student

connector design) enables accessing any

number of records without much of

customization and still complying fully

with security norms

Usage of type=“anytype” in the WSDL’s will

require XML validation at the ESB level(in

prescribed format) instead at WCF. If there is

any mismatch or validation failure the ESB

will reject the request.

The Interfaces created for the University of

Leeds and BCU might not work for other

universities until and unless the environment

within these universities are replicated.

The interfaces created for other Universities

may impose some limitation on the number

of records processed due to current adapter

design. It may require additional

customization to enable processing of any

number of records

Each university has its specific defined

flow which is selected through business

rules based on the input message. In

future if there is change in flow for a

specific university it will not impact any

part of the application.

The services are exposed and held in the

UDDI repository which acts as a place

holder from where the connectors can

be reused by any ESB that supports the

concepts of WCF and web services.

The design implemented for DMU

connectors will interact with the databases

directly, which might be a concern on data

security issues to the universities. However

this is taken care in the design that the data

that is picked up from the Agresso database

will not stored in any staging environment

and will be flowing within the ESB which is

an isolated environment(Private Cloud) for

outer world.

The high availability feature of the solution

is dependent not only on the cloud where

the SOA framework is hosted, but also on

the availability of the University systems to

feedback the data to the connectors.

Advantages & Limitations

Benefits to HE Sector

• Ease of Integration• Portable Solution• Configurable • Relative Low cost and Quick to implement• Reusable • Loosely coupled and available as independent services• Platform/ Technology & Vendor agnostic design

Value Adds

Dynamic Binding

• Reusability of Agresso Connector to decrease the rollout time of the connector

for any new University with Agresso system.

• The connector developed for DMU will just require minor configuration so as

to suit to other university

• Change the SQL configuration of the port for DMU connector with the details

of the Agresso system of the new university

• The new University will need to have same version of Agresso System like

DMU and will also provide the access to database to ensure connector utility

Generic Connectors: Interoperability with ESBs

The Message Flow in Architecture:

• Request message from HEDD application to the WCF end point which is exposed.• Apache CXF (Celtix & XFire) will create proxy using the client and make available to

access.• When ESB gets the request it will send data to ValidateStudent java class from where the

data will send to appropriate service and call the client of Agresso Student, BANNER or SITS system for further process.

• After receiving the response from the external system in the client, response will send to HEDD through the WCF service which is linked with the ESB.

Mule & BizTalk Architecture

Question & Answers

Thank You!