Revision control

Version control systems are most commonly stand-alone applications, but revision control is also embedded in various types of software like word processors (e.g. Microsoft Word, OpenOffice.org Writer, KOffice, Pages, Google Docs), spreadsheets (e.g. OpenOffice.org Calc, Google Spreadsheets, Microsoft Excel), and in various content management systems. Integrated revision control is a key feature of wiki software packages such as MediaWiki, DokuWiki, TWiki, etc. In wikis, revision control allows for the ability to revert a page to a previous revision, which is critical for allowing editors to track each other’s edits, correct mistakes, and defend public wikis against vandalism and spam.

The Revision Control System (RCS) is a software implementation of revision control that automates the storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised frequently, for example programs, documentation, procedural graphics, papers, and form letters. RCS is also capable of handling binary files, though with reduced efficiency and efficacy. Revisions are stored with the aid of the diff utility.

RCS was initially developed in the 1980s by Walter F. Tichy while he was at Purdue University as a free and more evolved alternative to the then-popular Source Code Control System (SCCS). It is now part of the GNU Project but is still maintained by Purdue University.

RCS operates only on single files, has no way of working with an entire project. Although it provides branching for individual files, the version syntax is cumbersome. Instead of using branches, many teams just use the built-in locking mechanism and work on a single head branch.

A simple system called CVS was developed capable of dealing with RCS files en masse, and this was the next natural step of evolution of this concept, as it “transcends but includes” elements of its predecessor. CVS was originally a set of scripts which used RCS programs to manage the files. It no longer does that, rather it operates directly on the files itself.

A later higher-level system PRCS^[1] uses RCS-like files but was never simply a wrapper. In contrast to CVS, PRCS improves the delta compression of the RCS files using Xdelta.

In single-user scenarios, such as server configuration files or automation scripts, RCS may still be the preferred revision control tool as it is simple and no central repository needs to be accessible for it to save revisions. This makes it a more reliable tool when the system is in dire maintenance conditions. Additionally, the saved backup files are easily visible to the administration so the operation is straightforward. However, there are no built-in tamper protection mechanisms (that is, users who can use the RCS tools to version a file also, by design, are able to directly manipulate the corresponding version control file) and this is leading some security conscious administrators to consider client/server version control systems that restrict users’ ability to alter the version control files.

Some wiki engines, including TWiki, use RCS for storing page revisions.

Basics of RCS

The Revision Control System (RCS) was designed by Walter Tichy of the Department of Computer Science at Purdue University. RCS is a software tool for UNIX systems which lets people working on the system control “multiple revisions of text … that is revised frequently, such as programs or documentation.” [TIC82] It can be applied to development situations of all sorts, including the creation of documents, drawings, forms, articles, and of course, source code.

In a typical software development environment, many developers will be engaged in work on one code base. If everyone was to be allowed to edit and modify any development item whenever they felt like it, it should be obvious that chaos would tend to result while little productive work got done. Instead of suffering under such an environment, most developers prefer to implement version control tools such as the one described here.

Version control tools allow an individual developer to maintain control over an item such as a source file while they implement and test changes to it. During this period, while the file is “checked out”, no one else is allowed to modify it. When the developer is satisfied that the changes have been implemented successfully and that they broke nothing in the meantime, the file may be “checked in” to the baseline database for use by everyone. The specifics of this process for RCS will be discussed in the tutorial proper.

Earlier implementations of version control tools include AT&T’s SCCS, IBM’s CLEAR/CASTER, and DEC’s CMS. RCS, implemented in 1982, attempts to fix several shortcomings the author found in previous tools.

What is CVS?

CVS is a version control system. Using it, you can record the history of your source files. For example, bugs sometimes creep in when software is modified, and you might not detect the bug until a long time after you make the modification. With CVS , you can easily retrieve old versions to see exactly which change caused the bug. This can sometimes be a big help.

You could, of course, save every version of every file you have ever created. This would, however, waste an enormous amount of disk space. CVS stores all the versions of a file in a single file in a clever way that only stores the differences between versions. CVS also helps you if you are part of a group of people working on the same project. It is all too easy to overwrite each other’s changes unless you are extremely careful. Some editors, like GNU Emacs, try to make sure that two people never modify the same file at the same time. Unfortunately, if someone is using another editor, that safeguard will not work. CVS solves this problem by insulating the different developers from each other. Every developer works in his own directory, and CVS merges the work when each developer is done. CVS started out as a bunch of shell scripts written by Dick Grune and posted to the newsgroup comp.sources.unix in the volume 6 release of July 1986. While no actual code from these shell scripts is present in the current version of CVS , many of the CVS conflict resolution algorithms come from them.

In April 1989, Brian Berliner designed and coded CVS . Jeff Polk later helped Brian with the design of the CVS module and vendor branch support.

Features

CVS uses a client-server architecture: a server stores the current version(s) of a project and its history, and clients connect to the server in order to “check out” a complete copy of the project, work on this copy and then later “check in” their changes. Typically, the client and server connect over a LAN or over the Internet, but client and server may both run on the same machine if CVS has the task of keeping track of the version history of a project with only local developers. The server software normally runs on Unix (although at least the CVSNT server supports various flavors of Microsoft Windows and Linux), while CVS clients may run on any major operating-system platform.

Several developers may work on the same project concurrently, each one editing files within their own “working copy” of the project, and sending (or checking in) their modifications to the server. To avoid the possibility of people stepping on each other’s toes, the server will only accept changes made to the most recent version of a file. Developers are therefore expected to keep their working copy up-to-date by incorporating other people’s changes on a regular basis. This task is mostly handled automatically by the CVS client, requiring manual intervention only when a conflict arises between a checked-in modification and the yet-unchecked local version of a file.

If the check-in operation succeeds, then the version numbers of all files involved automatically increment, and the CVS-server writes a user-supplied description line, the date and the author’s name to its log files. CVS can also run external, user-specified log processing scripts following each commit. These scripts are installed by an entry in CVS’s loginfo file, which can trigger email notification or convert the log data into a Web-based format.

Clients can also compare versions, request a complete history of changes, or check out a historical snapshot of the project as of a given date or as of a revision number. Many open-source projects allow “anonymous read access”, a feature pioneered by OpenBSD. This means that clients may check out and compare versions with either a blank or simple published password (e.g., “anoncvs”); only the check-in of changes requires a personal account and password in these scenarios.

Clients can also use the “update” command in order to bring their local copies up-to-date with the newest version on the server. This eliminates the need for repeated downloading of the whole project.

CVS can also maintain different “branches” of a project. For instance, a released version of the software project may form one branch, used for bug fixes, while a version under current development, with major changes and new features, can form a separate branch.

CVS uses delta compression for efficient storage of different versions of the same file. The implementation favors files with many lines (usually text files) – in extreme cases the system may store individual copies of each version rather than deltas.

Distributed Concurrent Versions System

• any desired number of programmers concurrently developing an arbitrary number of development lines in workspaces isolated from each other
• worldwide and transparent distribution of repositories via secure connection; efficient replication and quick local server access for all operations
• integration in nearly all current GUIs and IDEs through the use of the default CVS protocol between the CVS clients and DCVS servers
• the functionality of snapshots replacing the more susceptible tags
• the functionality of change sets as powerful means for structuring code development and release/change management
• configurable e-mail notifications (add on)
• hooks for process control
• user control and authentication either by local system specific defaults or by distributed LDAP servers
• installation packages for all popular operation systems

