Rhythm Section

The Rhythm Section (Frameworks)



Getting applications up and running in the shortest amount of time is critical these days.  This involved reducing the learning curve and implementing many concrete and final classes.  The following paragraphs examine the importance of framework design.


Frameworks reuse both design and code. Aspects of a design, such as the kinds of objects, are easily described by code. Other aspects are not described well by code, such as invariants maintained by objects in an ensemble. The fact that aspects of a framework are not expressed well as code makes frameworks harder to understand than abstract classes. A design must emphasize its details of a at the expense of others. A framework concentrates on describing object that make up the program and how they interact.

Dataflow is de-emphasized, but the communication between object is emphasized. Since frameworks provide abstract algorithms, users of a framework usually ignore the details of these algorithms and concentrate on designing and combining objects. The concept of a framework is harder to understand than that of an abstract class. Abstract classes can be defined either by how to recognize them or how to use them. Unfortunately, there is no simple way to tell whether a set of classes is a framework, so frameworks tend to be defined on how they are used.

The important classes in a framework, such as of Model/View/Controller, are usually abstract. Like Model/View/Controller, a framework usually comes with certain concrete subclasses of the classes in the framework. No component library is perfect to derive new concrete subclasses of the abstract classes in the framework. A good component library is valuable in addition to the framework, the essence of a framework is not the component library, but the model of interaction and control flow among the objects.

Frameworks are informally defined early as a set of objects and how they interact. Most the object ­oriented frameworks are specified by informal documentation and a set of (usually) abstract classes that represent the objects. The classes give the operational specification of how objects in the framework work together.

Given a specification language for describing the behavior of a set of objects, a framework would be a function from the set to constrain the behavior. For example, the Model/View/Controller framework would be a function from the three objects in a MVC trio: the view has a function from the state of the model to an image to invariants like the image on the screen inside a view’s bounding box is its function applied to the state of the model, and to operation sequences like whenever the controller changes the state of the model, it performs the operation on the view, which will redraw the screen. Note that a framework can define both the invariant and the outline of the algorithm.

Frameworks rely on undefined properties of the objects, such as the function from the state of the model to the image. A framework is filled out by selecting objects according to how they define these properties. The objects in a framework often place additional constraints on each other. Views (controllers) often use specialized operations to read (change) the state of a model. The major problem with expressing frameworks in a programming language is that it is hard to learn the constraints that the framework imposes on a program. The major advantage of expressing a framework as a program is that the algorithms and data structure of the program are automatically reused by every instantiation of the framework. There is usually an abstract class for each component in the framework. The algorithms and data structures that are reused are usually defined by these abstract classes. Each subclass of the abstract class defines a kind of component that fits into the framework, and they inherit much of their implementation from their abstract superclasses. This makes it easier to develop a library of components that can be mixed and matched within a framework.

A framework would be described both operationally and in terms of the constraints that it places on its components. This would not only provide code reuse, but make it easier to learn how objects in the framework interact. A framework reuses analysis, design, and code. It reuses analysis because it describes the kinds of objects that are important and how a large problem should be broken down into smaller problems. It reuses design because it contains abstract algorithms and describes the component interfaces that the programmer must implement and the constraints that any implementation must satisfy. It reuses code because it makes it easy to develop a library of compatible components and because the implementation of a new component can inherit most of its implementation from an abstract superclass. All of these are important, though in the long run it is probably the analysis and design reuse that provide the biggest payoff.

A framework hides the parts of the design that are common to all instances, and makes explicit the pieces that need to be customized.

A framework is most valuable when the part of the design that is hidden is the part that programmers find hardest to understand.

A class that is not abstract is concrete. In general, it is better to inherit from an abstract class than from a concrete class. A concrete class must provide a definition for its data representation, and some subclasses will need a different representation. Since an abstract class does not have to provide a data representation, future subclasses can use any representation without fear of conflicting with the one that they inherited. Creating new abstract classes is very important, but is not easy. It is always easier to reuse a nicely packaged abstraction than to invent it.

A programmer usually tries to create a new class by making it a subclass of existing class, since this is less work than creating a class from scratch. This can result in a class hierarchy whose top­most class is concrete. The top of a large class hierarchy should almost always be an abstract class. As a programmer gains experience, they will then try to reorganize the class hierarchy and find the abstract class hidden in a concrete class. The result will be a new abstract class that can be reused many times in the future.

