Service-oriented architecture (SOA) allows departmental developers working on a variety of applications at the various campuses and facilities of the University of Illinois to provide data access without worrying about the data sources.
The architecture for the university's enterprise resource planning (ERP) system also allows IT to do routine maintenance and upgrades to the ERP system without needing to test hundreds of departmental applications, explains Amin Kassem, manager of administrative information technology services at the school. The SOA implementation was part of the five-year global campus initiative (ERP) project that now provides campus offices and departments with administrative data, financial data, personnel and student data, he said.
All that data is available from the ESB for Ajax and rich Internet applications (RIAs) developed for the University of Illinois campuses in Champagne-Urbana, Springfield and Chicago, as well as the online campus, Kassem said.
"We decided to bring everything into one single system," he said of the recently completed initiative. "We came to the realization that there were a lot of systems that require enterprise data form the ERP system," he said.
The architects for the initiative did not want all the departmental applications accessing databases directly because it would have put a heavy load on the ERP system and the database management infrastructure, Kassem explained. So the initiative's architects decided to add a middle tier using an SOA approach that would allow access via JMS and Web services protocols for departmental applications, he added.
"SOA came into play to give us a way to decouple ourselves from the different IT units and departments and provide information in a secure and reliable way without having a huge impact on the ERP system," Kassem said.
As an example of how this works, he pointed to the admissions offices for the various campuses. The data on student applications is stored in a database accessed by the main ERP system that manages admissions that tracks applications and status. However, the people in the individual campus admission offices also need to access this information.
"How we deal with that is we use messaging protocols to place the data in message objects," he explained. "The message object contains the basic information about the applicant and their status."
The end user can also subscribe to the ERP system and receive updates published via the ESB when the applicant's status changes, he explained. Or they can use a Web application that interacts with the ESB in request/reply mode.
"In our environment we look at SOA as a framework," Kassem said. "We define the business objects in XML format that can be pumped into the bus. So we define applicant, we define vendor, we define all these business objects. Once an object is defined, we make it available through messaging in the bus."
Web services enable HTTP requests
The system allows departmental developers to access data via two methods, he explained.
"There is a JMS method where applications know how to use JMS to talk to the servers can get the data they need," he said. "The other way is providing a Web service. We use Web services developed in-house to allow people to do HTTP requests. They make a request through a Web service to access the data from the bus."
The system provides data to the bus regardless of the data source of the departmental developers do not have to worry about it.
"We define behind the scenes the core infrastructure the business object," Kassem said. "We do the plumbing behind the scenes where we can define the systems for the data and pump the data onto the bus."
The application developers simply connect to the bus and request the proper data and all the data management chores are taken care of by the system.
"To do that we have other services in our core infrastructure that allow us to authenticate and authorize applications, services that allow us to do routing, services that allow us to log all transactions being requested from the bus," Kassem said.
Prior to the SOA implementation, he said, developers of departmental applications had to find which databases contained information they needed and then create individual queries for that data.
"Now, we can say we have this particular piece of data available on the bus and anybody who needs to use this data can connect to the bus," Kassem said. "Being able to share the data among applications was a huge plus for us."
The another advantage is the developers for the various campuses, administrative offices and departments can now create applications much faster, he said.
"Because now we have created standards of how we connect to the bus, how to consume the data, and how we apply the data to the application, it makes it much easier to deploy a new application," Kassem said. "So it's given departments the agility to deploy applications much faster."
Finally, after five years development work on the ERP system, SOA provides the ability to maintain and update it without impacting the hundreds of departmental applications that interact with it.
"We achieved that by having the bus to manage the interaction with the applications and it becomes the backend infrastructure for the applications," Kassem explained. "That provides us with huge benefits where now all we need to do is make sure our pump into the bus is functional, then we can upgrade our ERP system without having to test everything related to the applications. Having to test every application in the decentralized system would be a daunting task."