STEP F Solution Demonstration_14Jun V 1.0 - Jisc

basiliskcanoeSoftware and s/w Development

Nov 2, 2013 (3 years and 8 months ago)

101 views

Step F


Solution Demonstration



&

Design Approach

Agenda

o
Demonstration of Step F

o
Scope

o
Architectural Design

o
Participants

o
UAT Set up

o
Testing Scenarios (End to End)

o
Test Results

o
Design Approach for Step F

o
Design solution

o
Advantages & Limitations

o
Design Benefits to HE sector

o
Value Adds













Step
-
F: Overview

ESB

Student

Record

(
Aggresso

Student
)

De Montfort


HECSU

Student

Record

(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

Student

Record

(BANNER)

University of Leeds

1

2

3

4

Web
-
Services &
SOA

Registry

5

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
e
xternal
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
.

Internet

HEDD

RULES

SYNC

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

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

Step F: Program Artifacts

Artifacts produced, reviewed during the project lifecycle


o
System Requirement Specification


HEDD Data Collection & Patterns Matching Document

o
Detailed Design Document


ESB Client Creation Guidelines


Design Details on usage of “Part Type”

o
UAT Testing Approach Document

o
Weekly Status Review


STEP F


Solution Design

Step F: Solution Design

o
Design

o
Advantages & Limitations

o
Benefits
to HE sector

o
Value 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!