Web代写：COMP30231 Service Oriented Architecture Principles

发表于   |   分类于

使用Service Oriented Architecture的设计方式，实现一整套Web服务器。

Service Oriented Architecture

Assessment Requirements

The practical element (sections A & B) of the coursework will be viva examined. Please have a top-level schematic diagram ready for the viva and prerecord your demo in a 5-minute presentation to ensure that you do not exceed your allocated time. In your presentation you should focus on the functionality as well as the code briefly explaining how you implemented functionality and how you integrated the components. If you chose not to prerecord and do not finish within the allocated time you will be stopped by the examiner and be evaluated based on the presented evidence so far.

You should submit a coursework report documenting your solution and answers to the research elements (sections C & D). The structure of the report should contain:

  1. Self-evaluation of the achieved implementation for Sections A-B (please be brief and precise, no introductions or background information needed) including functional description of your program, and discussion of your major design decisions. Please include top-level design diagrams only. Do not exceed 2 pages.
  2. Maximum of 800 words for Section-C plus any charts describing the results of your experiments.
  3. Maximum of 1,200 words for Section-D. Again, please adhere to the required comparison, with minimum introductory information.
  4. List of references and appendices.

The goal of this coursework is to demonstrate an understanding of using Service Oriented Architecture principles in software applications integration. In the first section, you will utilize web services to create a distributed serviceoriented system for advertising and searching for travel opportunities. The Service Orchestrator connects to two external REST services for generating a unique user ID and for getting the weather forecast for a specified location. It also connects to a message queuing system to publish and consume messages from other users.

Core web service

Implement the Orchestrator service

The service orchestrator should be implemented as a REST service running on the local Tomcat/Glassfish server.

The service should allow clients to perform a series of actions like: generate unique user IDs, query for new messages, and to submit messages (for new trip proposals and for trip interest). These should be exposed as REST methods for external clients to consume. The service should connect to the messaging system (RabbitMQ) to relay user actions as messages.

Access to RabbitMQ will be provided in the NOW room (credentials, URL). To access it you must use Pulse Secure on your personal machine, or you can access it through the Virtual PC.

The messages sent as REST calls by clients will be published/consumed by the REST service to/from the message queues. All communication is done in JSON. The messages sent by the service to the messaging system are of four types (see Figure 2 below also):

  • Query message (use the exchange called TRAVEL_OFFERS): retrieve information about upcoming trips. The response should contain the user ID, the message ID, coordinates of the place of visit, and the proposed trip date no more than 14 days in the future. In addition, when relaying it to the client after a REST call, the service should append the weather forecast for the location at the specified date.
  • Intent message (use the exchange called TRAVEL_INTENT): notify a user who has published a trip proposal that another user is interested in the invite. The sent message should contain the user ID, the ID of the user that has submitted the proposal, and the message ID.
  • Check intent message (use the exchange called TRAVEL_ INTENT): retrieve information about other users’ interest in the user’s trip proposal. The service response to a client REST call client should contain all the information sent in the Intent messages.
  • Submit trip proposal message (use the exchange called TRAVEL_OFFERS): notify other users about a trip proposal. The message should contain the user ID (sender or receiver), the message ID, coordinates/name of the place of visit, and the proposed trip date no more than 14 days in the future.

The Orchestrator REST service should expose to the client at least 5 methods corresponding to the four message types and an additional one for generating a user ID. It is up to you to pick a suitable HTTP method for each and to motivate the choice in your report/demo.

Web service composition

Integrate external REST services

To enable the Service Orchestrator to work as intended it must consume 2 external services: one for generating random IDs and another for the weather forecast.

Data from the weather service should be cached locally by saving it to a JSON file in order to avoid repeated calls for the same location and problems caused by network connections. A similar approach should be taken for the random generator where a sequence of randomly generated values should be stored locally for later reuse in case the Internet connection fails.

Implement client

