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.

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

REF, OSGi ORG

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

   4. Business Process Reengineering :

Business process reengineering (BPR) is a management approach aiming at improvements by means of elevating efficiency and effectiveness of the processes that exist within and across organizations. The key to BPR is for organizations to look at their business processes from a “clean slate” perspective and determine how they can best construct these processes to improve how they conduct business.

Different definitions can be found. This section contains the definition provided in notable publications in the field.

Hammer and Champy (1993) define BPR as

    “… the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance, such as cost, quality, service, and speed.”

Thomas H. Davenport (1993), another well-known BPR theorist, uses the term process innovation, which he says

    ”encompasses the envisioning of new work strategies, the actual process design activity, and the implementation of the change in all its complex technological, human, and organizational dimensions”.

Additionally, Davenport (ibid.) points out the major difference between BPR and other approaches to organization development (OD), especially the continuous improvement or TQM movement, when he states:

    “Today firms must seek not fractional, but multiplicative levels of improvement – 10x rather than 10%.”

Finally, Johansson et al. (1993) provide a description of BPR relative to other process-oriented views, such as Total Quality Management (TQM) and Just-in-time (JIT), and state:

    “Business Process Reengineering, although a close relative, seeks radical rather than merely continuous improvement. It escalates the efforts of JIT and TQM to make process orientation a strategic tool and a core competence of the organization. BPR concentrates on core business processes, and uses the specific techniques within the JIT and TQM ”toolboxes” as enablers, while broadening the process vision.”

4.1 Methodology :

Although the labels and steps differ slightly, the early methodologies that were rooted in IT-centric BPR solutions share many of the same basic principles and elements. The following outline is one such model, based on the PRLC (Process Reengineering Life Cycle) approach developed by Guha et.al. (1993).

   1. Envision new processes

         1. Secure management support

         2. Identify reengineering opportunities

         3. Identify enabling technologies

         4. Align with corporate strategy

   2. Initiating change

         1. Set up reengineering team

         2. Outline performance goals

   3. Process diagnosis

         1. Describe existing processes

         2. Uncover pathologies in existing processes

   4. Process redesign

         1. Develop alternative process scenarios

         2. Develop new process design

         3. Design HR architecture

         4. Select IT platform

         5. Develop overall blueprint and gather feedback

   5. Reconstruction

         1. Develop/install IT solution

         2. Establish process changes

   6. Process monitoring

         1. Performance measurement, including time, quality, cost, IT performance

         2. Link to continuous improvement

-> Loop-back to diagnosis

3.1 VPML : Visual Process Modeling Language.

3.2 BPMN : The Business Process Modeling Notation (BPMN) is a standardized graphical notation for drawing business processes in a workflow. The primary goal of BPMN is to provide a standard notation that is readily understandable by all business stakeholders. These business stakeholders include the business analysts who create and refine the processes, the technical developers responsible for implementing the processes, and the business managers who monitor and manage the processes. Consequently BPMN is intended to serve as common language to bridge the communication gap that frequently occurs between business process design and implementation.

3.2.1 BPMN’S SCOPE:

BPMN will be constrained to support only the concepts of modeling that are applicable to business processes. This means that other types of modeling done by organizations for non-business purposes will be out of scope for BPMN. For example, the modeling of the following will not be a part of BPMN:

    * Organizational structures

    * Functional breakdowns

    * Data models

3.2.2 ELEMENTS:

The modeling in BPMN is made by simple diagrams with a small set of graphical elements. It should make it easy for business users as well as developers to understand the flow and the process. The four basic categories of elements are as follows:

    * Flow Objects

          o Events

          o Activities

          o Gateways

    * Connecting Objects

          o Sequence Flow

          o Message Flow

          o Association

    * Swimlanes

          o Pool

          o Lane

    * Artifacts

          o Data Objects

          o Group

          o Annotation

These four categories of elements give us the opportunity to make a simple diagram (BPD). It is also allowed in BPD to make your own type of a Flow Object or an Artifact to make the diagram more understandable. Many types of Diagrams can be created.

3.3 BPEL : is a language for specifying business process behavior based on Web Services. Processes in WS-BPEL export and import functionality by using Web Service interfaces exclusively. WS-BPEL provides a language for the specification of Executable and Abstract business processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces.

In addition to providing facilities to enable sending and receiving messages, the BPEL programming language also supports:

    * A property-based message correlation mechanism

    * XML and WSDL typed variables

    * An extensible language plug-in model to allow writing expressions and queries in multiple languages: BPEL supports XPath 1.0 by default

    * Structured-programming constructs including if-then-elseif-else, while, sequence (to enable executing commands in order) and flow (to enable executing commands in parallel)

    * A scoping system to allow the encapsulation of logic with local variables, fault-handlers, compensation-handlers and event-handlers

    * Serialized scopes to control concurrent access to variables

