At Kynetia, we approach all of our developments from the perspective of the three layers that make up the application:

• Front-end - This is the presentation layer and is related with the user interface.
• Middleware - This is the level at which the application logic resides and usually integrations with other services.
• Back-end - This is the level at which data normally resides, either in conventional data bases, in transactional or legacy systems, or in real-time systems.

In each layer, we provide our clients with a range of services depending on application needs.

Front-end

While the front-end layer includes a significant client server component, Kynetia approaches development in this area from the standpoint of User-centered Interface Design.

Middleware

Middleware Layers

Services in the middleware layer are related with the creation of the business logic and encapsulation in reusable services. This layer also includes integration services.

All developments in the middleware layer are supported by the software development process described in Software Development Methodology.

Enterprise Service Bus (Services Wrapping – SOA)
Where clients have not developed an Enterprise Service Bus (ESB), one of the keys to middleware is to provide the support for the services created within the application.

The ESB stands above specific services in the application and is a strategic point of the Enterprise Architecture.

The key characteristics of the ESB are:

• Invocation. Support for synchronous and asynchronous transport protocols.
• Routing. Accessible service directions.
• Mediation. Adaptation services, protocol translation, data transformation and translation.
• Process orchestration. Definition of business processes.
• Complex event processing. Interpretation of events, correlation, publication/subscription, pattern matching.
• Service quality. Security (encryption and signatures), transactionability, reliability.
• Management. Monitoring, audit, logging, measurement, administration, etc.

ESB is, then, much more than a mere catalogue of services, and at least the features enumerated must be included.

Services
Depending on the Enterprise Architecture established, certain business rules and workflows need to be encapsulated in the form of services.

Kynetia uses SOA as a standard environment in which to model and provide the services developed. We also use SOA as a mechanism for the consumption of the services already existing in the EA.

Unquestionably, the most complicated part of the process of functional granularization in the service is to establish the ideal size of grains. This means answering the question of what is the optimum size for the conversion of a business rule into a service. A sound analysis of this issue from the architecture standpoint is key to the successful creation of services, because a very small size will waste time in the creation of permanent service workflows, while maintenance is more expensive. If the grain is too large, however, reusability will be affected and a part of the attraction of the method will be lost.

For example, the sale of airline tickets is one of the business rules of an airline company. This business rule is associated with various functionalities, such as obtaining customer data, allowing the choice of seats, reserving the seats selected, charging for the ticket and delivering the ticket. Each of these functions, meanwhile, has its own sub-functions.

Associated with the function allowing the choice of seats we find, for example, the sub-functions of consulting available seats, obtaining the seat required for the customer and storing the booking on the data base to ensure that the seat is not reserved by another customer. If we were to break these down further, moreover, we would find a host of other sub-functions.

The key question, then, is what is the optimum level to encapsulate the functions in a service? Should the service be the sale of airline tickets? Or should there be more services, with the result that consulting seat availability, obtaining the required seat for the customer and storing the booking on a data base would constitute three different services?
These are not easy questions, but the answers hold the keys to success. Consequently, it is necessary to examine a whole range of factors in order to reach the right decision.

While the creation of SOA services has come to be seen as the overarching standard that allows applications to utilize software services beyond the frontiers of the firm itself (normally wrapped, in turn, as Web Services), Kynetia’s services allow the use of legacy technologies such as CORBA, RMI and RPC, where necessary.

Business Logic and Integration
We model both the business logic and the workflow responsible for bringing together the necessary components to give rise to business processes based on the pattern modeling framework chosen.

Workflow managers play a key role in business process optimization and automation trends. The variability of business, emerging opportunities and continual competition mean that the rules governing business processes are exposed to ongoing change. At the same time, room must be left to manage these change at the non-technical level to provide business areas with the flexibility they need to defend the organization in an ever more competitive and dynamic environment.

The workflow managers located in the application’s middleware allow business processes to be modeled, parametized and automated, so they can be managed from a software tool. The different systems and applications supporting these business processes are integrated within the workflow managers to unify and control the flow between different phases of the processes and activities. Workflow tools provide users with the following functions:

• Control and monitoring, allowing the identification of bottlenecks, inefficiencies, present and future needs, etc.
• Simulation of processes, varying the structure and observing their behavior and effects on production resources.
• Orchestration: Easy modification of processes, changing phases, capacities, data flows, etc.
• Identification of opportunities for improvement arising from inefficiencies or the underuse of resources in the automated business processes.

Workflow managers are essential to the implementation of SOA architectures and continuous improvement processes are an essential part of both commercial solutions (Webmethods, IBM, Microsoft, Oracle and iLog) and custom or industry-specific solutions. The languages used to support process definition (BPEL, XPDL, XLANG, etc.) allow the creation and management of processes in these tools without the need for technical know-how or dependence on external advisers.

As mentioned above, integration with other applications using software services is a key part of the business logic. There is little point in defining a business rule if that has already been developed in some other part of the firm’s infrastructure. In this case, the key is to use the service. Consequently, it is essential arrive at a sound definition of the Enterprise Architecture in order to save development costs by avoiding the need to develop a new business logic, reusing existing services instead.

Where a given business rule has not been modeled in any other part of the firm’s infrastructure, it is necessary to decide whether or not the rule should be encapsulated in a reusable service, based on the Governance models established in the Enterprise Architecture, and made available to other parts of the same application, or even to external applications.

Patterns
Kynetia uses standard frameworks to develop the business models. These model common design patterns, thereby saving development costs for our clients and leaving room for much more dynamic application updates, at the same time as providing a standard environment for the development of the business logic and its encapsulation in services.

The patterns are a basic design element for the creation of an application that can be adapted to the changing business needs of our clients. Though isolated patterns may be chosen, these are in fact normally established through the Enterprise Architecture, as is the case in almost all development areas.

Infrastructure
At Kynetia we work with the three infrastructure technologies commonly used in business environments. These are Java (Java EE), Microsoft .Net and LAMP (Linux, Apache, MySQL, PHP/Pyton/Pearl). We have wide experience with all of these technologies in major projects.

We have an extensive track-record in the Java world working with both commercial server applications (such as IBM Websphere and BEA WebLogic) and Open Source environments like JBoss and Enhydra.

Infrastructure selection normally forms part of the Enterprise Architecture area, and subsequent development then goes ahead using the Governance resources defined in the architecture.

Back-end

The back-end layer is where the firm’s whole data architecture is located. Like the rest of the layers, the development strategy forms part of the policy defined in the Enterprise Architecture. In the case of Custom Software Development to support core business processes, the data model is designed in line with the data patterns defined in the EA. These are then passed on directly to the Enterprise Data Bus (or EDB).

We may, therefore, distinguish between two different data levels:

• Enterprise Standard Data
• Enterprise Data Bus

Enterprise Standard Data
This is the data level that is directly modeled as the data base driver based on the standards defined in the Enterprise Architecture.

Kynetia has wide experience of complex data models based on metadata which support highly flexible applications and map the main market data drivers such as Oracle, MS SQL, Sybase, Informix, MySQL, etc.

Enterprise Data Bus
It is not clear at present whether standard data access should be another service located in the Enterprise Service Bus (ESB) or whether this component is not in fact much closer to the data source. Kynetia works with both approaches, although we believe the latter is more efficient, because access is practically direct if the EDB is closer to the data source, and this considerably improves performance.

This approach to the solution may be more interesting in many cases, but in others it is necessary to use data access as another ESB service, since many applications already contain a specifically developed data service, and changing it could cause significant extra problems. For this reason, the data design pattern is often not used when the SOA is implemented.