Software Engineering

by Kerem Kosaner

Model-View-Controller Pattern

Posted by keremkosaner on 5 September 2008

Model-view-controller (MVC) is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. In MVC, the model represents the information (the data) of the application and the business rules used to manipulate the data; the view corresponds to elements of the user interface such as text, checkbox items, and so forth; and the controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.

Model-view-controller is both an architectural pattern and a design pattern, depending on where it is used.

As an architectural pattern

It is common to split an application into separate layers that run on different computers: presentation (UI), domain logic, and data access. In MVC the presentation layer is further separated into view and controller.

MVC is often seen in web applications, where the view is the actual HTML page, and the controller is the code that gathers dynamic data and generates the content within the HTML. Finally, the model is represented by the actual content, usually stored in a database or in XML nodes, and the business rules that transform that content based on user actions.

Though MVC comes in different flavors, control flow generally works as follows:

1. The user interacts with the user interface in some way (e.g. presses a button).
2. A controller handles the input event from the user interface, often via a registered handler or callback.
3. The controller notifies the model of the user action, possibly resulting in a change in the model’s state. (e.g. controller updates user’s Shopping cart).
4. A view uses the model (indirectly) to generate an appropriate user interface (e.g. the view produces a screen listing the shopping cart contents). The view gets its own data from the model. The model has no direct knowledge of the view.
5. The user interface waits for further user interactions, which begins the cycle anew.

Some implementations such as the w3c XForms also use the concept of a dependency graph to automate the updating of views when data in the model changes.

By decoupling models and views, MVC helps to reduce the complexity in architectural design, and to increase flexibility and reuse.

As a design pattern

MVC encompasses more of the architecture of an application than is typical for a design pattern.

Model
The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating whether today is the user’s birthday, or the totals, taxes, and shipping charges for shopping cart items).
Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.
View
Renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.
Controller
Processes and responds to events, typically user actions, and may invoke changes on the model.

Posted in Design Patterns | Leave a Comment »

OSGi : Open Services Gateway initiative

Posted by keremkosaner on 5 August 2008

The OSGi Alliance is a worldwide consortium of technology innovators that advances a proven and mature process to assure interoperability of applications and services based on its component integration platform. The OSGi Service Platform is delivered in many Fortune Global 100 company products and services and in diverse markets including enterprise, mobile, home, telematics and consumer.

The alliance provides specifications, reference implementations, test suites and certification to foster a valuable cross-industry ecosystem. Member companies collaborate within an egalitarian, equitable and transparent environment and promote adoption of OSGi technology through business benefits, user experiences and forums.

The core component of the OSGi Specifications is the OSGi Framework. The Framework provides a standardized environment to applications (called bundles). The Framework is divided in a number of layers.

* L0: Execution Environment
* L1: Modules
* L2: Life Cycle Management
* L3: Service Registry A ubiquitous security system is deeply intertwined with all the layers.

The OSGi specifications are so widely applicable because the platform is a small layer that allows multiple Java™ based components to efficiently cooperate in a single Java Virtual Machine (JVM). It provides an extensive security model so that components can run in a shielded environment. However, with the proper permissions, components can reuse and cooperate, unlike other Java application environments. The OSGi Framework provides an extensive array of mechanisms to make this cooperation possible and secure.

The presence of OSGi technology-based middleware in many different industries creates a large software market for OSGi software components. The rigid definition of the OSGi Service Platform enables components that can run on a variety of devices, from very small to very big.

Adoption of the OSGi specifications can therefore reduce software development costs as well as provide new business opportunities.

Members of the OSGi Alliance

Aplix Corporation
Deutsche Telekom
Electricitié de France (EDF)
Ericsson Mobile Platforms AB
GigaSpaces Technologies
Harman/Becker Automotive Systems GmbH
Hitachi, Ltd.
IBM Corporation
Industrial Technology Research Institute
IONA Technologies
Jayway AB
Makewave
Mitsubishi Electric Corporation
Motorola, Inc.
NEC Corporation
Nokia Corporation
NTT
Oracle Corporation
ProSyst Software GmbH
Red Hat
Samsung Electronics Co., Ltd.
SAP AG
Siemens AG
Software AG
SpringSource
Sprint
Sun Microsystems, Inc.
Telcordia Technologies, Inc.
TIBCO Software Inc.
Telefónica I+D
REF, OSGi ORG

Posted in Software Eng. | Tagged: | Leave a Comment »

SOA Tools Platform Project

Posted by keremkosaner on 22 April 2008

The mission of the SOA Tools Platform (STP) project is to build frameworks and exemplary extensible tools that enable the design, configuration, assembly, deployment, monitoring, and management of software designed around a Service Oriented Architecture (SOA). The project is guided by the values of transparency, extensibility, vendor neutrality, community collaboration, agile development, and standards-based innovation. STP leverages the Service Component Architecture specification (SCA) as its model. STP is a natural complement to other Eclipse projects, such as the Web Tools Platform and Data Tools Platform, and reuses, as appropriate, components from these projects

Active Components Are :

STP SOA System (SOAS)
STP Service Creation (SC)
STP BPEL 2 Java (B2J)
STP BPMN (BPMN)
The STP Intermediate Metamodel (STP-IM)
STP Policy Editor (POLICY)
STP SCA (SCA

Posted in Process Modeling | Leave a Comment »