3.3.1 BPEL Design Goals

There were ten original design goals associated with BPEL:

   1. Define business processes that interact with external entities through Web Service operations defined using WSDL 1.1, and that manifest themselves as Web services defined using WSDL 1.1. The interactions are “abstract” in the sense that the dependence is on portType definitions, not on port definitions.

   2. Define business processes using an XML-based language. Do not define a graphical representation of processes or provide any particular design methodology for processes.

   3. Define a set of Web service orchestration concepts that are meant to be used by both the external (abstract) and internal (executable) views of a business process. Such a business process defines the behavior of a single autonomous entity, typically operating in interaction with other similar peer entities. It is recognized that each usage pattern (i.e. abstract view and executable view) will require a few specialized extensions, but these extensions are to be kept to a minimum and tested against requirements such as import/export and conformance checking that link the two usage patterns.

   4. Provide both hierarchical and graph-like control regimes, and allow their use to be blended as seamlessly as possible. This should reduce the fragmentation of the process modeling space.

   5. Provide data manipulation functions for the simple manipulation of data needed to define process data and control flow.

   6. Support an identification mechanism for process instances that allows the definition of instance identifiers at the application message level. Instance identifiers should be defined by partners and may change.

   7. Support the implicit creation and termination of process instances as the basic lifecycle mechanism. Advanced lifecycle operations such as “suspend” and “resume” may be added in future releases for enhanced lifecycle management.

   8. Define a long-running transaction model that is based on proven techniques like compensation actions and scoping to support failure recovery for parts of long-running business processes.

   9. Use Web Services as the model for process decomposition and assembly.

  10. Build on Web services standards (approved and proposed) as much as possible in a composable and modular manner.

BPEL is an Orchestration language, not a choreography language . The primary difference between orchestration and choreography is executability and control. An orchestration specifies an executable process that involves message exchanges with other systems, such that the message exchange sequences are controlled by the orchestration designer. A choreography specifies a protocol for peer-to-peer interactions, defining, e.g., the legal sequences of messages exchanged with the purpose of guaranteeing interoperability. Such a protocol is not directly executable, as it allows many different realizations (processes that comply with it). A choreography can be realized by writing an orchestration (e.g. in the form of a BPEL process) for each peer involved in it. The orchestration and the choreography distinctions are based on analogies: orchestration refers to the central control (by the conductor) of the behavior of a distributed system (the orchestra consisting of many players), while choreography refers to a distributed system (the dancing team) without centralized control.

   Process Modeling :

The term process model is used in different contexts. For example, in Business process modeling the enterprise process model is often referred to as the business process model. Process models are core concepts in the discipline of Process Engineering.

Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could be done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.

The goals of a process model are to be:

Descriptive :

                o Track what actually happens during a process.

o Takes the point of view of an external observer who looks at the way a process has been performed and determines the improvements that have to be made to make it perform more effectively or efficiently.

Prescriptive :

                 o Defines the desired processes and how they should/could/might be performed.

                 o Lays down rules, guidelines, and behavior patterns which, if followed, would lead to the desired process performance. They can range from strict enforcement to flexible guidance. Explanatory :

                 o Provides explanations about the rationale of processes.

                 o Explore and evaluate the several possible courses of action based on rational arguments.

 o Establish an explicit link between processes and the requirements that the model needs to fulfill.

                 o Pre-defines points at which data can be extracted for reporting purposes.

Meta-process modeling is a type of metamodeling used in software engineering and systems engineering for the analysis and construction of models applicable and useful some predefined problems. Meta-process support the effort of creating flexible process models. The purpose of process models is to document and communicate processes and to enhance the reuse of processes. Thus, processes can be better taught and executed. Results of using meta-process models are an increased productivity of process engineers and an improved quality of the models they produce.

Business process management (BPM) is a method of efficiently aligning an organization with the wants and needs of clients. It is a holistic management approach that promotes business effectiveness and efficiency while striving for innovation, flexibility and integration with technology. As organizations strive for attainment of their objectives, BPM attempts to continuously improve processes – the process to define, measure and improve your processes – a ‘process optimization’ process. Business process management life-cycle : Design, Modeling, Execution, Monitoring, Optimization.

1.    Process :

Process is “Ordered set of activities to solve a problem”. Process (computing), a running program; a task to be executed, especially one which is largely self-contained.

1.2 Process Concept in Methodologies:

Dataflow Diagram: A data flow diagram (DFD) is a graphical representation of the “flow” of data through an information system. A data flow diagram can also be used for the visualization of data processing (structured design). It is common practice for a designer to draw a context-level DFD first which shows the interaction between the system and outside entities. This context-level DFD is then “exploded” to show more detail of the system being modeled.

