Slide 1 - CANHEIT

242 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
242
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • See Sun’s paper on the web at http://www.sun.com/software/communitysource/principles.xml
  • We are going to examine the whole question of a Student System built on a Service oriented Architecture from a different perspective. We are going to drill right down to a very small segment of the Student System to examine how it might be built on web services. And then we will zoom back to the big picture to see how this micro view confirms some of the broad conclusions of SOA. Here are some preliminary assumptions about a community source student system: It is too big to be built as a single monolithic system It has to be built as a set of independent components These components are collections of web services It has to be built with open technologies On an open source infrastructure On open standards With open source tools Customers of a community source Student System may wish to implement using commercial infrastructure products or commercial tools. However, reference implementations of Student System modules have to be based entirely on open source, otherwise the project becomes a reseller of commercial products.
  • Here is a brief inventory of the business modules that, taken together, make up a fully functional Student System. These modules could be stand-alone in that they could be implemented by themselves and still perform useful work. They are: Recruitment and admissions Registration Curriculum development. Advising Course and exam scheduling. Fee assessment and payment Awards and financial aid. Degree audit and end-of-term evaluation. Graduation These modules all use a set of common infrastructure modules (indicated by the blue boxes in the diagram). Some of the infrastructure modules are enterprise wide in that they could equally well be used by FMIS, Payroll and HR. They include: Identity services (authentication and authorization). Communication services (e-mail and calendars). All these modules communicate with each other via a common set of protocols and technologies which we call the service bus . It is important to divide up the Student System at this level because these are the kinds of modules you might consider buying. They can be built and implemented as separate products. As you probably know, you can actually buy a degree audit system or a scheduling system
  • If we drill down one level deeper we find that these components are themselves aggregations of more primitive services. From a design point of view we can categorize services as follows: Composed services . This is sometimes called the orchestration layer. An orchestration coordinates the work performed by different services. For example you might have a grades collection module that: Authenticates a user. Gets the user roles and permissions. Retrieves a class list Collects and updates grades. Business services . A business service is a service that performs a specific business function. For example, you could have a service that managed the academic record. It could have a method to retrieve a collection of grades. It is agnostic in the sense that it does not know or care about the context. The grades collection could be initiated by an admissions process, a degree audit process or a transcript transmission process. It is composable in the sense that it can be used as a basic building block in a more complex process. Infrastructure services . Some of these services are enterprise-wide and are not limited to the student system. They include things like authentication and authorization.
  • The different categories of services are really abstractions to help us with the design process. We distinguish between business processes and services during the design phase because these distinctions help us model our business. It is extremely important to get that design “right” because if we can draw the correct boundaries around our services we will achieve the kind of Loose coupling Re-usability That we want for a really modular system. However, when it comes to the actual implementation, all services look the same. They have an interface that is described in the standard Web Service Definition Language (or WSDL ). They contain some code that does the actual work. You can plug them together via something we can call a service bus .
  • A service consists of three parts: A service container. An interface definition. Actual code (Java of C++) that does the work. The service container is code that will abstract certain common functions from individual services. These include things like: Lifecycle management: Start, stop, refresh, test Security: Authorization and authentication Logging and caching In an SOA these will themselves be implemented as services. So this diagram is a little misleading. For activities like authorization and logging, you must imagine the service container reaching out to other services to perform these tasks. The WSDL is the interface to the service. It is an XML document that describes: The input types (as XML schemas) The method that will be called The return types (as XML schemas) The manner in which inputs and outputs will be mapped to SOAP messages Inside the service are a set of common JAVA (or C++) programs that actually do the work.
  • The service bus is actually an abstraction that covers both standards and software components. The standards refer to the XML standards that should be ubiquitous throughout the Student System. For example: There needs to be a standard XML schema for transcripts that will be understood by all services. There needs to be a standard XML schema for test score results. Some books refer to this as the canonical XML . The service container that we looked at in the previous slide is part of the bus architecture because the service container ensures that our services all communicate in a standard way. This means that: They plug into security services in a standard manner. They can be managed in a standard way from a central console. Lastly, the service bus can include a messaging system backbone. This last point requires some further clarification. A lot of the messaging within the SIS does to need to be anything more than simple point-to-point messaging. If you wanted to you could say that http was the messaging backbone because we are dealing with simple request-response message patterns. However, there will also be cases where some kind of message brokering will be required. This is especially true in the case of integration with other enterprise systems. So maybe services need 2 options for connecting with other services: Simple point-to-point Via a message broker.
  • We are going to take a simple example that represents a very small slice of SIS functionality. We will do three things: See how it is implemented as a set of web services. See how it fits into the larger component model of the Student System See how we can generalize it so that it can be used in a number of different contexts. And we can use the example to illustrate larger points about a Service Oriented Architecture In this example we are going to receive an SAT (Scholastic Aptitude Test) result for an applicant. The SAT score arrives via ftp as a text file (because, for some odd reason, SAT’s are not implemented as EDI T138 transactions). The file is parsed and it is converted to our standard (canonical) XML Both messages (before and after the conversion) are logged The SAT is evaluated The SAT and the evaluation result are added to the applicant’s file
  • Here is a graphical illustration of how a set of services could be combined to complete the process we just outlined. In this particular example the routing information is part of the message itself. The message is a SOAP message and the routing information would be stored in the SOAP headers. Here are the steps: An admissions process will set the routing information in the SOAP headers and the actual data/XML payload in the SOAP body. The document transformation service would create the correct XML representation of the SAT score. It would then examine the SOAP headers to discover the next destination for the message and then forward it to the logging service. Once the logging service had completed its work the message would be passed on to the evaluation service Once the SAT scores had been evaluated, both the SAT itself and the results of the evaluation would be stored in the applicant’s academic record. Of course there are different ways of implementing this Instead of creating a “self- routing” message, the admissions module could have coordinated the entire process by First calling the transformation service Secondly, calling the evaluation service Thirdly, calling the evaluation service Lastly, calling the academic record service This is an illustration of the concept of message patterns .
  • We can illustrate a number of points about an SOA by looking at different aspects of these individual services. For example, a message transformation service enforces the canonical XML of the system. It ensures that all messages are converted to the standard XML schemas that all other services understand. It is worth stating some of the reasons why XML schema is the vehicle for capturing the entity model of the Student System First, XML is the lingua franca of web services Secondly, XML schema allows us to create an extensible data model: It support inheritance. It supports includes. It supports the creation of complex types. Thirdly, it has a very rich set of constructs for defining data relationships. For example: The order in which element appear. The range of allowable values for an element. Lastly, some of the “heavy lifting” has already been done by organizations like PESC and IMS. Developing schemas can be painstaking and time-consuming work so there is an enormous advantage in using off-the-shelf schemas wherever possible. Note: the performance of XML is not really an issue. The real issue is remoting. If you are going to implement remote services then you have to serialize objects across the wire. Serializing and deserializing can be expensive operations and XML is no exception.
  • When we use web services then the interfaces to our services will be defined as WSDL’s. The WSDL is an XML file that acts as a standard service contract. Here are some of the key points: First, it is not obvious. So before we look at it in some more detail, there needs to be simple description of the service in English. For example: “The academic evaluation service will apply evaluation rules to test score results and transcripts. The inputs can be a test score (see test score schema) and the ID of an evaluation ruleset…”. The English description must be published on a website along with the WSDL itself. If you want to see an example of this you can go to the Google web service: http://www.google.com/apis/ The second point is that our data definitions are imported. For example, we are simply going to use the PESC definition for test scores (because we have mapped our inbound SAT score to this definition). This further illustrates the enormous importance of a standard set of XL schemas because every service is simply going to re-use these definitions WSDL itself is a W3C standard and it is very well thought out. Secondly, the WSDL specifies which of the data structures belongs in the inbound and outbound messages. Lastly, the WSDL maps these messages to the parameters of an actual method (which could be implemented in java or C++)
  • Here is the first slide that showed the Student System as a series of modules. Now we can see how a process (in this case an admissions process) is actually composed of a number of different services. This illustrates one of the basic principles of a Service Oriented Architecture, namely, that individual services can be composed into more complex processes.
  • If we had a module that could only process SAT scores we would not necessarily want to deploy it as a service. What we need it to generalize the service so that it can do useful work in a number of different contexts. So we Generalize the input to cover any kind of learning result. This would include: Any kind of test score: GRE, LSAT, TOEFL, SAT Any kind of transcript (high-school transcripts and post-secondary transcripts). The results of Broader based admission We plug in a generic rules engine so it can process any kind of rule: Admission requirements. Awards rules. Degree requirements. Now our service can be re-used by a number of different Student System modules:
  • Once the service has been generalized it can be used by a number of different modules. For example: It can be used by the admissions module to determine the admissibility of applicants. It can be used by the registration module to do pre-requisite checking It can be used by the awards module to evaluate applicants for merit based awards It can be used by the degree audit function This illustrates another core concept of a Service Oriented Architecture: namely, the re-usability of core business services.
  • Of course a fundamental question is whether the: Standards Tools Technologies Are available to build the king of system we are proposing. There is the extra caveat that, in the context of a community source project, we need these technologies to be open source so that the Student System does not become a reseller of commercial products. The technologies in question are: Core infrastructure Operating systems Databases Application servers Web service standards Web service technologies Tools to develop web services Run time containers for web-services Application components
  • Here is a highly oversimplified picture of the evolution of open source. Open source pre-dates Linux. However, the point of this illustration is to show that it is now possible to build enterprise solutions entirely on an open-source software stack. There are: An open source operating systems (Linux) Open source web containers (JBoss and Apache) Open source databases (mySQl and postgeSQL )
  • The core standards that are required for a Student System based on web-services are XML schema , WSDL and SOAP . That is because these are the standards that allow us to: Capture our entity model Capture our service model These are all W3C standards and they are reliable and mature. XML schema was published as a W3C Recommendation in May 2001 WSDL 1.1 was published by W3C in 2001. WSDL 2.0 is a recommendation till July 2006 SOAP 1.0 dates from 2000, SOAP 1.2 from 2003 The other web-service standards required for a full blown SOA are not as mature. In a pure SOA all infrastructure needs are met by services. Thus requirements such as transactional consistency should be delivered by services. The fact that these areas of web-services are not as mature should not really matter. In the initial phases, a Student System would only need the core web-service standards: XML schema WSDL SOAP The other standards cover things that are typically dealt with in the service container. As long as concerns such as transactional consistency are carefully isolated in the service containers, a web-service version could always be implemented later in the project.
  • The whole question of Web Service standards is really an issue for tool vendors. It is organizations who are creating software like: WSDL to Java compilers SOAP-Java binding frameworks Run-time engines for web services Who really need to worry about the details of the standards (at least at the WS-I level of detail). A community source student system should be using “off the shelf” tools. To that extent the details of standards are immaterial. There are already excellent tools for developing web services that plug into the Eclipse platform. They include: Graphical tools for authoring XML schemas (which have really nice code completion features). The Axis plug-ins that include graphical tools for developing WSDL’s
  • The development of a distributed system will require a large investment in business design: Data model Service model The design work need to be done collaboratively. Models need to be versioned and published. At the same time there needs to be a reference set of tools and technologies. All of the above speaks to the technology and architecture of the project. Of course there will have to be the appropriate management and governance structures in place to make this kind of project work.
  • Slide 1 - CANHEIT

    1. 1. A Community Source Student Services System Richard Spencer Leo Fernig CANHEIT, Halifax June 12, 2006
    2. 2. Mellon funded planning study <ul><li>Goals </li></ul><ul><ul><li>level of interest in an open source SSS? </li></ul></ul><ul><ul><li>need for an open source SSS? </li></ul></ul><ul><ul><li>any existing applications to use as a base? </li></ul></ul><ul><li>Participants </li></ul><ul><ul><li>University of Indiana, Georgetown University, San Joaquin Delta College, UBC, consultants and others </li></ul></ul><ul><li>Consultation </li></ul><ul><ul><li>meetings at JA-SIG and Sakai conferences </li></ul></ul><ul><ul><li>SOA workshop in Vancouver </li></ul></ul><ul><ul><li>focus groups at AACRAO </li></ul></ul><ul><ul><li>consultation with vendors </li></ul></ul>
    3. 3. <ul><li>3 developments that enable a CS SSS </li></ul><ul><li>open and community source software development </li></ul><ul><li>service oriented architecture (SOA) </li></ul><ul><li>Web services </li></ul><ul><li>The SSS vision </li></ul><ul><li>focus on the end user </li></ul><ul><li>support all types of learning </li></ul><ul><li>build a modular system </li></ul><ul><ul><li>integrate modules with existing systems </li></ul></ul><ul><li>use workflow and rules engines </li></ul><ul><ul><li>cross departmental and system boundaries </li></ul></ul><ul><ul><li>implement “your practices”, not “best practices” </li></ul></ul>
    4. 4. Open and Community Source
    5. 5. The evolution of Open Source Core Infrastructure Tools and components Enterprise solutions Linux (1991) 1990 Apache (1995) 1995 2000 2005 PostgreSQL (1999) Eclipse (2004) uPortal (2001) Sakai(2004) Kuali(2004) Moodle(2001) jBoss (1999) SSS (2006) ???
    6. 6. Open vs. community source <ul><li>Open source </li></ul><ul><li>Open membership </li></ul><ul><li>Large developer community </li></ul><ul><li>Individuals may decide priorities & projects </li></ul><ul><li>Local development can lead to different versions </li></ul><ul><li>Source code is open for review and change </li></ul><ul><li>Corporate contributions welcome </li></ul><ul><li>Community source </li></ul><ul><li>Membership in a community </li></ul><ul><li>Smaller development community </li></ul><ul><li>Priorities established by community </li></ul><ul><li>Locally developed components are compatible </li></ul><ul><li>Source code may be included in commercial products </li></ul><ul><li>Institutional and corporate contributions welcome </li></ul>
    7. 7. Community source objectives <ul><li>Productivity </li></ul><ul><ul><li>more developers working on project </li></ul></ul><ul><li>Reliability </li></ul><ul><ul><li>more eyes looking for bugs </li></ul></ul><ul><li>Innovation </li></ul><ul><ul><li>institutions are free to innovate and share </li></ul></ul><ul><li>Direction </li></ul><ul><ul><li>partners can have input into Community projects </li></ul></ul><ul><li>Evolution </li></ul><ul><ul><li>community can ensure sustained development </li></ul></ul><ul><li>Partnerships </li></ul><ul><ul><li>include commercial partners </li></ul></ul>
    8. 8. A student services system
    9. 9. SOA goals <ul><li>break business processes down into: </li></ul><ul><ul><li>process or control logic (orchestration service layer) </li></ul></ul><ul><ul><li>business logic (business service layer) </li></ul></ul><ul><ul><li>infrastructure functions (application service layer) </li></ul></ul><ul><li>use standard data models and XML schemas </li></ul><ul><li>build agnostic, reusable “services” to provide the business logic and application functions </li></ul><ul><li>use rules engines for the internal logic </li></ul><ul><li>use workflow for the process logic </li></ul><ul><li>loosely couple components </li></ul><ul><li>agility - make process change easier! </li></ul>
    10. 10. Community source SSS possibilities <ul><li>True service analysis and orientation </li></ul><ul><li>Common entity models, data standards and XML schemas </li></ul><ul><li>Web services for loose coupling </li></ul><ul><li>Combining modules developed at different schools </li></ul><ul><li>Combining open source and commercial components </li></ul><ul><li>Using commercial service providers to implement and support systems and system components </li></ul>
    11. 11. Imagining a next generation student services system
    12. 12. The Expedia model <ul><li>Where do you want to go </li></ul><ul><li>When do you want to go there </li></ul><ul><li>You can choose: </li></ul><ul><ul><li>the airline </li></ul></ul><ul><ul><li>the class </li></ul></ul><ul><li>You can sort the results by </li></ul><ul><ul><li>price </li></ul></ul><ul><ul><li>departure or arrival time </li></ul></ul><ul><li>if you like one of the choices..... </li></ul><ul><ul><li>provide your name and payment information </li></ul></ul>
    13. 13. How we often deal with applicants <ul><li>Give me your personal information first </li></ul><ul><ul><li>including your name, gender, date of birth... </li></ul></ul><ul><li>Here is a list of every program we offer </li></ul><ul><li>Choose no more than two </li></ul><ul><li>Pay us </li></ul><ul><li>We will let you know if we can admit you </li></ul><ul><li>.....but give us a few weeks to figure this out </li></ul><ul><li>If yes, we will give you a registration time </li></ul><ul><li>Then you can search for the courses you need </li></ul><ul><li>If no, </li></ul><ul><ul><li>we keep your money anyway </li></ul></ul>
    14. 14. Letting students admit themselves
    15. 15. Self evaluation and admission <ul><li>If there are specific admission requirements: </li></ul><ul><ul><li>e.g.: required courses, grades or gpas </li></ul></ul><ul><li>Students choose a program & enter their own courses and grades </li></ul><ul><li>A rules engine determines if they are admissible </li></ul><ul><ul><li>they get a full explanation of: </li></ul></ul><ul><ul><ul><li>what credentials were used, what was missing </li></ul></ul></ul><ul><ul><ul><li>how the admission gpa was calculated </li></ul></ul></ul><ul><ul><ul><li>why they did or didn’t qualify for admission </li></ul></ul></ul><ul><li>They can admit themselves.. </li></ul><ul><ul><li>and print their admission letter in real time </li></ul></ul>
    16. 16. Reflecting on self-admission <ul><li>Students: </li></ul><ul><ul><li>do the grade submission work </li></ul></ul><ul><ul><li>get an immediate answer </li></ul></ul><ul><ul><li>can see the rules and how they have been applied </li></ul></ul><ul><li>The process allows: </li></ul><ul><ul><li>a student to try multiple “what if” scenarios </li></ul></ul><ul><ul><li>counselors to advise students on program requirements </li></ul></ul><ul><li>The rules engine could allow the student to: </li></ul><ul><ul><li>select a program, and see what is required to enter it </li></ul></ul><ul><ul><li>enter what they have, and see what they are eligible for </li></ul></ul><ul><li>Staff can concentrate on value added work </li></ul><ul><li>The process is scalable! </li></ul>
    17. 17. Applicant login Identity service Evaluate applic’t/ offer choices Program/aid services Information collection Prior inst. services Applicant profile Choice not available Registration service Outcome Choice available
    18. 18. What we have learned
    19. 19. The vision is right <ul><li>Focus on end users </li></ul><ul><li>Support all kinds of learning </li></ul><ul><li>Modular, standards based, loose coupled </li></ul><ul><li>SOA, web services, and enterprise services </li></ul><ul><li>Workflow, rules engines (decision services) </li></ul><ul><li>Make it easy to redesign business processes </li></ul><ul><li>Extend functionality into new areas </li></ul><ul><li>Community source development </li></ul><ul><li>Scalable, rule based, self-service processes </li></ul>
    20. 20. The need is there <ul><li>add functionality to existing systems </li></ul><ul><ul><li>ERPs can’t do everything </li></ul></ul><ul><ul><li>re-use some existing functionality </li></ul></ul><ul><li>replace old technology </li></ul><ul><ul><li>don’t want to install a monolithic ERP system </li></ul></ul><ul><li>future path for in-house systems </li></ul><ul><ul><li>one institution can no longer develop a complete student system </li></ul></ul><ul><li>get off the ERP upgrade path </li></ul><ul><ul><li>improvements don’t always reflect cost and effort </li></ul></ul><ul><li>Delaware: </li></ul><ul><li>housing </li></ul><ul><li>dining </li></ul><ul><li>course approval </li></ul><ul><li>judicial referral </li></ul><ul><li>course & faculty evaluation </li></ul><ul><li>advising notes </li></ul><ul><li>Indiana </li></ul><ul><li>course trading </li></ul>
    21. 21. The next steps <ul><li>International participation in planning </li></ul><ul><li>Entity models, XML schemas </li></ul><ul><li>Service oriented analysis of key processes </li></ul><ul><ul><li>some process redesign </li></ul></ul><ul><li>Web services standards </li></ul><ul><li>Reference infrastructure </li></ul><ul><li>Identify partners who will build modules </li></ul><ul><li>Form a partnership </li></ul><ul><li>Build the first modules </li></ul>
    22. 22. ...and now to cover Leo’s part
    23. 23. Development strategy for a student system <ul><li>It is too big to be built as a single monolithic system </li></ul><ul><ul><li>It has to be built as a set of independent components </li></ul></ul><ul><ul><li>These components are collections of services </li></ul></ul><ul><ul><li>The services are loosely coupled using Web services </li></ul></ul><ul><li>It has to be built with open technologies </li></ul><ul><ul><li>On an open source infrastructure </li></ul></ul><ul><ul><li>On open standards </li></ul></ul><ul><ul><li>With open source tools </li></ul></ul>
    24. 25. A more detailed decomposition of services <ul><li>Business services </li></ul><ul><li>Agnostic </li></ul><ul><li>Composable </li></ul><ul><li>Composed services </li></ul><ul><li>Aggregations </li></ul><ul><li>Orchestrations </li></ul><ul><li>Infrastructure services </li></ul><ul><li>Enterprise wide </li></ul><ul><li>Student System specific </li></ul>
    25. 26. Services are built on the same model
    26. 27. Anatomy of a service <ul><li>A service is composed of: </li></ul><ul><li>A container </li></ul><ul><ul><li>Lifecycle management </li></ul></ul><ul><ul><li>Security </li></ul></ul><ul><ul><li>Caching/logging services </li></ul></ul><ul><li>An interface defined in WSDL </li></ul><ul><ul><li>Data structures </li></ul></ul><ul><ul><li>Method signatures </li></ul></ul><ul><li>Implementation code </li></ul><ul><ul><li>Java classes </li></ul></ul>
    27. 28. Anatomy of a service bus <ul><li>A service bus is composed of: </li></ul><ul><li>A canonical XML </li></ul><ul><li>Lightweight service containers </li></ul><ul><li>A messaging system backbone </li></ul>
    28. 29. A simple example: Processing an SAT score <ul><li>An SAT score arrives via ftp: </li></ul><ul><li>It is converted to standard (canonical) XML </li></ul><ul><li>Both messages are logged </li></ul><ul><li>The SAT is evaluated </li></ul><ul><li>The SAT and the evaluation are added to the applicant’s file </li></ul><ul><li>In reality these services would deal with any tests: GRE,TOEFL, LSAT </li></ul>
    29. 30. A simple example: Message flow
    30. 31. A simple example: A message transformation service <ul><li>All messages in the Student System conform to a standard set of schemas (a canonical XML) </li></ul><ul><li>Wherever possible we need to use existing industry standards. For example: </li></ul><ul><ul><li>PESC http://www.pesc.org/ </li></ul></ul><ul><ul><li>IMS http://www.imsglobal.org/ </li></ul></ul>
    31. 32. Example: WSDL for an academic decision service <wsdl:types> <xsd:import namespace=“http://www.pesc.org/” schemaLocation=“test.xsd”/> <xsd:import namespace=“http://open.sis/schema/rules” schemaLocation=“rules.xsd”/> <xsd:import namespace=“http://open.sis/schema/result” schemaLocation=“result.xsd”/> </wsdl:types> <wsdl:message name=“EvaluationRequest”> <wsdl:part element=“pesc:test” name=“EvaluationRequest”/> <wsdl:part element=“key:ruleKey” name=“EvaluationRequest”/> </wsdl:message> <wsdl:message name=“EvaluationResponse”> <wsdl:part element=“res:result” name=“EvaluationResponse”/> </wsdl:message> <wsdl:portTypes> <wsdl:operation name=“evaluate”/> <wsdl:inout message=“EvaluationRequest”/> <wsdl:output message=“EvaluationResult”/> </wsdl:operation> Data definitions Message definitions Interface definition Schemas are defined elsewhere
    32. 33. A simple example: Fitting services into the component model <ul><li>Message transform service </li></ul><ul><li>Logging service </li></ul><ul><li>Academic decision service </li></ul><ul><li>Academic record service </li></ul>
    33. 34. Generalizing from the simple example <ul><li>In reality we would not want a service that simply </li></ul><ul><li>evaluated SAT scores. Instead….. </li></ul><ul><li>A general Academic Decision Service </li></ul><ul><ul><li>Degree audit </li></ul></ul><ul><ul><li>Pre-requisite checking in registration </li></ul></ul><ul><ul><li>Evaluating admission requirements </li></ul></ul><ul><li>A general Academic Record Service that can handle any learning result: </li></ul><ul><ul><li>Test results (SAT, TOEFL, GRE) </li></ul></ul><ul><ul><li>Transcript courses (and transfer credit) </li></ul></ul><ul><ul><li>Portfolio artifacts </li></ul></ul>
    34. 35. Generalizing from the simple example <ul><li>Academic decision service </li></ul><ul><li>Is used by: </li></ul><ul><li>Admissions </li></ul><ul><li>Registration </li></ul><ul><li>Awards </li></ul><ul><li>Degree Audit </li></ul>
    35. 36. Are the technologies available? <ul><li>Core infrastructure </li></ul><ul><li>Web service standards </li></ul><ul><li>Web service technologies </li></ul><ul><li>Application components </li></ul>
    36. 37. Core infrastructure Linux (1991) 1990 Apache (1995) 1995 2000 2005 PostgreSQL (1999) Eclipse (2004) uPortal (2001) Sakai(2004) Core Infrastructure Tools and components Enterprise solutions Kuali(2004) Moodle(2001) jBoss (1999)
    37. 38. Web service standards <ul><li>W3C standards: </li></ul><ul><ul><li>XML schema </li></ul></ul><ul><ul><li>WSDL </li></ul></ul><ul><ul><li>SOAP </li></ul></ul><ul><li>Other web service standards (mainly OASIS): </li></ul><ul><ul><li>WS-transaction </li></ul></ul><ul><ul><li>WS-coordination </li></ul></ul><ul><ul><li>WS-security </li></ul></ul><ul><ul><li>BPEL (Business Process Execution Language) </li></ul></ul><ul><li>Web Service Interoperability Group </li></ul><ul><ul><li>Basic Profile </li></ul></ul><ul><ul><li>Basic Security Profile </li></ul></ul>
    38. 39. Web service tools <ul><li>Tools for authoring XML schemas </li></ul><ul><li>Tools for authoring WSDL’s </li></ul><ul><li>Web service run-time containers </li></ul><ul><li>For example: </li></ul><ul><li>WST Eclipse tools for authoring XML schemas </li></ul><ul><li>Axis (Apache) graphical tools for authoring WSDL’s </li></ul><ul><li>Web service run-time containers </li></ul>
    39. 40. Conclusion Three prerequisites for a student system <ul><li>An entity model </li></ul><ul><ul><li>A high level entity model </li></ul></ul><ul><ul><li>A set of XML schemas (a canonical xml) </li></ul></ul><ul><li>A service model </li></ul><ul><ul><li>A high level service decomposition model </li></ul></ul><ul><ul><li>A common set of WSDL’s </li></ul></ul><ul><li>Technology infrastructure </li></ul><ul><ul><li>Core infrastructure </li></ul></ul><ul><ul><li>Web services standards </li></ul></ul><ul><ul><li>Web service tools and technologies </li></ul></ul><ul><ul><li>Application components </li></ul></ul>

    ×