The course is part of this learning path
In this course, we will learn the concepts of microservice and spring framework with a focus on design patterns.
- Learn about various design patterns
- Beginner Java developers
- Java developers interested in learning how to Build and Deploy RESTful Web Services
- Java Developers who want to develop web applications using the Spring framework
- Java Developers who want to develop web applications with microservices
- Java Developers who wish to develop Spring Boot Microservices with Spring Cloud
- Basic Java knowledge
Hello dear friends. In this video, we will examine The Business Delegate Pattern, let's begin. The Business Delegate Pattern is one of the core Java EE design patterns. It's used in order to decouple or reduce the coupling between the presentation tier, and business services. It's also required to hide the details of implementation of the services. Meaning it is needed to remove the function of lookup in the business tier code within the presentation tier code. It's basically used to reduce communication, or remote look up functionality to business tier code in presentation tier code. The Business Delegate Pattern adds an abstraction layer between presentation and business tiers. By using the pattern, we gain loose coupling between the tiers, and encapsulate knowledge about how to locate, connect to, and interact with the business objects that make up the application.
As you can see in the UML, there are three participants. Business delegate is a single entry point class for client entities to provide access to business service methods. The business service is a business-tier component, such as an enterprise bean or a JMS component, that provides the required service to the client. The business delegate uses the lookup service to locate the business service. The lookup service encapsulates the implementation details of business service lookup. The business delegates role is to provide control and protection for the business service. The business delegate can expose two types of constructors to clients. One type of request instantiates the business delegate without an ID, while the other instantiates it with an ID, where ID is a string version of the reference to a remote object, such as EJB home or EJB object.
When initialized without an ID, the business delegate requests the service from the lookup service, typically implemented as a service locator, which returns the service factory such as EJB home. The business delegate requests that the service factory locate, create, or remove a business service, such as an enterprise bean. Business delegate reduces coupling between presentation tier clients and business services. The business delegate hides the underlying implementation details of the business service. Now, let's create a project using the business delegate pattern. Create a new project and name it 'Business Delegate.' First, we need a business service as interface. We will define the process method. Afterwards, let's define two concrete classes implementing this interface, EJB. We will override method, now JMS. Override for JMS. Let's define a lookup service. The lookup service object should provide the relative business implementations, and business object access to the business delegate logic. Now, we can define our business delegate. Also we need a client to act as an access point to the business services. Let's use this pattern. First, define delegate. Now set EJB to service. Now set delegate to client. Change with JMS. Done, let's look at the results. The first process is EJB, and the second one is JMS. We have now finished examining this pattern. In the next video, we will look into the composite entity pattern. So, I'll see you there my friends.
OAK Academy is made up of tech experts who have been in the sector for years and years and are deeply rooted in the tech world. They specialize in critical areas like cybersecurity, coding, IT, game development, app monetization, and mobile development.