RSS
Showing posts with label CHAPTER 13. Show all posts
Showing posts with label CHAPTER 13. Show all posts

MIDDLEWARE


·        Computer software that connects software components or some people and their applications.

·        Sometimes called plumbing because it connects two applications and passes data between them.

·        The software consists of a set of services that allows multiple processes running on one or more machines to interact.

·        This technology evolved to provide for interoperability in support of the move to coherent distributed architectures, which are most often used to support and simplify complex distributed applications.

·        Includes web servers, application servers, and similar tools that support application development and delivery.

·        Especially integral to modern information technology based on XML, SOAP, Web services, and service-oriented architecture.

·        Middleware sits "in the middle" between application software that may be working on different operating systems.

·        Examples include EAI software, telecommunications software, transaction monitors, and messaging-and-queuing software.

·        Distinction between operating system and middleware functionality is, to some extent, arbitrary.

·        Core kernel functionality can only be provided by the operating system itself, some functionality previously provided by separately sold middleware is now integrated in operating systems.

·        Typical example is the TCP/IP stack for telecommunications, nowadays included in virtually every operating system.

·        In simulation technology, middleware is generally used in the context of the high level architecture (HLA) that applies to many distributed simulations.
·        A layer of software that lies between the application code and the run-time infrastructure.

Use of middleware

Middleware services provide a more functional set of application programming interfaces to allow an application to:
  • Locate transparently across the network, thus providing interaction with another service or application
  • Filter data to make them friendly usable or public via anonymization process for privacy protection (for example)
  • Be independent from network services
  • Be reliable and always available
  • Add complementary attributes like semantics
when compared to the operating system and network services.

Types of middleware

·        Message-oriented Middleware

-          Message-oriented middleware is middleware where transactions or event notifications are delivered between disparate systems or components by way of messages, often via an enterprise messaging system.

·        Enterprise messaging system

-          An enterprise messaging system is a type of middleware that facilitates message passing between disparate systems or components in standard formats, often using XML, SOAP or web services.

·        Message broker

-          Part of an enterprise messaging system, message broker software may queue, duplicate, translate and deliver messages to disparate systems or components in a messaging system.

·        Enterprise service bus

-          Enterprise Service Bus (ESB) is defined by the Burton Group as "some type of integration middleware product that supports both MOM and Web services".

·        Content-centric Middleware

-          Content-centric middleware provides a simple provide/consume abstraction through which applications can issue requests for uniquely identified content, without worrying about where or how it is obtained. Juno is one example, which allows applications to generate content requests associated with high-level delivery requirements. The middleware then adapts the underlying delivery to access the content from the source that is best suited to matching the requirements. This is therefore similar to Publish/subscribe middleware, as well as the Content-centric networking paradigm.

·        Hurwitz classification system

-          Judith Hurwitz created a classification system for middleware in her article Sorting Out Middleware.

·        Remote procedure call

-          With Remote Procedure Call middleware, a client makes calls to procedures running on remote systems. Can be asynchronous or synchronous.

·        Message oriented Middleware

-          With Message Oriented Middleware, messages sent to the client are collected and stored until they are acted upon, while the client continues with other processing.

·        Object Request Broker

-          With Object Request Broker middleware, it is possible for applications to send objects and request services in an object-oriented system.

·        SQL-Oriented Data Access

-          SQL-oriented Data Access is middleware between applications and database servers.

·        Embedded middleware

-          Embedded middleware provides communication services and integration interface software/firmware that operates between embedded applications and the real time op.

·        Other

            Other sources include these additional classifications:
-          Transaction processing monitors — Provides tools and an environment to develop and deploy distributed applications.
-          Application servers — software installed on a computer to facilitate the serving (running) of other applications.

References:
http://en.wikipedia.org/wiki/Middleware

Rapid Application Developement


Rapid Application Development (RAD)
·        RAD introduced by James Martin in 1991.

·        Type of software development methodology uses minimal planning in favor of rapid prototyping.

·        The "planning" of software developed using RAD is interleaved with writing the software itself.

·        The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.

·        Structured techniques and prototyping are especially used to define users' requirements and to design the final system.

·        The development process starts with the development of preliminary data models and business process models using structured techniques.

·        RAD approaches may entail compromises in functionality and performance in exchange for enabling faster development and facilitating application maintenance.

·        All types of RAD have the potential for providing a good framework for faster product development with improved software quality, but successful implementation and benefits often hinge on project type, schedule, software release cycle and corporate culture.

This table contains a high-level summary of some of the major types of RAD and their relative strengths and weaknesses.
Agile software development (Agile)

Pros
Minimizes feature creep by developing in short intervals resulting in miniature software projects and releasing the product in mini-increments.
Cons
Short iteration may add too little functionality, leading to significant delays in final iterations. Since Agile emphasizes real-time communication (preferably face-to-face), using it is problematic for large multi-team distributed system development. Agile methods produce very little written documentation and require a significant amount of post-project documentation.
Extreme Programming (XP)

Pros
Lowers the cost of changes through quick spirals of new requirements. Most design activity occurs incrementally and on the fly.
Cons
Programmers must work in pairs, which is difficult for some people. No up-front “detailed design” occurs, which can result in more redesign effort in the long term. The business champion attached to the project full time can potentially become a single point of failure for the project and a major source of stress for a team.
Joint application design (JAD)

Pros
Captures the voice of the customer by involving them in the design and development of the application through a series of collaborative workshops called JAD sessions.
Cons
The client may create an unrealistic product vision and request extensive gold-plating, leading a team to over- or under-develop functionality.
Lean software development (LD)

Pros
Creates minimalist solutions (i.e., needs determine technology) and delivers less functionality earlier; per the policy that 80% today is better than 100% tomorrow.
Cons
Product may lose its competitive edge because of insufficient core functionality and may exhibit poor overall quality.
Rapid application development (RAD)

Pros
Promotes strong collaborative atmosphere and dynamic gathering of requirements. Business owner actively participates in prototyping, writing test cases and performing unit testing.
Cons
Dependence on strong cohesive teams and individual commitment to the project. Decision making relies on the feature functionality team and a communal decision-making process with lesser degree of centralized PM and engineering authority.
Scrum

Pros
Improved productivity in teams previously paralyzed by heavy “process”, ability to prioritize work, use of backlog for completing items in a series of short iterations or sprints, daily measured progress and communications.
Cons
Reliance on facilitation by a master who may lack the political skills to remove impediments and deliver the sprint goal. Due to relying on self-organizing teams and rejecting traditional centralized "process control", internal power struggles can paralyze a team.



Table 1: Pros and Cons of various RAD types

Reference:
http://en.wikipedia.org/wiki/Rapid_application_development

RAD GAME TOOLS      
·        RAD Game Tools is privately-held company owned by Jeff Roberts and Mitch Soule based in Kirkland, Washington that develops video and computer game software technologies which are licensed primarily by video game companies.
·        Unusual among middleware companies as they generally hire one specific person to write, document and support each single product.

References:
http://en.wikipedia.org/wiki/RAD_Game_Tools