Step F Solution Demonstration & Design Approach. Agenda o Demonstration of Step F o Scope o...
-
date post
20-Dec-2015 -
Category
Documents
-
view
223 -
download
0
Transcript of Step F Solution Demonstration & Design Approach. Agenda o Demonstration of Step F o Scope o...
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!