IFS Applications Architecture

IFS Applications is built using the same principles employed by successful manufacturers - the production and assembly of components. Application solutions are built from business components, which in turn are built from smaller software components that implement the functional aspects of the application. Each component has a well-defined purpose and interface that describes what the component does, but not how it does it. This allows change and evolution within a component without affecting other components.

At the lowest level, components carry out basic functions such as retrieving or updating information in the database. Through successive layers, the business components come to represent complete business entities and activities such as customers and order management. Customers realize the benefits of this approach by choosing only the business components they need. Later, other components may be added or upgraded without disrupting the components already in place. This results in a very stable operational system in spite of change. A company's system can evolve in an orderly way without the "big-bang" approach required by a non component-based, monolithic system.

IFS uses a combination of process modeling and Unified Modeling Language (UML) object modeling to design IFS Applications. The process model describes what the application does; the object model describes the components that make up the application and how they relate to one another.

Contents

• Combining Object Orientation and Service Oriented Architecture
• Multi-tier Architecture
• Integration through IFS Connect
• Windows, UNIX and Linux Platforms

Combining Object Orientation and Service Oriented Architecture

IFS Service-Oriented Component Architecture combines the proven benefits of components and object orientation with the agility and ease of use of service-oriented architectures (SOA).

Object orientation has taken software development forward in the areas of productivity, reliability, and maintainability as a result of the extensive use of interfaces and the tight coupling between information and the functionality that operates on it. However, object orientation has failed to create a straightforward mapping of real-life business processes to software functions. To adapt software to changes and integrations in real-life processes, designers must find the relevant objects, understand their relationships, and figure out which parts of the objects apply to the task at hand. A large amount of detailed knowledge is required to effect change. This creates a time and cost barrier to change.

Process-oriented enterprise computing relies on SOA to address many of the issues in adapting software to change in real-life business processes. SOA applications map well to models and language used to describe real-life processes. In practice, such models as the Business Process Modeling Language (BPML) require the application to expose service interfaces or to be wrapped behind them. Where SOA promotes software functionality to be organized around the business service it provides, rather than which object it operates on, it also becomes easier to add and change process-related business rules in an SOA application.

Although SOA addresses many challenges related to developing agile business software, it suffers from some of the drawbacks that were solved by object orientation. For example, SOA applications generally have more redundant implementations, resulting in quality risks and more difficult maintenance. The many layers of indirection and relatively low level of maturity of development tools mean that performance can suffer - both when using the systems and during development.

IFS has chosen to combine the strengths of both object orientation and SOA in IFS Service-Oriented Component Architecture. An object-oriented core provides the performance, reliability, and quality required in business applications. Combined with a service layer and an SOA API, this makes business processes flexible and easy to use. SOA interface OO implementation

Multi-tier Architecture

IFS Service-Oriented Component Architecture is a layered, multi-tier architecture. Each tier has its own job to do and does it in a standard way with a clear separation from, and interface to, other tiers. Each tier has its own software objects. These are all derived from a common design model but are implemented using different technologies to suit their purpose.

IFS Service Oriented Component Architecture is divided in to three main tiers, with the business logic available through access providers to IFS user interfaces and custom interfaces.

The fully normalized data storage tier is based on the relational database model. This is the prevalent storage technology for today and the foreseeable future. The database server is configured so that no data can be accessed or modified except through the business logic. This guarantees data integrity and prevents "back-door" modification.

The business logic tier is the heart of the application. It implements business knowledge, functionality, and processes. This tier is divided into two sub tiers. The application core sub tier is a high-performance, object-oriented implementation of business-object level and activity-level business logic. The composite services layer is a service-oriented interface and API used for integrations, client access, and process level logic.

The presentation tier provides interaction with human users and client-side applications and devices. The same business logic can serve many different types of interfaces, such as web browsers, PDAs, and PCs. Interfaces in the presentation tier access the functionality of the business logic tier through access providers. Storage Business Logic Presentation

Integration through IFS Connect

IFS Service-Oriented Component Architecture is an open architecture, allowing other applications to access information and invoke functionality in IFS Applications. Message-based business process integration is provided through the IFS web services and the IFS/Connect integration broker.

Deployment View of the Architecture

IFS Applications is built using standard tools and technologies. This gives low total cost of ownership (TCO) and a high degree of freedom in deployment options. IFS supports most platforms, including Microsoft Windows, major UNIX® variants, and Linux®. Because each physical tier in the architecture is separated through standard protocols, it is possible to "mix and match" platforms in a deployment. IFS Applications can be deployed on anything from a single laptop running all components for demo purposes, to multi-server production installations with both database and application servers running in cluster configurations - supporting tens of thousands of concurrent users.

The two principal deployment components are the database and the J2EE application server. This open architecture makes full use of J2EE but avoids proprietary extensions, allowing companies to deploy on a variety of application servers from IBM and  Oracle - or go open source with JBoss, Apache, and Linux. This openness protects against vendor lock-in.

Clients communicate through Http(s) to the web and application servers that in turn access the database instance through JDBC.

The database runs both the storage tier and the application core business logic objects. The J2EE application server runs the services layer business logic objects, the web/portal presentation tier, and integration services. Both the database and the application server can be run in clustered configurations for extreme reliability and scalability. IFS Web Client and portals can be deployed in the main application server or in a separate web application server. A front-end web server such as Microsoft IIS or Apache can also be used as a complement to the application server.

Clients access the business logic predominantly by using Http (or Https using SSL) protocol. This allows easy passage through firewalls, proxies, and other network infrastructure. Port numbers can be configured. Integrations and customer interfaces access the business logic through the same access providers as used by IFS Applications clients, and thus use the same protocols.

Windows, UNIX and Linux Platforms

IFS' ongoing goal is to offer customers a choice of hardware, operating systems, application servers, or integration technology platforms on which to run IFS Applications. Instead of trying to lock customers into a particular technology stack, IFS works actively to enable customers to choose and change over time.

Whereas some enterprises predominantly use Windows platforms, others rely on UNIX or Linux. Consequently, IFS actively works to integrate IFS Applications into both Windows and UNIX/Linux environments. This includes the ability not only to run server-side components on either platform but also to provide plug-and-play support for important infrastructure on the respective platform. For example, IFS Applications can use either Microsoft Active Directory, or any LDAP directory for authentication. The front-end web server can be either Apache or Microsoft IIS. Add-on and integration development can be done using Java/J2EE, COM, or .NET.

Similarly, IFS sees no need to choose between J2EE and .NET - companies can use both. Packaged applications in combination with continuously changing IT environments mean that most organizations will find themselves operating both J2EE and .NET-based applications. Interoperability between the two is both possible and available. IFS respects these facts, and although the server-tier of IFS Applications is implemented according to J2EE architecture, IFS Applications fits well into either environment. This is why IFS Applications supports J2EE technologies such as JSP, JMS, and EJB as well as .NET technologies such as ASP.NET, WinForms®, BizTalk®, and COM+.

Foundation1 Components

Foundation1 is packaged as a product, and like any other IFS solution it consists of a number of product components.

Component Overview and Dependencies

The components inside the Foundation1 Product relates to each other in the following manner:

One component (A) may be dependent on another (B), meaning that component B is required for component A to install and operate. Foundation1 components depend on each other in the following way. An arrow from one component means that it is dependant on the component to which the arrow is pointing.

Component Details

The following table summarizes the information about the physical delivery components included in the Foundation1 Product.

In addition to the components there are other parts of Foundation1 that are often thought of as separate components, although they are in fact packaged inside one of the actual components. These functional areas are listed in the comments column below. Some, but not all, of these parts are sold as individual sales parts.