An example of a class that needs to be reorganized is View, which defines a user interface object that controls a region of the screen. A view might have many subclasses, but is concrete. A careful examination will reveal a number of assumptions made in a view that most of its subclasses do not use. The most important is that each view will have subviews. In fact, most subclasses of a view implement views that can never have subviews. Quite a bit of code in a view deals with adding and positioning subviews, making it very difficult for a beginning programmer to understand the key abstractions that a view represents. The solution is simple: split View into two classes, one (view) of which is the abstract superclass and the other (view WithSubview) of which is a concrete subclass that implements the ability to have subviews. The result is much easier to understand and to reuse.


Booker Showers

How to identify objects as REST Resources

How to identify objects as REST Resources


Assuming the reader has an idea of the REST design philosophy, rampant confusion exists on what is exactly a resource.  Much debate exists on how to identify and/or classify Internet HTTP objects as REST resources.  A resource is the data end point of a URI (e.g., music.taliferro.com/artists/calima-shatiday/).  Data is emphasized because REST resources should be a stateless data representations that can be bookmarked.  It’s important to understand this design philosophy when creating a REST resource.  This idiom is often ignored and puts a REST design in significant peril.

I have also seen many SOAP implementations shoe-horned into REST which only leads to abstruse REST structure.

So how are these resources manipulated?  REST resources are manipulated in 2 ways, through the HTTP verbs (PUT=UPDATE, POST=ADD, GET=RETRIEVE, DELETE=DELETE) and custom REST objects called components.

Components act upon Resources.  (What Roy Fielding calls components some people call controllers. REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components.) This is an important concept to understand, because it is the foundation of good REST design.

A good REST design will define data elements as the resources, use PUT, POST, GET and DELETE to manipulate the data.

An easy way to design REST is to look at the landscape and divide your nouns and verbs.  The nouns are your resources and the verbs should fit under PUT, POST, GET and DELETE and act as your controllers or actions verbs.  If you can remember this simple design constraint, the limitation will assist in creating a decent REST design.


Booker Showers

Better Orchestration Through Folder Structure

Better Orchestration Through Folder Structure

Organizing resources into an appropriate structure is a major struggle for most implementors.  Unorganized resources makes it difficult to scale.  In addition, confusing folder usage as taxonomy instead of data usage places an unnecessary burden on a consumer of a resource.  Maximum orchestration can only be achieved through proper semantics.

A folder should contains all the resources that belong to the current data structure. The folder includes all files, resources and/or business data necessary to process a request.

Most of the time, there is only one data resource. Sometimes, there may be more than one data resource for the same composite resource (e.g., one for http and another on https).

A project folder should contain resources attached to a project. The composite resource may be divided into corresponding systems and inserted into a specific folder called by an orchestrator.

The specific folder name under the system folder contains all resources belonging to the current implementation. The specific folder includes all files and resources. For example, the folder will contain the XSLT files, the XSD files, WADL, and/or WSDL files used to call a resource.

An Infrastructure folder should contain all resources that are not specific to a particular project or implementation. The Infrastructure folder includes the XSD files, Query files, shared function files, and the WSDL file used to implement a generic service.


Booker Showers

REST Conductor

The REST Conductor

Improper REST usage is difficult to scale and can reduce developer adoption.  The following points are important to consider  when taking on the role as The REST Conductor.

REST is an ideal solution for data collections and underlying data:

  • For all data resources the common HTTP 1/1 verbs are used to specify the action taken on the resources GET, PUT POST and DELETE.
  • All resource names should be plural nouns.
  • The resource path should be resource restrictive. If a word is in the path of the URI, the word should return a value.
  • Collections should be returned for the plural connotation, e.g. “Devices.”
  • To refer to a specific resource, the ID of the resource should be used, e.g. “/Devices/4893”.
  • An operation is idempotent if a sequence of two or more of the same operations results in the same state or result. (If you call an operation more than once you should receive the same result.) According to the HTTP 1.1 specification, GET, HEAD, PUT, and DELETE are idempotent, while POST is not. Multiple attempts to PUT (update) data to a URL results in the same resource state returned, which is the same as a single attempt to PUT data to the URL. However, the same cannot be said of a POST request as the state of the resource may change.)
  • The following is recommended for REST operations:
    • Create = PUT if and only if you are sending the full content of the specified resource (URL).
    • Create = POST if and only if you are sending a command to the server to create a subordinate of the specified resource, using some server-side algorithm.
    • Retrieve = GET (must be side effect free).
    • Update = PUT if and only if you are updating the full content of the specified resource.
    • Update = POST if and only if you are requesting the server to update one or more subordinates of the specified resource.
    • Delete = DELETE.
  • REST resources may put hyperlinks within URI representation to enable clients to drill down for more information, and/or to obtain related information. Moreover, REST resources may gradually reveal data rather than in a single response document by providing hyperlinks to obtain more details.