You client should implement functionality to store the trip proposals it has issued and expressions of interest by other users.

A text or GUI based interface client for communicating with the REST service should be implemented.

To simulate a real-life system clients could either consume messages published by other students’ clients or you could create 2 clients and test the functionality between the two by linking them both to the service.

In order to achieve the highest marks, you must show initiative and inventiveness beyond the stated specification; the contribution of the advanced functionality depends on technical challenge in its implementation. Examples include:

  • Demonstrate that the client (user) can communicate to other clients (students) through the message queueing system;
  • Implementing additional functionality based on what is offered in the mentioned external REST APIs; Examples can include:
    • A confirmation message from the trip proposer to the interested person after the latter expresses his/her interest;
    • Adding an external geolocation service for expanding the search radius in case forecast is unavailable for given location (example: https://rapidapi.com/wirefreethought/api/geodb-cities/ which has a free tier);
  • Implementing non-Java clients to demonstrate SOA’s platform independence or running the orchestrator service on Tomcat deployed on the Azure cloud.
  • Add support for XML based messaging besides the required JSON one.
  • Etc.

Analysis of QoS

Referring to your implementation, describe SOA Web Services’ performance and scalability challenges, in particular with the increase in service demand - such as the number of concurrent client connections and the size of the payload (response messages). Highest marks will be awarded to submissions that perform physical QoS testing (for instance through JMeter - available on NTU software hub) for the developed application.

Explain how Cloud Computing provision can address these issues, and referring to the deployment model, elaborate on the challenges accompanying migration to the Cloud Infrastructure.

Analysis of Big Data scenarios and ways of mitigating them through cloud computing (weighting 20%)

Today’s social applications generate a large volume of data at variable data rates.

In the context of the 8V’s select 4 of them and describe how they relate to your application. You should consider things such as the number of users, message rates, data types, etc. Consider their impact on storage, network, and processing and discuss potential solutions.

Discuss infrastructure and software implications that Big Data could have on the functioning of the application and how cloud computing (public/private/hybrid) could address them. At least 2 implications must be identified.

Endeavour to use other sources of information (papers, articles, etc.).

Feedback Opportunities

Formative (Whilst you’re working on the coursework)

You will frequently be given informal verbal or written feedback regarding your performance on tasks relating to the coursework assessment during the lectures, surgeries, and/or laboratory sessions. Attendance is therefore important for your development and thus coursework success. In addition, your Tutor may provide you with additional interim formative check points depending on the delivery pattern of the course.

Summative (After you’ve submitted the coursework)

You will receive specific feedback regarding your coursework submission together with your awarded grade when it is returned to you. Your assessor will provide you with the following as a minimum:

  • Your grade;
  • A feedback comment (a statement regarding the quality of your work);
  • A feed forward comment (a statement regarding how you could improve your data analytic knowledge and skills for the future).

Resources that may be useful

Referencing styles please use Harvard as detailed here.
Guide to planning your time is here and an automated planner here
Guidance on avoiding cheating is here

Remember to use Outlook or physical calendars to block out time between lectures and labs to work on this coursework.

Moderation

The Moderation Process

All assessments are subject to a two-stage moderation process. Firstly, any details related to the assessment (e.g., clarity of information and the assessment criteria) are considered by an independent person (usually a member of the module team). Secondly, the grades awarded are considered by the module team to check for consistency and fairness across the cohort for the piece of work submitted.

Aspects for Professional Development

ALL aspects of this coursework will provide meaningful evidence of a wide range of academic, technical and ‘soft skills’ such as organisation and planning, analytical reasoning, reflection and effective report writing. It also provides your employer with clear evidence of your ability to understand and build distributed applications by following a serviceoriented architecture and leverage cloud capabilities.

Many of these are useful transferable skills for employment applications or your Skills Portfolio. Similarly, the practical class protocols provide several examples appropriate for use in the Skills Portfolio as bioscience (i.e., subject-specific) skills.