• The system designer makes a context level DFD, which shows the interaction (data flows) between the system (represented by one process) and the system environment (represented by terminators).
• The system is decomposed in lower level DFD (Zero) into a set of processes, data stores, and the data flows between these processes and data stores.
• Each process is then decomposed into an even lower level diagram containing its subprocesses.
• This approach then continues on the subsequent subprocesses, until a necessary and sufficient level of detail is reached which is called the primitive process (aka chewable in one bite).

UML:  In the field of software engineering, the Unified Modeling Language (UML) is a standardized visual specification language for object modeling. UML is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model. UML is not restricted to modeling software. UML is also used for business process modeling, systems engineering modeling and representing organizational structures. The Systems Modeling Language (SysML) is a Domain-Specific Modeling language for systems engineering that is defined as a UML 2.0 profiles.

Structure diagrams emphasize what things must be in the system being modeled:

        * Class diagram

        * Component diagram

        * Composite structure diagram (added in UML 2.x)

        * Deployment diagram

        * Object diagram

        * Package diagram

Behavior diagrams emphasize what must happen in the system being modeled:

        * Activity diagram

        * State Machine diagram

        * Use case diagram

Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

        * Communication diagram

        * Interaction overview diagram (added in UML 2.x)

        * Sequence diagram

        * Timing diagram (added in UML 2.x)

Concepts: UML uses many concepts from many sources. For a definitive list, consult the glossary of Unified Modeling Language terms. Notable concepts are listed here.

• For structure : Actor, attribute, class, component, interface, object, package
• For behavior :  Activity, event, message, method, operation, state, use case.
• For relationships : Aggregation, association, composition, dependency, generalization (or inheritance).
• Other concepts :

        * Stereotype. It qualifies the symbol it is attached to.

        * Multiplicity notation which corresponds to database modeling cardinality, e.g., 1, 0..1, 1..*

        * Role

COSEML: Component Oriented Software Engineering (COSE) seems to be the future of software engineering. Currently, COSEML is the only modeling language that completely supports the COSE approach. Abstract decomposition of the system and their representing components are shown in a hierarchy diagram to support the COSE process model. In COSEML, only static modeling is supported through this single diagram. However, software is about behavior and static modeling is not sufficient to describe the system.

Activitiy Diagram: In the Unified Modeling Language, an activity diagram represents the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.

Activity diagrams are typically used for business process modeling. They consist of:

    * Initial node.

    * Activity final node.

    * Activities

The starting point of the diagram is the initial node, and the activity final node is the ending. An activity diagram can also have zero or more activity final nodes. Inbetween activities are represented by rounded rectangles.

Workflow : The term is used in computer programming to capture and develop human to machine interaction. Workflow software aims to provide end users with an easier way to orchestrate or describe complex processing of data in a visual form, much like flow charts but without the need to understand computers or programming.

“Great Software Debates”, Alan M. Davis states in the chapter “Requirements”, subchapter “The Missing Piece of Software Development”:

“ Students of engineering learn engineering and are rarely exposed to finance or marketing. Students of marketing learn marketing and are rarely exposed to finance or engineering. Most of us become specialists in just one area. To complicate matters, few of us meet interdisciplinary people in the workforce, so there are few roles to mimic. Yet, software product planning is critical to the development success and absolutely requires knowledge of multiple disciplines.”

Sun Microsystems, Inc. announced it has completed the acquisition of MySQL AB, developer of the world’s most popular open source database, for approximately $1 billion in total consideration. Sun also unveiled the immediate availability of MySQL’s complete portfolio of products and enterprise services backed by its 17,000-strong global sales and services organization and its extensive international network of authorized distribution channels. Sun now provides a single, secure choice for customers and developers seeking to put MySQL into deployment on a global basis. Users can get started with free downloads at dev.mysql.com/downloads.

There are a variety of differences and similarities between the Eclipse and NetBeans development platforms as IDEs for Java development. Choice seems to largely be a matter of preference, as the feature sets are mostly convergent.

Project Similarities

Both tools are:

* Supported plugin model
* Java IDE with tons of bells and whistles
* Java 5 syntax support

Eclipse

Eclipse has a strong open source community following and plugin community.

* Directly supported by Eclipse Foundation, including IBM
* Strong plugin support from third parties
* SWT test bed
* Built and distributed on GCJ/Classpath by several Linux distros.

NetBeans

NetBeans has the direct support of Sun and has made strong efforts to be a competitive Java development platform to Eclipse.

* Directly supported by Sun
* Good J2EE/J2ME support
* Extras for integration with Solaris