Case study for software architect
0 likes107 views
This document discusses integrating a website builder application with an admin application for an online shopping site. It considers three design options: full inclusion, no inclusion, and a microservices-based approach. The full inclusion option combines the two apps but could impact performance. No inclusion separates the apps but could cause data and communication delays. The preferred option is a microservices-based integration, which addresses limitations of the other approaches and allows for robust and flexible integrations now and in the future. User experience, performance impacts, and testing environments should be priorities in the integration process.
Case study for software architect
- 1. Osama Mustafa pg. 1 Case Study for Software Architect Contents Abstract:.................................................................................................................................................2 Introduction: ..........................................................................................................................................3 Overview: ...........................................................................................................................................3 Why we use application integration:.....................................................................................................3
- 2. Osama Mustafa pg. 2 Implementation of application integration: ..........................................................................................4 APIs and Web Applications:...................................................................................................................4 An API or the System that Supplies it?...............................................................................................5 Useful components in this diagram:..................................................................................................9 Limitation:..............................................................................................................................................9 Technical Limitations: ........................................................................................................................9 Legal Limitations: ...............................................................................................................................9 More solutions can be implemented: -..................................................................................................9 1. Full inclusion.............................................................................................................................10 2. No inclusion..............................................................................................................................10 3. Micro services-based................................................................................................................11 criteria for to determine which design to choose ...............................................................................12 Considerations .....................................................................................................................................12 Abstract: We have two separate applications that we would like to integrate together. One is a WYSIWYG application for generating static websites. The other is an admin application for managing an online shopping site. We would like to be able to use the features of the Website Builder to design pages in the Web shop. In addition, we would also like to be able to manage product details (name, price, images, etc.) while updating Web shop pages in the Website Builder.
- 3. Osama Mustafa pg. 3 Introduction: Overview: The ecosystem of e-commerce and business applications has evolved: highly specialized vendors now offer every kind of specialty tool, plug-in feature, and business operations application imaginable and still new applications are appearing every day. Incongruous operating systems and distributed applications installed on diverse hardware, with hundreds of different types of messages being sent and received simultaneously from the web and inside the organization require businesses to devote special attention to application integration possibilities. There is hardly a single web development project today that doesn’t involve some kind of 3rd party vendor integration, be it for adding the latest must-have consumer features, ensuring you have the appropriate site analytics and marketing metrics or integrating your business process applications into your website. As much as we would like to complete all our work in a single application, doing so is nearly impossible. There are various developers and entrepreneurs creating applications that specialize in assisting with specific needs and roles within companies. So, rather than relying on a single application, we inevitably end up relying on many. While this helps us complete multiple tasks, managing multiple applications and the data they store can be difficult. Application integration helps maintain, manage, and keep all your applications up to date while alleviating data duplication and redundancy. By creating an application integration network that allows applications to communicate with each other, business and work processes can be done more effectively and efficiently. Enterprise application integration (EAI) is used to describe application integration at the enterprise level where multiple applications are interconnected. Whether on the enterprise level or not, application integration can mitigate challenges related to data silos. Why we use application integration: The need for application integration stems from the need to move data between applications. This includes transferring data from one application to another in a scheduled, ongoing way or moving data once from a legacy system into something new. Or, in short, application integration is used to make life easier. With application integration, you can enter data once and connect it to multiple applications instead of entering the same data as many times as you have applications. When you add new data into an application that has been integrated with other applications, the data will be automatically distributed throughout the connected applications. This reduces human error, the need for manual
- 4. Osama Mustafa pg. 4 intervention, and overall ensures consistency across your platforms. By having a comprehensive system that forms a bridge between heterogeneous applications, you won’t have to be concerned about whether your applications were originally intended to communicate with each other or not. This gives you the freedom and flexibility to choose applications of your choice, not just apps that are within a collection of technologies or from the same vendor. Implementation of application integration: The basic of APIs: Application integration is typically done with the use of APIs. An API (application programming interface) is a package of functions or rules that allow a user to reference and interact with parts of an application for their own purposes. This allows for control and flexibility for the end user while allowing the original creators to maintain their application without interference. Within an API are the protocols that allow for application integration to take place. While APIs these days are most often referencing web APIs, APIs have long been used to integrate on premise software systems. They have played a significant role in SOA (service-oriented architecture), which has mainly taken place on premise. This means application integration was only really able to take place internally. With the web and the development of cloud applications, application integration is more commonly an external process. You do not necessarily need to have an application stored on your computer for you to be able to access the API of an application. APIs and Web Applications: APIs for web applications have become very popular and essential for various tasks due to the increase in mobile applications and cloud-based software. Web APIs are distinct for the following reasons: • They are exposed over the web using an HTTP or HTTPS protocol • Public web APIs are available over the internet, typically with supporting documentation • They are most often built using JSON or XML While web APIs do share consistencies, most web APIs will be unique in the way that you can use them. These differences are dependent on how the developers of the application decided to create the corresponding API. Therefore, the specific information that is needed to fully make use of a specific API relies heavily on the documentation that is provided. Here is the work flow diagram of the whole working system.
- 5. Osama Mustafa pg. 5 Figure 0.1 the work flow diagram As you can see how the user interact with the Application/System and how the Application and integrated API working combined and give the user a reliable system. And the user can access all the feature in single Application looks like everything is running on a one place. Here is a diagram which shows how the Application and API connect and communicate with each other by using API calls and pre-defined methods. Figure 0.2 how the Application and API connect An API or the System that Supplies it? Whatever symbol we choose, what we've done is to show the *system* rather than the actual API. The API is a definition of a service provided by the system in question. How should we provide more details about the API? There are a number of ways we could do this but my preference is to give details of the API on the connector (line connecting two elements/boxes). In C4 the guidelines for a container diagram includes
- 6. Osama Mustafa pg. 6 listing protocol information on the connector and an API can be viewed as the layer above the protocol. For example: Figure 0.1 listing protocol information Many API providers supply multiple services/APIs (I'm not referring to different operations within an API but multiple sets of operations in different APIs, which may even use different underlying protocols.) • Allow a bulk, batch download of static data (such as details of companies listed on a stock market) via xml over HTTP. • Supply real time, low latency updates of market prices via bespoke messages over UDP. Two of the services use the same protocol (xml over HTTP) but have very different content and use. One of the APIs is used to constantly supply information after user subscription (market data) and the last service involves the user supplying all the information with no acknowledgment (although it should reconcile at EOD).
- 7. Osama Mustafa pg. 7 There are multiple ways of showing this. We could: • Have a single service element, list the APIs on it and have all components linking to it. • Show each service/API as a separate box and connect the components that use the individual service to the relevant box. • Show a single service element with multiple connections. Each connection is labeled and represents an API. • Use a Port and Connector style notation to represent each API from the service provider. Provide a key for the ports. • Use a UML style 'cup and ball' notation to define interfaces and their usage. Some of these questions may come to your mind: • How are my services currently organized and exposed internally/externally? • How does the partner want to integrate with my system, e.g., internal networks, protocols, etc.? • How do I secure, track and manage the integration of my exposed services? The following integration diagram below illustrates (at a high level) the existing communication protocols between the components. You’ll also see how some of the services are being exposed to third- party developers via the External API Gateway at the logic layer.
- 8. Osama Mustafa pg. 8 Figure 0.2 existing communication protocols between the components From the diagram above, you’ll realize that the system was designed to be API-driven, which makes it easy for integration. Almost all the services are exposed via web services, including the data storage components. The next step is to check with the partner on the list of services that they require, mode of integration, e.g. internal or external, and cross-reference the requirements with the services exposed via the API catalogue. There are also follow-up action items, i.e. working with the system engineers to decide on the security and monitoring of exposed services. Sometimes, there may be requirement gaps such as partner wants to integrate externally, but your services are only exposed internally, or certain data attributes are missing. In such cases, efforts would have to be factored in to cater to the requirements. The integration diagram has to highlight details, i.e. internal services/APIs, link to API catalogue, etc. to identify such gaps quickly.
- 9. Osama Mustafa pg. 9 Useful components in this diagram: Grouped components into layers and bounded contexts — an indication of internal/external API gateways and services Annotations with additional information — reference links to API catalogues where detailed service data attributes can be obtained to assess gaps Application details and context — services are named appropriately to allow quick assessment of requirements v.s. actual. Limitation: Technical Limitations: Many API providers have technical limitations in place. I list a few here: • Rate Limits: Many API providers have limits on the number of queries you can execute per day. You would need to make sure your application doesn’t need to exceed that limit, and find workarounds for that. • Request/Response Formats: Many API providers require you to create your requests and receive your responses in a specific format. Make sure that your application can support such requests without a major overhaul. This is especially true when integrating APIs with existing systems. • Request Restrictions: Some API providers only allow you to execute requests from specific domains/IPs. Your integration plan needs to address those issues if they exist. Legal Limitations: In addition to the technical limitations mentioned above, some API providers have legal limitations in place in order to make sure that data retrieved via the API is properly used. For example, LinkedIn allows you to fetch a user’s connection information, but it doesn’t allow you to share that data with third parties. Although this is technically possible, it’s legally impossible to do so, and implementing such a solution will only cause your API access to be cut. Knowing those legal limitations in advance will help you properly plan your integration and address any issues earlier in the process. More solutions can be implemented: -
- 10. Osama Mustafa pg. 10 1. Full inclusion of web builder with admin app meaning web builder is basically in the administration app. In this case builder app will automatically have access to all data like product process, photos, etc, which will eliminate any data flow, hence remove communication delays. However, this might also lead to slow app response or even legging at times because its heavy since two apps inclusively combined. Figure 0.1 ARCHITECTURAL DESIGN FOR FULL INCLUSION DESIGN 2. No inclusion of web builder with admin app meaning instead of combining both apps completely one can integrate them on module bases. New web builder functionality can be developed separately without have any connection with admin application. It will be faster in the sense that it will be lighter. However, it will have quite a lot flow of data between admin app and builder module, which might add some communication delays.
- 11. Osama Mustafa pg. 11 Figure 0.2 ARCHITECTURAL DESIGN FOR NO INCLUSION DESIGN 3. Micro services-based integrations of admin app and web builder application. Currently admin app has monolithic backend which has to be converted to micro services and then implement builder as a service a well. It will counter all drawbacks of above designs like slow app response and communication delays. This the best solution with robust solution and opportunity to integrate more features in future. Please visit https://www.ibm.com/cloud/learn/microservices to learn more about micro services. Figure 0.3 ARCHITECTURAL DESIGN FOR MICRO SERVICES-BASED DESIGN
- 12. Osama Mustafa pg. 12 criteria for to determine which design to choose Criteria Full Inclusion Design No Inclusion Design Micro service Design Heavy app Yes No NO Communication delays No Yes NO Expensive to Implement No No Yes Is robust No No Yes Benefits Future Integration No No Yes Require New Technology No No Yes Considerations First and foremost, front end users’ experience should be the priority. As it is quite easy for developers to not consider how their actions might affect user experience when working on back-end project like this. Depending on current architectural design of the shopping site it will differ how much refactoring is required to make it changeable and controllable by a website builder. For example, if it does not follow basic component driven design principles then it can lead to extra work as website itself has to be refactored significantly before connecting it to a website builder. This refactoring of front end could result in some changes to UI which might feel unfamiliar to regular users or even lost functionality in worst case scenario. Another important aspect to consider would be how admin application will integrate with web builder. For example, if web builder and current administrational functionalities are implemented on same page or as described in document as one-page application, then it might cause the application to slow down or even leggy at points. A robust design will avoid these issues and also give opportunity to integrate additional functionalities with ease in future. Last but not least, a separate local environment or testing server should be used for this whole process. It happens quite often then due to some error or mistake the whole website goes down and obviously that’s not great for a live website. Furthermore, for extra security the website should have a backup before start implementing anything.