It is important that the architecture is built to ensure that that the application can expose its business functionality to external applications. One possible use case could be the requirement for a third-party to update data within the application, such as the status of a customer order. Such functionality would give users the ability to accurately predict when an order would be available for a customer to collect, improving the level of service that they can offer their customers.
To expose the business functionality in a 3-tier web application to external applications the following steps should be taken:
Follow the principle of ‘separation of concerns’ to ensure that all presentation, business and data access logic are clearly separated into different layers.
Ensure that no business logic is implemented exclusively in client-side code. In theory business logic should only be encapsulated in server-side code, but in reality non-functional factors such as performance, scalability and usability dictate that it sometimes needs to be in client-side code. This is acceptable if this business logic is also implemented in server-code code. If this is not the case external applications need to replicate this business logic which introduces potential security, maintenance and ease of use issues.
Ensure external applications are ‘first class citizens’ by providing them access to exactly the same functional APIs as the internal presentation layer, though not necessarily allowing access to them in the same way. Internal presentation logic could access business functionality via direct in-proc calls to the business components themselves or via other technologies such as .NET Remoting or even web services.
A single API will minimise maintenance costs. Individual external applications can be granted or denied access to specific services using the same granular user access-based security model that provides authentication, authorisation and auditing support to normal application users.
Implement a ‘thin’ service layer on top of the business logic. In a simple scenario this layer should be focused on creating instances of a single business component and then calling a single method on this component to exchange data with an external application. In addition, simple formatting can be performed depending on the type of external application that will consume the services. Modern web applications often expose their functionality using XML-based messaging protocols such as SOAP, or increasingly more lightweight REST protocols that often return results as JSON.
In more complicated situations where a higher level of functionality needs to be exposed, for example, to simplify how the functionality is accessed, a service layer could contain calls to multiple business components all encapsulated within a single transactional boundary.
You must log in to post a comment.