1. Step F Solution Demonstration & Design Approach

2. 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

3. 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

4. Step F: High Level Scope Open Integration Layer

5. Step F: Solution Architecture

6. 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.

7. Internet HEDD RULES SYNC Solution Overview

8. 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

9. Step F Solution Testing

10. 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

11. 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)

12. Student Validation Service flow

13. 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

15. Step F: Program Schedule

16. 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

17. STEP F Solution Design

18. Step F: Solution Design o Design o Advantages & Limitations o Benefits to HE sector o Value Adds

19. 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.

20. 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. 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.

21. 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

22. Public Cloud Benefits: Multiple Consumers & Multiple Applications/Services Multiple Endpoints to access various services Effective utilisation of available resources Public Vs Private Cloud

23. 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

24.  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

25. 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

26. Value Adds

27. 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

28. 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

29. Question & Answers

30. Thank You!