Booker Showers

Service Mediation

Understanding Service Mediation


Mediation is a metaphor used to describe brokering service capabilities.  A skilled developer can build a mediation model on top of any provider’s software to deliver services in a controlled and efficient manner.

What problem does mediation solve?

Customers want access to company services. When customers sign up for a service via a website the customer does not like to wait to use the service.  Additionally, when a customer signs up for several services at once they usually want immediate access to the services.

Suppose the following services are provided by a company⎯audio streaming, online billing, content downloading, self service support, and 3rd party apps.  Each of the services has its own infrastructure and are managed by different departments.  How can  customers gain access to multiple services immediately after they sign up?  Service Mediation.

Service mediation is the mechanism used to stitch together various system services and present to a customer one unified service.

However, service mediation is not limited to internal infrastructure type services accessible to customers. Service mediation also applies to REST resources a company wants to make available to internal and external developers.

Understanding Service Mediation

Services are composite functions built by combining multiple Factory Assistants.  A composite service consists of services drawn from several different factories. The components may be individual services, functions from within other applications, or entire systems.

Mediator provides centralized Business Support by integrating process flows and business logic. Main also provides synergy across services, users, and subscriptions. Moreover, this synergy is dynamically created, configured, and provisioned by using a set of profile definitions and policies.

Sentry is the access point. Software on this layer provides security to USM capabilities from a user interface.

Factory assistants generally provide a set of building blocks common to all services.


Booker Showers

How Resource Restrictive REST URIs Save API Design

How Resource Restrictive REST URIs Save API Design


A common problem with REST is unintentional categorization.  Many creators of REST resources include words in the URL that are unnecessary and provide no value, which lead to problems.  Using unnecessary words (unknowingly) limits the URL’s semantical construction, which leaves less room for resource extension.

Consider a resource restrictive REST URI as a definitive resource. What does the term “resource restrictive” URI mean? Each word in a resource restrictive URI structure should lead to a data source.  For instance, a tree structure that usually has something underneath⎯e.g. /Music/Artists/Albums/Songs, where music contains all music, artists contains musical artists, and the artists albums are another resource one layer deeper.

Music |-Artists |-Albums |-Songs

Every layer reveals an additional concrete resource/s. If I navigate to music, I should see a list of artists. If I navigate to an artist, I should see a list of music belonging to the artist.

Many REST URIs are non-restrictive. In addition, non-restrictive REST URIs provide no value in the URI, only to categorize, not inform.

For example, a REST URI such as /Collection/Music/Received/Songs has no hierarchical value other than categorizing the music as songs received.  Navigating the structure reveals nothing for Collection, Music or Received. Results are only returned when you arrive at songs.  Do you recognize the design flaw?

If the structure type described was the path, where would you add Albums or Artists?

A well, thought-out resource restrictive URI saves future headaches when trying to add additional resources to a hierarchy.  The reason many REST resources only have one resource at the end of a long URI string is because the URI is not well developed. There is nowhere to go after the endpoint.


Booker Showers


Avoid REST Implementation Failure

Avoid REST Implementation Failure

Poorly implemented REST strategies cost companies millions to maintain and decommission. Each failed REST implementation moves REST further down the path to obsolescence.  To avoid REST implementation failure, management and developers must return to REST philosophy basics.

The Representational State Transfer (REST) is an architectural style. REST exploits the benefits and constraints of the web by identifying system restrictive elements that differentiate the design space. Additionally, REST allows the web to stay in harmony with corporate systems.

REST architecture emphasizes system constraints and de-emphasizes creativity or vision. System designers avoid precarious situations by designing, a REST philosophy-based implementation.

Management may want to monetize software assets by exposing internally developed infrastructure as API‘s (Application Programming Interface).  The challenge is to provide an interface that allows developers the creative freedom to generate new applications from a company’s infrastructure elements.

An additional challenge for system architects is to help executive decision makers understand how competitors improperly using REST is not a path to follow.