Version Control with Subversion

Subversion is a free/open-source version control system. That is, Subversion manages files and directories over time. A tree of files is placed into a central repository. The repository is much like an ordinary file server, except that it remembers every change ever made to your files and directories. This allows you to recover older versions of your data, or examine the history of how your data changed. In this regard, many people think of a version control system as a sort of “time machine”.

Subversion can access its repository across networks, which allows it to be used by people on different computers. At some level, the ability for various people to modify and manage the same set of data from their respective locations fosters collaboration. Progress can occur more quickly without a single conduit through which all modifications must occur. And because the work is versioned, you need not fear that quality is the trade-off for losing that conduit—if some incorrect change is made to the data, just undo that change.

Some version control systems are also software configuration management (SCM) systems. These systems are specifically tailored to manage trees of source code, and have many features that are specific to software development—such as natively understanding programming languages, or supplying tools for building software. Subversion, however, is not one of these systems. It is a general system that can be used to manage any collection of files. For you, those files might be source code—for others, anything from grocery shopping lists to digital video mixdowns and beyond.

[wikipedia.org]
[http://ximbiot.com]
[http://tartarus.org/~simon]
[http://www.oreillynet.com/pub/a/oreilly/opensource/news/subversion_ch02.html]

Enterprise resource planning

An ERP system supports most of the business system that maintains in a single database the data needed for a variety of business functions such as Manufacturing, Supply Chain Management, Financials, Projects, Human Resources and Customer Relationship Management.

An ERP system is based on a common database and a modular software design. The common database can allow every department of a business to store and retrieve information in real-time. The information should be reliable, accessible, and easily shared. The modular software design should mean a business can select the modules they need, mix and match modules from different vendors, and add new modules of their own to improve business performance.

Ideally, the data for the various business functions are integrated. In practice the ERP system may comprise a set of discrete applications, each maintaining a discrete data store within one physical database.

The term ERP originally referred to how a large organization planned to use organizational wide resources. In the past, ERP systems were used in larger more industrial types of companies. However, the use of ERP has changed and is extremely comprehensive, today the term can refer to any type of company, no matter what industry it falls in. In fact, ERP systems are used in almost any type of organization – large or small.

In order for a software system to be considered ERP, it must provide an organization with functionality for two or more systems. While some ERP packages exist that only cover two functions for an organization (QuickBooks: Payroll & Accounting), most ERP systems cover several functions.

Today’s ERP systems can cover a wide range of functions and integrate them into one unified database. For instance, functions such as Human Resources, Supply Chain Management, Customer Relations Management, Financials, Manufacturing functions and Warehouse Management functions were all once stand alone software applications, usually housed with their own database and network, today, they can all fit under one umbrella – the ERP system.

ERP – Implementation is The Challenge

The Ideal ERP System

An ideal ERP system is when a single database is utilized and contains all data for various software modules. These software modules can include:

Manufacturing: Some of the functions include; engineering, capacity, workflow management, quality control, bills of material, manufacturing process, etc.

Financials: Accounts payable, accounts receivable, fixed assets, general ledger and cash management, etc.

Human Resources: Benefits, training, payroll, time and attendance, etc

Supply Chain Management: Inventory, supply chain planning, supplier scheduling, claim processing, order entry, purchasing, etc.

Projects: Costing, billing, activity management, time and expense, etc.

Customer relationship management (CRM): CRM is a term applied to processes implemented by a company to handle its contact with its customers. CRM software is used to support these processes, storing information on current and prospective customers. Information in the system can be accessed and entered by employees in different departments, such as sales, marketing, customer service, training, professional development, performance management, human resource development, and compensation. Details on any customer contacts can also be stored in the system. The rationale behind this approach is to improve services provided directly to customers and to use the information in the system for targeted marketing. While the term is generally used to refer to a software-based approach to handling customer relationships, most CRM software vendors stress that a successful CRM strategy requires a holistic approach. CRM initiatives often fail because implementation was limited to software installation without providing the appropriate motivations for employees to learn, provide input, and take full advantage of the information systems.

Data Warehouse: Usually this is a module that can be accessed by an organizations customers, suppliers and employees. Data warehouse is a repository of an organization’s electronically stored data. Data warehouses are designed to facilitate reporting and analysis. This classic definition of the data warehouse focuses on data storage. However, the means to retrieve and analyze data, to extract, transform and load data, and to manage the data dictionary are also considered essential components of a data warehousing system. Many references to data warehousing use this broader context. Thus, an expanded definition for data warehousing includes business intelligence tools, tools to extract, transform, and load data into the repository, and tools to manage and retrieve metadata. In contrast to data warehouses are operational systems which perform day-to-day transaction processing. The process of transforming data into information and making it available to the user in a timely enough manner to make a difference is known as data warehousing.

How can ERP improve a company’s business performance?

ERP’s best hope for demonstrating value is as a sort of battering ram for improving the way your company takes a customer order and processes it into an invoice and revenue—otherwise known as the order fulfillment process. That is why ERP is often referred to as back-office software. It doesn’t handle the up-front selling process (although most ERP vendors have developed CRM software or acquired pure-play CRM providers that can do this); rather, ERP takes a customer order and provides a software road map for automating the different steps along the path to fulfilling it. When a customer service representative enters a customer order into an ERP system, he has all the information necessary to complete the order (the customer’s credit rating and order history from the finance module, the company’s inventory levels from the warehouse module and the shipping dock’s trucking schedule from the logistics module, for example).

People in these different departments all see the same information and can update it. When one department finishes with the order it is automatically routed via the ERP system to the next department. To find out where the order is at any point, you need only log in to the ERP system and track it down. With luck, the order process moves like a bolt of lightning through the organization, and customers get their orders faster and with fewer errors than before. ERP can apply that same magic to the other major business processes, such as employee benefits or financial reporting.

That, at least, is the dream of ERP. The reality is much harsher.

Let’s go back to those inboxes for a minute. That process may not have been efficient, but it was simple. Finance did its job, the warehouse did its job, and if anything went wrong outside of the department’s walls, it was somebody else’s problem. Not anymore. With ERP, the customer service representatives are no longer just typists entering someone’s name into a computer and hitting the return key. The ERP screen makes them businesspeople. It flickers with the customer’s credit rating from the finance department and the product inventory levels from the warehouse. Will the customer pay on time? Will we be able to ship the order on time? These are decisions that customer service representatives have never had to make before, and the answers affect the customer and every other department in the company. But it’s not just the customer service representatives who have to wake up. People in the warehouse who used to keep inventory in their heads or on scraps of paper now need to put that information online. If they don’t, customer service reps will see low inventory levels on their screens and tell customers that their requested item is not in stock. Accountability, responsibility and communication have never been tested like this before.

People don’t like to change, and ERP asks them to change how they do their jobs. That is why the value of ERP is so hard to pin down. The software is less important than the changes companies make in the ways they do business. If you use ERP to improve the ways your people take orders, manufacture goods, ship them and bill for them, you will see value from the software. If you simply install the software without changing the ways people do their jobs, you may not see any value at all—indeed, the new software could slow you down by simply replacing the old software that everyone knew with new software that no one does.

Implementation of an ERP System

Implementing an ERP system is not an easy task to achieve, in fact it takes lots of planning, consulting and in most cases 3 months to 1 year +. ERP systems are extraordinary wide in scope and for many larger organizations can be extremely complex. Implementing an ERP system will ultimately require significant changes on staff and work practices. While it may seem reasonable for an in house IT staff to head the project, it is widely advised that ERP implementation consultants be used, due to the fact that consultants are usually more cost effective and are specifically trained in implementing these types of systems.

One of the most important traits that an organization should have when implementing an ERP system is ownership of the project. Because so many changes take place and its broad effect on almost every individual in the organization, it is important to make sure that everyone is on board and will help make the project and using the new ERP system a success.

Usually organizations use ERP vendors or consulting companies to implement their customized ERP system. There are three types of professional services that are provided when implementing an ERP system, they are Consulting, Customization and Support.

Consulting Services – usually consulting services are responsible for the initial stages of ERP implementation, they help an organization go live with their new system, with product training, workflow, improve ERP’s use in the specific organization, etc.

Customization Services – Customization services work by extending the use of the new ERP system or changing its use by creating customized interfaces and/or underlying application code. While ERP systems are made for many core routines, there are still some needs that need to be built or customized for an organization.

Support Services- Support services include both support and maintenance of ERP systems. For instance, trouble shooting and assistance with ERP issues.

Advantages of ERP Systems

There are many advantages of implementing an EPR system; here are a few of them:

• A totally integrated system
• The ability to streamline different processes and workflows
• The ability to easily share data across various departments in an organization
• Improved efficiency and productivity levels
• Better tracking and forecasting
• Lower costs
• Improved customer service

Disadvantages of ERP Systems

While advantages usually outweigh disadvantages for most organizations implementing an ERP system, here are some of the most common obstacles experienced:

Usually many obstacles can be prevented if adequate investment is made and adequate training is involved, however, success does depend on skills and the experience of the workforce to quickly adapt to the new system.

• Customization in many situations is limited
• The need to reengineer business processes
• ERP systems can be cost prohibitive to install and run
• Technical support can be shoddy
• ERP’s may be too rigid for specific organizations that are either new or want to move in a new direction in the near future.

ERP Implementation Life Cycle

Free and Open Source ERP software

• Adempiere, a Java based ERP-System which started as a fork of Compiere
• Compiere, a Java based ERP-System
• Dolibarr, a PHP based ERP system
• ERP5, a Python based ERP system
• GNU Enterprise
• GRR (software), a PHP/MySQL -based, web-accessed free ERP system
• JFire, a Java based ERP-System from NightLabs
• Kuali Foundation
• LedgerSMB
• OFBiz
• OpenBlueLab
• Openbravo, a Java based ERP-System
• OpenERP (formerly Tiny ERP)
• Opentaps (Java based)
• OrangeHRM
• Postbooks from XTuple
• SQL-Ledger
• Stoq
• WebERP

[wikipedia.org]
[tech-faq.com]
[www.cio.com]

Standardization

UML is officially defined by the Object Management Group (OMG) as the UML metamodel, a Meta-Object Facility metamodel (MOF). Like other MOF-based specifications, UML has allowed software developers to concentrate more on design and architecture.^[1]

UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages, supported by the OMG.

Extensible Mechanisms

UML is extensible, offering the following mechanisms for customization: profiles and stereotype. The semantics of extension by profiles have been improved with the UML 1.0 major revision.

UML has matured significantly since UML 1.1. Several minor revisions (UML 1.3, 1.4, and 1.5) fixed shortcomings and bugs with the first version of UML, followed by the UML 2.0 major revision that was adopted by the OMG in 2003. There are four parts to the UML 2.x specification: the Superstructure that defines the notation and semantics for diagrams and their model elements; the Infrastructure that defines the core metamodel on which the Superstructure is based; the Object Constraint Language (OCL) for defining rules for model elements; and the UML Diagram Interchange that defines how UML 2 diagram layouts are exchanged. The current versions of these standards follow: UML Superstructure version 2.1.2, UML Infrastructure version 2.1.2, OCL version 2.0, and UML Diagram Interchange version 1.0^[4].

Although many UML tools support some of the new features of UML 2.x, the OMG provides no test suite to objectively test compliance with its specifications.

Diagrams overview

UML 2.0 has 13 types of diagrams divided into three categories: Six diagram types represent static application structure, three represent general types of behavior, and four represent different aspects of interactions. These diagrams can be categorized hierarchically as shown in the following Class diagram:

UML does not restrict UML element types to a certain diagram type. In general, every UML element may appear on almost all types of diagrams. This flexibility has been partially restricted in UML 2.0.

In keeping with the tradition of engineering drawings, a comment or note explaining usage, constraint, or intent is always allowed in a UML diagram.

The highlights of UML 2.0 functionality

The new developments in UML 2.0 can be grouped into the following five major categories, listed in order of significance:

• A significantly increased degree of precision in the definition of the language: This is a result of the need to support the higher levels of automation required for MDD. Automation implies the elimination of ambiguity and imprecision from models (and, hence, from the modeling language) so that computer programs can transform and manipulate models.
• An improved language organization: This is characterized by a modularity that not only makes the language more approachable to new users, but also facilitates inter-working between tools.
• Significant improvements in the ability to model large-scale software systems: Some modern software applications represent integrations of existing stand-alone applications into more complex systems of systems. This is a trend which will likely continue resulting in ever more complex systems. To support such trends, flexible new hierarchical capabilities were added to the language to support software modeling at arbitrary levels of complexity.
• Improved support for domain-specific specialization: Practical experience with UML demonstrated the value of its so-called “extension” mechanisms. These were consolidated and refined to allow simpler and more precise refinements of the base language.
• Overall consolidation, rationalization, and clarifications of various modeling concepts: This resulted in a simplified and more consistent language. It involved consolidation and — in a few cases — removing redundant concepts, refining numerous definitions, and adding textual clarifications and examples.

Se-Radio.net interview Bran Selic on UML

In this episode we’re talking to Bran Selic of Malina Software about modelling in general and UML2 in particular. Bran covers the basics of modelling, the history of UML, and what’s new in UML2.

Host(s): Laurence

Guest(s): Bran Selic

[wikipedia.org]
[http://www.ibm.com/developerworks]
[http://www.se-radio.net]

[Def.] Design, usually considered in the context of applied arts, engineering, architecture, and other creative endeavors, is used both as a noun and a verb. As a verb, “to design” refers to the process of originating and developing a plan for a product, structure, system, or component.

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems.

Not all software patterns are design patterns. Design patterns deal specifically with problems at the level of software design. Other kinds of patterns, such as architectural patterns, describe problems and solutions that have alternative scopes.

Example 1 : Singleton [Gamma95]

Rationalle and Motivation

The singleton pattern applies to the many situations in which there needs to be a single instance of a class, a single object. It is often left up to the programmer to insure that the An important consideration in implementing this pattern is how to make this single instance easily accessible by many other objects.

Classes

There is actually only one class that needs to be written specially to implement the Singleton pattern. A second client class will always be involved take make requests from the singleton.

Singleton

Here is what a Booch [Booch94] class cloud might look like:

Advantages

What are the advantages to using this pattern?

Single instance is controlled absolutely. When implemented as the pattern recommends, the class will have direct control over how many instances can be created. This is in contrast to making the programmer responsible for insuring that there is only one instance.

This pattern is easily extensible to allow a controlled number of “singleton” objects to be created. The most important modification needed to accomplish this change is in the operator that has control over access to the instances. In this case, the Instance() function would need to be changed.

Examples Here is how a generic singleton might be written in C++. If you want to try it, here is the source code: singleton_ex.tar

class Singleton {
public:
    static Singleton* Instance();  // gives back a real object!
    static proof(void);            // proof that the object was made
protected:
    Singleton();                   // constructor
private:
    static Singleton* _singleton;
};

And the implementation like:

Singleton* Singleton::_singleton = 0;

Singleton* Singleton::Instance()
{
   if (_singleton == 0)
   {
      _singleton = new Singleton;
   }     // end if
   return _singleton;
}    // end Instance()

Food for thought…

What about sub-classing? How can we make the implementation more flexible? Possibly for reuse, or maybe for using multiple singletons in a single program. So what really happens if you try to explicitly declare a Singleton object?

Example 2 : Facade

Rationalle and Motivation

The facade pattern can make the task of accessing a large number of modules much simpler by providing an additional interface layer. When designing good programs, programmers usually attempt to avoid excess coupling between module/classes. Using this pattern helps to simplify much of the interfacing that makes large amounts of coupling complex to use and difficult to understand. In a nutshell, this is accomplished by creating a small collection of classes that have a single class that is used to access them, the facade.

Classes

There can be any number of classes involved in this “facaded” system, but I would think that the minimum is four classes. One client, the facade, and the classes underneath the facade. In a typical situation, the facade would have a limited amount of actual code, making calls to lower layers most of the time.

Advantages/Disadvantages

As stated before, the primary advantage to using the facade is the make the interfacing between many modules or classes more managable. One possible disadvantage to this pattern is that you may lose some functionality contained in the lower level of classes, but this depends on how the facade was designed.

Examples

Imagine that you need to write some program that needs to represent a building as rooms that can be manipulated. Manipulated as in interacting with objects in the room to change their state. The client that has ordered this program has determined that there will only be a need for a finite number of objects possible in each room, and a finite number of operations that can be performed on each of them.

You, as the program architect, have decided that the facade pattern will be an excelent way to keep the amount of interfacing low, considering the number of possible objects in each room, and the actions that the client has specified.

Facade example

Facade example

Consider the sheer simplicity from the client’s side of the problem. A less thought out design may have looked like this, making lots of interaction by the client necessary.

Architectural style

[Def.] Architectural styles classify architecture in terms of form, techniques, materials, time period, region, etc. It overlaps with, and emerges from the study of the evolution and history of architecture. In architectural history, the study of Gothic architecture, for instance, would include all aspects of the cultural context that went into the design and construction of these structures. Architectural style is a way of classifying architecture that gives emphasis to characteristic features of design, leading to a terminology such as Gothic “style”.

[Def.] The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them. The term also refers to documentation of a system’s software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects.

[Shaw & Clements, 1996] “A set of design rules that identify the kinds of components and connectors that may be used to compose a system or subsystem, together with local or global constraints on the way the composition is done”

A set of constraints you put on your development to elicit desirable properties from your software architecture. Constraints may be:

• Topological
• Behavioral
• Communication-oriented
• etc. etc.

Architectural styles typically determine four kinds of properties [AAG93]:

1. They provide a vocabulary of design elements – component and connector types such as pipes, filters, clients, servers, parsers, databases etc.
2. They define a set of configuration rules – or topological constraints – that determine the permitted compositions of those elements.
3. They define a semantic interpretation, whereby compositions of design elements, suitably constrained by the configuration rules, have well-defined meanings.
4. They define analyses that can be performed on systems built in that style. Examples include schedulability analysis for a style oriented toward real-time processing [Ves94] and deadlock detection for clientserver message passing [JC94].

Example Architectural Styles

• Model-View-Controller (MVC) architecture pattern. The MVC architecture style is a popular organizing concept for systems. The model represents the data for the system, the view represents the way the data are presented to the user, and the controller handles the logic for the system.
• Publish-subscribe. The publish-subscribe architecture pattern is a system in which a publisher publishes data on a bus. Subscribers subscribe to portions of the data that are published by publishers on the bus. They register for various topics. When a message appears on the bus that matches the topic in which a subscriber is interested, the bus notifies the subscriber. The subscriber can then read the message from the bus.
• Pipes and filters. Anyone who is familiar with UNIX systems will recognize this architectural pattern. The pipe and filter pattern allows a system to be assembled from small programs called filters. A filter has an input and an output. The filters are assembled into a chain in which each filter gets data from the previous filter in the chain, processes the data, and passes the data to the next filter in the chain. The best example of a pipe and filter system is a compiler. The lexical analysis, syntax analysis, semantic analysis, intermediate code generation, and optimization occur in a pipe and filter style chain.
• Layers. A layered system is one in which different layers of the system take care of a specific function of the system. Each layer in a layered architectural style is a package of software that has a well-defined interface and a few well-known dependencies within the application. For example, a data access layer is responsible for encapsulating the technical means for accessing a database. All data requests to a database go through the data access layer for that database. The data access layer has the responsibility of hiding the data access mechanism from upstream layers. In a closed layer system, a layer may only access adjacent layers. In an open layer system, layers may access any other layer in the system, not just the ones to which they are adjacent.

Model-View-Controller (MVC) architecture pattern

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.

MVC model

• Model
  • The model represents enterprise data and the business rules that govern access to and updates of this data.
  • This is the domain-specific representation of the information on which the application operates.
  • It maps requests coming from clients into operations over the model
• View
  • The view renders the contents of a model. It accesses enterprise data through the model and specifies how
    that data should be presented.
  • It is the view’s responsibility to maintain consistency in its presentation when the model changes.
  • MVC is often seen in web applications, where the view is the HTML page and the code which gathers
    dynamic data for the page.
• Controller
  • The controller translates interactions with the view into actions to be performed by the model.
  • This responds to events, typically user actions, and invokes changes on the model and perhaps the view.
  • In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.

Differences and Similarities beetwen Architectural Styles and Design Patterns

There are many similarities between patterns and styles. Gaol: package engineering experience, formulation is the same : organization and interaction among “key” components. But thay have come from different communities. Many architectural styles have been well know for a long time in the software engineering community while patterns area relatively recent development in OO design . Figure below show a sketch of differences and similarities.

Differences and similarities

[henrymuccini.com]
[wikipedia.org]
[http://users.csc.calpoly.edu]

I propose to consider the question “Can machines think?” This should begin with definitions of the meaning of the terms “machine” and “think.”

Turing Test is meant to determine if a computer program has intelligence. Quoting Turing, the original imitation game can be described as follows:

The new form of the problem can be described in terms of a game which we call the “imitation game.” It is played with three people, a man (A), a woman (B), and an interrogator (C) who may be of either sex. The interrogator stays in a room apart from the other two. The object of the game for the interrogator is to determine which of the other two is the man and which is the woman. He knows them by labels X and Y, and at the end of the game he says either “X is A and Y is B” or “X is B and Y is A.” The interrogator is allowed to put questions to A and B.

When talking about the Turing Test today what is generally understood is the following: The interrogator is connected to one person and one machine via a terminal, therefore can’t see her counterparts. Her task is to find out which of the two candidates is the machine, and which is the human only by asking them questions. If the machine can “fool” the interrogator, it is intelligent.

This test has been subject to different kinds of criticism and has been at the heart of many discussions in AI, philosophy and cognitive science for the past 50 years.

Who was Alan Turing?

[from Wikipedia.org] Alan Mathison Turing, OBE, FRS (pronounced /ˈt(j)ʊ(ə)rɪŋ/) (23 June 1912 – 7 June 1954) was an English mathematician, logician and cryptographer.

Turing is often considered to be the father of modern computer science. He provided an influential formalisation of the concept of the algorithm and computation with the Turing machine. With the Turing test, meanwhile, he made a significant and characteristically provocative contribution to the debate regarding artificial intelligence: whether it will ever be possible to say that a machine is conscious and can think. He later worked at the National Physical Laboratory, creating one of the first designs for a stored-program computer, the ACE, although it was never actually built in its full form. In 1948, he moved to the University of Manchester to work on the Manchester Mark I, then emerging as one of the world’s earliest true computers.

During the Second World War Turing worked at Bletchley Park, the UK’s codebreaking centre, and was for a time head of Hut 8, the section responsible for German naval cryptanalysis. He devised a number of techniques for breaking German ciphers, including the method of the bombe, an electromechanical machine that could find settings for the Enigma machine.

What is the Loebner Prize?

The Loebner Prize for artificial intelligence ( AI ) is the first formal instantiation of a Turing Test. The test is named after Alan Turing the brilliant British mathematician. Among his many accomplishments was basic research in computing science. In 1950, in the article Computing Machinery and Intelligence which appeared in the philosophy journal Mind, Alan Turing asked the question “Can a Machine Think?” He answered in the affirmative, but a central question was: “If a computer could think, how could we tell?” Turing’s suggestion was, that if the responses from the computer were indistinguishable from that of a human,the computer could be said to be thinking. This field is generally known as natural language processing.

In 1990 Hugh Loebner agreed with The Cambridge Center for Behavioral Studies to underwrite a contest designed to implement the Turing Test. Dr. Loebner pledged a Grand Prize of $100,000 and a Gold Medal (pictured above) for the first computer whose responses were indistinguishable from a human’s. Such a computer can be said “to think.” Each year an annual prize of $2000 and a bronze medal is awarded to the most human-like computer. The winner of the annual contest is the best entry relative to other entries that year, irrespective of how good it is in an absolute sense.

Further information on the development of the Loebner Prize and the reasons for its existence is available in Loebner’s article In Response to the article Lessons from a Restricted Turing Test by Stuart Shieber.

‘Intelligent’ computers put to the test’ (Guardian.co.uk)

Can machines think? That was the question posed by the great mathematician Alan Turing. Half a century later six computers are about to converse with human interrogators in an experiment that will attempt to prove that the answer is yes.

In the ‘Turing test’ a machine seeks to fool judges into believing that it could be human. The test is performed by conducting a text-based conversation on any subject. If the computer’s responses are indistinguishable from those of a human, it has passed the Turing test and can be said to be ‘thinking’.

No machine has yet passed the test devised by Turing, who helped to crack German military codes during the Second World War. But at 9am next Sunday, six computer programs – ‘artificial conversational entities’ – will answer questions posed by human volunteers at the University of Reading in a bid to become the first recognised ‘thinking’ machine. If any program succeeds, it is likely to be hailed as the most significant breakthrough in artificial intelligence since the IBM supercomputer Deep Blue beat world chess champion Garry Kasparov in 1997. It could also raise profound questions about whether a computer has the potential to be ‘conscious’ – and if humans should have the ‘right’ to switch it off.

Professor Kevin Warwick, a cyberneticist at the university, said: ‘I would say now that machines are conscious, but in a machine-like way, just as you see a bat or a rat is conscious like a bat or rat, which is different from a human. I think the reason Alan Turing set this game up was that maybe to him consciousness was not that important; it’s more the appearance of it, and this test is an important aspect of appearance.’

The six computer programs taking part in the test are called Alice, Brother Jerome, Elbot, Eugene Goostman, Jabberwacky and Ultra Hal. Their designers will be competing for an 18-carat gold medal and $100,000 offered by the Loebner Prize in Artificial Intelligence. (more)

[http://www.loebner.net/]
[http://www.guardian.co.uk/technology]

AOP importance is increasing in the past few years, Spring are using it in a widely manner and also OSGi have announced few month ago your Aspect bundle for weaving at run-time (Equinox Aspect). So AOP have a grait impact on present programming and I think that it will have also with future programming.

This episode is a systematic introduction to Aspect Oriented Programming (in contrast to the interview with Gregor Kiczales). We discuss the fundamentals of AOP, define many of the relevant terms and also look at how and where AOP is used in practice, as well as at some current research trends.

Host(s)

Guest(s)

Christa Schwanninger,
Iris Groher

Follow I have posted from slideshare.net two good presentations to AOP.

Aspect-Oriented Programming and Depedency Injection

Aspect Oriented Software Development

Have fun!

[se-radio.net]

One of the first questions that customers often ask is “What’s the difference between a mashup and the Web applications that we currently use in our enterprise today?” The difference has little to do with technology or the integration of systems. Instead, it reflects the ease with which the application can be created by users, how the application is intended to be used, and the lack of nonfunctional requirements (for example, reliability, availability, and performance) that need to be addressed after the mashup or Web application is deployed.

Innovation in the Programmable Web: Characterizing the Mashup Ecosystem

Mashups: A Web 2.0 child

As noted earlier, mashups utilize many of the same technologies as traditional Web applications both in the enterprise servers and in the browser. The concept of mashups is not new, as businesses and Web developers have been aggregating and integrating data for the past decade using the Web as a platform. To minimize confusion, let’s clarify a few points about mashups. For many, mashup is considered a technical term regarding the mashing of disparate data to produce something new and interesting. A situational application is considered a tactical application, one that is often temporary and built by the people who use it. In this respect, a mashup can be a situational application, and a situational application can be a mashup. For this article, mashup means a situational application that is implemented as a mashup. See figure 1 for an overview.

Figure 1. Characteristics of mashups and situational applications

A primary difference between mashups and traditional Web applications concerns the mashup application life cycle and the tendency of mashups to join seemingly unrelated data from public sources in meaningful ways with little or no formal agreements with the data providers. (more)

Types of mashups

There are many types of mashups, such as consumer mashups, data mashups, and business mashups. The distinction is somewhat arbitary because the underlining technology is the same regardless of the use case.

The most common mashup is the consumer mashup. Consumer mashups combine different forms of media from multiple sources and combine them into a single graphical interface. Consumer mashups are aimed at the general public, that is, consumers. Examples of consumer mashups include the many Google Maps applications, iGuide and Radioclouds.

Another common mashup is a data mashup. Data mashups combine similar types of media and information from multiple sources into a single graphical representation. An example of a data mashup is the Havaria Information Services’ AlertMap. which combines current data from over 200 sources related to severe weather conditions, biohazard threats and seismic information from around the world, and displays them on a single map of the world. Another example of a data mashup is Yahoo Pipes

Business mashups focus on various forms of data aggregation into a single presentation, but also allow for collaborative functionability amongst businesses and developers. Serena Software is a company involved in the business mashup industry.

Service mashups

Recently, in the context of the Web, the mashup concept has emerged, and researchers have developed a huge number of Web 2.0 applications. But what exactly does mashup mean? It simply indicates a way to create new Web applications by combining existing Web resources utilizing data and Web APIs. Mashups are about information sharing and aggregation to support content publishing for a new generation of Web applications. By extension, service mashups — the theme of this special issue — aim to design and develop novel and modern Web applications based on easy-to-accomplish end-user service compositions. Combining Web service technologies with fresh content, collaborative approaches (such as Web 2.0 technologies, tags, and microformats), and possibly Web data management and semantic technologies (RSS, RDFa, Gleaning Resource Descriptions from Dialects of Languages, and the Sparql Protocol and RDF Query Language) is an exciting challenge for both academic and industrial researchers building a new generation of Web-based applications. Researchers have created different mashup tools and platforms, letting developers and end-users access and compose various data that Web applications can provide. IBM’s QEDWiki, Yahoo Pipes, Google Mashup Editor, and Microsoft’s Popfly are some well-known examples of mashup platforms that users have largely adopted. Yet these platforms and associated tools represent only early and limited sets of capabilities that are sure to be followed by more powerful and flexible alternatives. (more)

Key research issues in service mashups

Although many have already adopted the (service) mashup concept and recognized its value, realizing the concept is still challenging, and much work remains before we’ll see mashup applications in a mature stage. Let’s briefly discuss some key issues we must consider in the future to improve sharing (registration and publication), finding (search and discovery), reusing (invocation), and integrating (mediation and composition) services.

The first key challenge is that of semantic heterogeneity. Compared to data, services can present a broader form of heterogeneity. Correspondingly, the Web services research community has identified a broader form of semantics — data (I/O), functional (behavioral), nonfunctional (quality of service, policy), and execution (runtime, infrastructure, exceptions). Several research projects have looked at semantics for traditional (WSDL or SOAP) Web services to help address heterogeneity and mediation challenges, and the community took a step toward supporting semantics for Web services by adopting Semantic Annotation for WSDL (SAWSDL) as a W3C recommendation in August 2003. (more)

In this issue

The four articles in this issue address some of the challenges inherent in developing mashup-services-based advanced Web applications.

In “Mashing Up Search Services,” Daniele Braga, Stefano Ceri, Florian Daniel, and Davide Martinenghi propose a visual service mashup language for graphically composing and automatically executing queries over search services. They define search services as services with a variable number of ranked data. The proposed language lets users declaratively specify a query and mash up registered services in a drag-and-drop fashion to compose that query. The authors build service compositions as directed acyclic graphs whose nodes are service invocations and whose arcs are connections between services. The authors propose a physical service access plan for the Web service composition’s execution needs, such as generating a schedule of series or parallel service invocations, orchestrating such invocations, and joining data from different services into a ranked output. They argue that their language enables interesting runtime environments capable of deriving different executable service invocation strategies. Researchers are still working to meet other challenges, such as mastering more complex dependencies among services and supporting reliable and transactional Web services.

In “Composing RESTful Services and Collaborative Workflows: A Lightweight Approach,” Florian Rosenberg, Francisco Curbera, Matthew J. Duftler, and Rania Khalaf propose the extensible Bite language based on a lightweight process composition model for both Web data-driven applications and Web workflow composition. Bite combines SOA process composition principles with REST architectural requirements and workflow functionalities. It lets users implement RESTful service composition and interactive workflows.

In “An Online Platform for Web APIs and Service Mashups,” E. Michael Maximilien, Ajith Ranabahu, and Karthik Gomadam propose an online mashup platform that enables the construction, reuse, sharing, deployment, and management of Web APIs and service mashups. The proposed platform’s main characteristic resides in its domain-specific language, which is introduced to explicitly represent the activities that a mashup designer must fulfill, such as data mediation and service protocol mediation. The authors have deployed the IBM sharable code platform on IBM alpha works services.

Finally, in “Understanding Mashup Development,” Jin Yu, Boualem Benatallah, Fabio Casati, and Florian Daniel provide an overview of some popular and representative mashup development tools and frameworks. Mashup in this article refers to Web applications comprising data, application logic, and UIs of existing applications or services. The authors compare and discuss these tools and frameworks by considering four dimensions: the component model, which describes the mashup components’ characteristic properties; the composition model, which specifies how components are glued to create a mashup application; the development environment, and the runtime environment. In their discussion, the authors conclude that mashup tools’ main characteristics are simplicity, usability, and ease of access. They also identify some perspectives that could improve mashup tools, such as describing user interfaces as components that can be reused and integrated like services.

Example of Mushup Application

• The mashup below uses the Yahoo API to create a traffic mapping tool. Enter the city and state for a view of traffic accidents, delays, and other incidents in your area. If no markers are present, try entering New York, New York where unfortunately, accidents seem to be ever present in the city. (follow me)

• An Ajax-Mashup Sample Application on Sun Java System Web Server 7.0 (follow me)

• CLEARMAP is a mashup web application by the Chicago Police Department which integrates the department’s database of reported crimes with Google Maps in order to help stop crime in areas and warn citizens of areas where the crime rate is high.

• TheCampingMap.com is a site that shows camp-sites in Europe.

• WikiCrimes is a wiki-style website where internet users can report crimes by placing pins on a GoogleMaps based map. The website classifies crimes as robbery, theft or other by pin colour

David Barnes demo of IBM Mashup Center

[http://www.ibm.com]
[http://developers.sun.com/]
[http://dsonline.computer.org]
[wikipedia.org]

In press previews for JavaFX, Sun Fellow James Gosling explained:

Most scripting languages are oriented at banging out Web pages. This is oriented around interfaces that are highly animated.

—James Gosling,

There are parts of the world where a person’s desktop computer is their cell phone, and that’s the kind of end point that we’re going to get to,

—James Gosling,

JavaFX is anticipated to compete on the desktop with Adobe Flash Player, Adobe AIR, OpenLaszlo, and Microsoft Silverlight. It may also target Blu-ray Disc’s interactive BD-J platform, although as yet no plans for a Blu-ray release have been announced.

Tutorials on javafx.com

Creating GUIs Using JavaFX Script

This lesson describes the JavaFX SDK Runtime functionality for creating GUIs. It gives you a high-level explanation of the feature and offers instructions on how to create GUIs using the functionality.

The JavaFX SDK runtime is the foundation library of JavaFX platform, allowing content developers, designers, and GUI architects to quickly and easily create GUIs for Rich Internet Applications. Based on the underlying scene graph functionality, the library provides the ability to present objects in scenes such as a frame containing a circle with a defined filling and stroke, and apply different types of lighting, animation, and transformation effects. For more information about the scene graph API, see the project page at scenegraph.dev.java.net and Presenting Visual Objects lesson.

To learn how to create the GUI using JavaFX Script, consider a task of creating simple graphics: a rounded rectangle and a text string with a drop shadow.

The following code sample shows how you do it in a traditional way using Java 2D:

import java.applet.Applet;
import java.awt.font.*;
import java.awt.geom.*;
import java.awt.*;
...
public class SimpleButton extends Applet {
...
	public void paint(Graphics g) {
	  Graphics2D g2 = (Graphics2D) g;
	  g.setColor(Color.LIGHT_GRAY);
	  g2.fillRoundRect(10, 10, 200, 50, 15, 15);

	  Font font = new Font("Serif", Font.BOLD, 20);
	  g.setFont(font);
	  String textString = "Java 2D";
	  FontRenderContext frc = ((Graphics2D)g).getFontRenderContext();
	  Rectangle2D bounds = font.getStringBounds(textString, frc);
	  int wText = (int)bounds.getWidth();
	  int TextX = 10 + 200/2 - wText/2;

	  g.setColor(Color.DARK_GRAY);
	  g.drawString(textString, TextX + 1, 39);
	  g.setColor(Color.YELLOW);
	  g.drawString(textString, TextX, 40);
	}
...
}

Figure 1: Java 2D Sample

To drop a shadow, this code sets a contrast color and uses an additional drawString method with offset coordinates.

The JavaFX Script Language and JavaFX Runtime classes enable developers to render the same graphic context more easily and more clearly:

import javafx.scene.*;
import javafx.scene.paint.*;
import javafx.scene.geometry.*;
import javafx.scene.text.*;
import javafx.scene.effect.*;
import javafx.ext.swing.*;

SwingFrame {
  title: "Simple (JavaFX demo)"
  width: 228
  height: 98
  content: Canvas {
    content: Group {
      content: [
        Rectangle {
          x: 10   y: 10
          width: 200   height: 50
          arcWidth: 15   arcHeight: 15
          fill: Color.web("#C0C0C0")
        },
        Text {
          x: 110   y: 40
          content: "JavaFX"
          font: Font {
            name: "Serif"
            size: 20
            style: FontStyle.BOLD
          }
          fill: Color.YELLOW
          horizontalAlignment: HorizontalAlignment.CENTER
          effect: DropShadow {
            offsetX: 2   offsetY: -2   radius: 6
            color: Color.BLACK
          }
        }
      ]
    }
  }
  visible: true
}

This code sample defines a Group object containing two elements: Rectangle and Text. Shape parameters and coordinates as well as font and colors are set using corresponding attributes – x , y, font, size, style, fill and color. The effect attribute applies a drop shadow to the Text element.

To enhance this code, apply a lighting effect to the Group:

import javafx.scene.*;
import javafx.scene.paint.*;
import javafx.scene.geometry.*;
import javafx.scene.text.*;
import javafx.scene.effect.*;
import javafx.scene.effect.light.*;
import javafx.ext.swing.*;

Group {
  content: [
    Rectangle{...}
    Text {...}
  ] effect: Lighting{light: DistantLight {azimuth: 225}}
}

Figure 2: JavaFX Script Sample

The azimuth attribute defines a direction angle for the light source on the XY plane, in degrees.
More visual effects are available in the javafx.scene.effect and javafx.scene.effect.light packages. Refer to the API doc or to API Reference for more information. The entire code of this program is available in the JavaFXGraphics.fx file.

Applying Data Binding

Data binding is one of the advantageous features in JavaFX Script Language. It enables all public attributes and functions to be bound. For example, you can bind the window title to the TextField, so whatever you type automatically appears in the window title without handling event listeners. For the graphical sample, you create a slider to vary the angle of the distant light source.

Figure 3: Data Binding Sample

To add the slider to the Group, use the ComponentView class.

var slider = Slider{minimum: 0 maximum: 360 value: 20};

(more)

The demo application is a stopwatch widget that measures and displays time intervals accurate to within hundredths of a second. The application interface is a dial that has a second hand, two small dials that display tenths and hundredths of a second, and a digital display that shows time elapsed in minutes, seconds, and tenths and hundredths of a second. On the top of the main dial there are two buttons, green and red. The green button starts or stops the time measure. Once the green button is pressed during time measure, the stopwatch stops indicating the time elapsed, however the actual time measuring continues. This feature allows recording intermediate results. The red button resets the elapsed time.

Figure 1: Stopwatch Widget

Creating the Application GUI

The demo uses a number of JavaFX SDK Runtime classes to build the application UI and implement graphical effects.

The following code draws the inner and the outer circle of the main stopwatch. Note the use of the Circle, LinearGradient, and RadialGradient classes. These classes are used to draw circles with a 140- and 134- pixel radius and fill them with the linear and radial gradient respectively. The radius of the circle is defined by the radius attribute, the start and end colors of the gradient are defined using the Stop and color attributes.

Group { translateX: 40 translateY: 40 content: [
  Circle {
    centerX: 140
    centerY: 140
    radius: 140
    fill:LinearGradient { startX:0 startY:0 endX:1 endY:1
      stops: [
        Stop { offset:0 color: webcolor("#3c3c3c") },
        Stop { offset:1 color: webcolor("#010101") }
      ]
    }
  },
Circle {
  centerX: 140
  centerY: 140
  radius: 134
  fill: RadialGradient { centerX:0.5 centerY:0.5 radius:0.5
    stops: [
      Stop { offset:0 color: rgba(20,20,20,1) },
      Stop { offset:0.9499 color: rgba(20,20,20,1) },
      Stop { offset:0.95 color: rgba(20,20,20,1) },
      Stop { offset:0.975 color: rgba(20,20,20,1) },
      Stop { offset:1 color: rgba(84,84,84,0) }
    ]
  }
},
...

Also note that the Group class groups the two circles to enable them share a coordinate space and to be transformed as a group.

The numbers “0″, “15, “30″, “45″ below the tick marks are implemented using the Text class. Here is the code that draws a white “0″.

Text {
  font: Font{name: "Courier" size: 16, style: FontStyle.BOLD}
  x: 141 y: 47
  content: "0"
  horizontalAlignment: HorizontalAlignment.CENTER
  fill: webcolor("#FFFFFF")
},
...

Note that the code uses font to set the font style and its size, x and y attributes to define the position of the tick mark, and content to display “0″. It also fills the tick mark with yellow using fill with a defined web code for this color.

The hand of the main dial comprises of two rectangles and a circle created using the Circle and Rectangle classes. Additionally, lighting effect is applied to the dial using Lighting class:

Group {
  content: [
    Group {
      content: [
        Circle {centerX: 140 centerY: 140 radius: 8
          fill: webcolor("#FF0000")},
        Rectangle{x: -1.5 y: -20 width: 3 height: 120
            fill: webcolor("#FF0000")
            rotate: bind handAngle
            translateX: 140
            translateY: 140},
        Rectangle{x: -1.5 y: -40 width: 3 height: 20
            fill: webcolor("#FFFFFF")
            rotate: bind handAngle
            translateX: 140
            translateY: 140}
      ]
      effect: Lighting{
        light: DistantLight {azimuth: 225}
      }
    }
  ]
...

(more)

Demo: JavaFX, creating a sphere with shadow on silveiraneto.net

Silveira Neto describes on your blog an interesting JavaFX demo and its graphics potentialities.

This is a short tutorial about some JavaFX elements like ellipses, circles, effects and gradients.

In the first code we are creating a frame with a ellipse with center in (120,140), 60 pixels of horizontal radius, 20 pixels of vertical radius and color black. We have also a circle with center in (100,100), 50 pixels of radius and color red. The idea is make this circle appears like a sphere and make the ellipse look like a shadow.

view plaincopy to clipboardprint?


import javafx.application.*; 
import javafx.scene.paint.*; 
import javafx.scene.geometry.*; 
 
Frame { 
 title: "JavaFX Sphere", width: 300, height: 300, visible: true 
 stage: Stage { 
 content: [ 
 Ellipse { 
 centerX: 120, centerY: 140, radiusX: 60, radiusY: 20 
 fill: Color.BLACK 
 }, 
 Circle { centerX: 100, centerY: 100, radius: 50, fill: Color.RED } 
 ] 
 } 
} 

view plaincopy to clipboardprint?


import javafx.application.*; 
import javafx.scene.paint.*; 
import javafx.scene.geometry.*; 
 
Frame { 
 title: "JavaFX Sphere", width: 300, height: 300, visible: true 
 stage: Stage { 
 content: [ 
 Ellipse { 
 centerX: 120, centerY: 140, radiusX: 60, radiusY: 20 
 fill: Color.BLACK 
 }, 
 Circle { centerX: 100, centerY: 100, radius: 50, fill: Color.RED } 
 ] 
 } 
} 

import javafx.application.*;
import javafx.scene.paint.*;
import javafx.scene.geometry.*;

Frame {
    title: "JavaFX Sphere", width: 300, height: 300, visible: true
    stage: Stage {
        content: [
            Ellipse {
                 centerX: 120, centerY: 140, radiusX: 60, radiusY: 20
                 fill: Color.BLACK
            },
            Circle { centerX: 100, centerY: 100, radius: 50, fill: Color.RED }
        ]
    }
}

Now we will just add two thing, a effect and a radial gradient.

First we’ll just add javafx.scene.effect.* to our import list and just call the gaussian blur effect in our ellipse with

[wikipedia.org]
[http://javafx.com/]
[http://silveiraneto.net/]
[http://learnjavafx.typepad.com]
[javapassion.com]

The tactic exploits the internet routing protocol BGP (Border Gateway Protocol) to let an attacker surreptitiously monitor unencrypted internet traffic anywhere in the world, and even modify it before it reaches its destination.

The demonstration is only the latest attack to highlight fundamental security weaknesses in some of the internet’s core protocols. Those protocols were largely developed in the 1970s with the assumption that every node on the then-nascent network would be trustworthy. The world was reminded of the quaintness of that assumption in July, when researcher Dan Kaminsky disclosed a serious vulnerability in the DNS system. Experts say the new demonstration targets a potentially larger weakness.[...] (more)

O’Reilly TV: Dan Kaminsky on the DNS Bug of 2008

ECF Eclipse Communication Framework is a framework for supporting the development of distributed Eclipse-based tools and applications. It can be used to create other plugins, tools, or full Eclipse RCP applications that require asynchronous point-to-point or publish-and-subscribe messaging.

ECF providing two things to developers:

• Real-time communication and collaboration features for teams using Eclipse such as peer-to-peer file sharing, remote opening of Eclipse views, screen capture sharing, and real-time shared editing.
• A set of communications APIs and frameworks built upon existing protocols (like Google Talk, XMPP, SSH, HTTP/HTTPS, Rendevous, IRC, and others) for developers to add communications and messaging to their own Equinox-based plugins, or customize and extend the ECF applications. The APIs support peer-to-peer as well as client-server and multipoint messaging, and are focused around specific types of communication, such as peer-to-peer file transfer, presence/IM/chat, dynamic service discovery, remote OSGi services, channels for messaging, etc.

Introduction: ECF Containers

ECF introduces the concept of a communications container. ECF containers represent access to a protocol-specific communications context. For connection-oriented communications, an ECF container loosely corresponds to the traditional notion of a communications session, but the more general container concept is also useful for capturing context even if the communications are not session-oriented.

ECF containers can represent both point-to-point communications (e.g. client/server) or publish-and-subscribe (group) communications. Container instances can provide access to synchronous communications only, asynchronous communications only, or both together. This flexibility allows many communications applications to be constructed out of one or more ECF containers…each of which provides access to some specific communications context and some protocol(s) for communicating within that context. (more)

Distributed OSGi

The goal of distributed OSGi is to extend the OSGi framework for distributed computing capabilities by configuring an existing distributed computing software system (such as Web services, CORBA, or Eclipse ECF) behind an OSGi service. The goal of distributed OSGi is to allow a service running in one OSGi framework to invoke a service running in another, potentially remote, OSGi framework (meaning a framework in a JVM). This excerpt makes it quite clear what this initiative is all about:

The Distributed OSGi effort also seeks to enable “a service running in one OSGi framework to invoke a service running in another, potentially remote, OSGi framework (meaning a framework in a JVM),” Newcomer wrote. As the current OSGi standard only defines how services talk to each other only within a single JVM, “extensions are needed to allow services to talk with each other across multiple JVMs — thus the requirements for distributed OSGi on which the design is based…. Overall we recieved good feedback, and a lot of questions pertaining to work that still needs to be done. We hope to be able to publish the code to Apache and publish a draft of the design doc this summer, perhaps in August, after we have a chance to formally review the initial implementation with the EEG membership, and get their blessing (no doubt there will be some changes as well since this is just the start).” he said.

In a blog post following the Distributed OSGi demonstration in Berlin, Newcomer wrote:

“The goal of distributed OSGi is to extend the OSGi framework for distributed computing capabilities by configuring an existing distributed computing software system (such as Web services, CORBA, or Eclipse ECF [Eclipse Communication Framework]) behind an OSGi service. The demo showed a Web services solution using Apache CXF as the distribution software, but the design should work with any distributed computing system.”

R-OSGi

R-OSGi runs as an OSGi bundle and facilitates distribution for arbitrary OSGi framework implementations. All that a service provider framework has to do is registering a service for remote access. Subsequently, other peers can connect to the service provider peer and get access to the service. Remote services are accessed in an entirely transparent way. For every remote service, a local proxy bundle is generated that registers the same service. Local service clients can hence access the remote service in the same way and without regarding distribution. R-OSGi, a distributed middleware platform that extends the centralized industry-standard OSGi module interface to support distributed module management. To the developer, R-OSGi looks like a standard module management tool. However, at deployment time R-OSGi can be used to turn the application into a distributed application by simply indicating where the different modules should be deployed. In particular, at run time R-OSGi represents distributed failures as conventional module insertion and withdrawal operations so that the logic to deal with failures is the same as that employed to deal with dependencies among standard modules. In doing so, R-OSGi greatly simplifies the development of distributed applications with no performance cost. Hal Hildebrand in his blog said:

At this year’s EclipseCon, I went to a talk by Jan Rellermeyer regarding his R-OSGi system. His stuff is open source, which you can find here. The slides for his talk are available here. It’s extremely interesting and I would suggest anyone who’s interested in the distributed OSGi stream to both download and play with the r-OSGi system and to read the paper and presentation. In particular, I think that his discussion of the alternatives vis a vis Jini, UPnP and SLP is quite illuminating. (more)

NB the presentation slides for R-OSGi have just been posted .

Differences between Distribuited OSGi and r-OSGi:

Hal Hildebrand wrote the differences between Distribuited OSGi and r-OSGi:

In Jan’s implementation, the primary interface to the system – from the client’s POV – is the RemoteOSGiService interface. To make use of a remote service the client does the following: (more)

[http://blogs.iona.com/newcomer]
[http://r-osgi.sourceforge.net/]
[http://www.tensegrity.hellblazer.com]
[http://www.eweek.com]
[http://java.dzone.com]