To use a baker analogy⎯a baker needs different ingredients to bake different kinds of pies. A baker cannot use a pre-baked pie to create other pies.

Ultimately, a better strategy gives a developer some tools and allows the developer to combine those tools with other tools to create a new product. A developer should not be given a finished product and asked to create something new from the finished product.

From a REST architect perspective, the value of resources and controllers comes from thinking in the abstract. Abstract thinking about the parts (instead of the whole) create value for the developers you are trying to attract.

For example, if a telecommunication company wants to gain developer adoption, decision makers would align assets so one asset alone would not accomplish much. However, one asset combined with other assets would create something interesting and viable.

As a developer, you should imagine mixing and matching various resources forming new software products, or incorporating resources into another product. To focus on parts instead of predetermined concepts allows a developer’s imagination to flourish.

When each infrastructure asset independently evolves and gains a consistent interface the benefit to a company lies in monetizing exposed assets to external developers.

Booker Showers


5 Rules For Creating New Versions

I marvel at the debate that takes place about when to create a new version of an API, HTML, or REST resource. In a world where being combative or argumentative is the norm, here is some guidance and ammunition for those looking for sanity when creating a new version.

Parameters Change

Any time a parameter is added or changed on the input or output of a method, the version should be changed. The version change is also a courtesy to developers utilizing the method—hey something was added or changed, so take note.

Methods Change

When a method changes either through a name change, additional functionality, or through deprecation a new version, is necessary.

Location Change

Sometimes it’s necessary to move a method or REST resource to a new location because of an architectural, semantic, categorization, or physical server consideration. When the location of an API method changes, always create a new version and add a warning to the existing API method that the method was moved to a new location, and all future calls should be directed to the new location.

Technology Implementation Change

Technology changes. Frameworks, languages, and new programming techniques are often catalyst for changing the implementation of an API. The changes usually result in a speed increase, better quality, or more functionality. When the technology used to implement a technology changes, it’s a good idea to inform the user via a version change.

Results Change

There may be times when the results returned from a method call are augmented or modified but are not useable. For example, if the results expected are for an address of 50 characters, but the results now include 70 characters and an office suite number the calling programs may not be able to handle the result.

To execute a successful implementation, you must have a practical versioning scheme. Without a versioning strategy, an API and the associated functionality becomes difficult to scale and deploy.

Strategic Tuning with Project Management

Strategic Tuning with Project Management

Project management is about managing activities that drive business success.

Businesses are most effective when tasks are under control. Management and staff must perform many tasks to remain competitive. Tasks such as creating invoices, tracking projects, opportunities, emailing prospects, filing electronic and printed documents, scheduling appointments, maintaining customer information, and monitoring social media require daily attention. While necessary, time spent on the tasks described tend to dilute focus on strategic aspects of your business.

Your employees work together, shouldn’t your software?

To run a business on several different software applications is challenging. A software package for accounting. Different applications for sales and customer support.

Strategic Tuning with Project Management

A Web site to market products

and services, another application to manage social media, and stand-alone shipping and receiving software can separately create information silos.

Share information between applications? Sometimes, between some applications. In most cases, employees have to re-enter data into each application, increasing the possibility of errors and decreasing productivity. A lack of integrated reporting hinders management from real-time information crucial to important decision-making.

Yes, integrated applications exist. However, for many businesses the costs associated with monthly, Cloud subscription pricing per user, installation, and maintenance can be off-putting unless persuasive evidence of long-term benefits are clearly articulated.

Consider a single, integrated strategy to run your entire business enhanced by the use of technology. An integrated strategy should connect project management with daily tasks, and your organization’s overall goals and objectives.

An ideal strategy:

  • Reduces IT costs.
  • Increases productivity because entering data is only required once.
  • Provides individual access to information in the Cloud. Role-based permissions define what functions each person can see and use, which dramatically improves productivity and efficiency.
  • Provides integrated reporting capabilities to give managers and employees a complete view of all facets of the business in real-time.
  • Allows industry terminology customization and on-the-fly reporting.

To develop an integrated strategy enhanced by technology requires a complete understanding (that only comes from experience installing and creating integrated systems) of Web-based, legacy, and enterprise solutions. Understanding all the front and back office functionalities needed to run a business, with tools to manage products, services, leads, customers, partners, vendors, and employees is difficult but not impossible to achieve.

Page 2 of 212