Paremus logo
 
 
   
   
 
 
   
     
 
 
 
 
 
 
 
 
 
 
 
 
 
What does a Service Fabric offer to Architects?
 

The concept of ’middleware’ has remained largely unchanged since client-server computing emerged in the early 1990s. Middleware is static; middleware services are infrastructure stovepipes to which business applications are rigidly coupled. As business requirements and industry ‘fashions’ change, layer upon layer of middleware is introduced but rarely replaced which results in ever increasing cost and complexity.

Providers of Cloud Computing continue to repeat this fundamental error. By providing ‘baked-in’ middleware services, ‘Cloud platforms’ lock your business applications into their runtime infrastructure and make these environments impossible to evolve.

The Paremus Service Fabric provides a real alternative to this lock-in by providing an adaptive runtime that dynamically molds itself to your business requirements.

The Paremus Service Fabric is a reactive model-driven runtime. When provided with an application description, the Service Fabric not only deploys, assembles and maintains the associated application, but also any middleware services that it depends on. For example, deploy a WAR artifact and the Service Fabric responds by installing the appropriate WebServer into which the WAR is automatically deployed. Conversely, when an application is removed, all associated middleware and infrastructure services that are no longer in use, are also removed.

 

An end to middleware and protocol lock-in

By not mandating a particular architectural pattern or protocol, the Service Fabric removes the shackles that constrain applications to rigid infrastructure silos.

Application components can be co-located on a single Service Fabric node, or distributed across many nodes. Horizontal scaling is controlled either by customizable scaling behaviors that dynamically respond to changing business loads or manually by Operations.

Service Bindings describe how the components are interconnected and how the resultant Services should be exposed to external parties. Components can interact directly, or via an intermediary middleware of your choice including but not limited to: broker based messaging (JMS/AMQP), SEDA or Tuple Space patterns, or low latency broker-less peer to peer data centric messaging.
 

Embracing NoSQL

The era of the 'one-size-fits-all database/data-cache' is over. Increasing data volumes and differing Consistency, Availability, Partitionability (CAP) trade-offs are driving the use of new types of data stores, often referred to as NoSQL (Not only SQL) which include document databases, key-value stores and graph databases.

Recognizing this, the Paremus Service Fabric does not enforce any particular data doctrine. The industry’s most advanced private Java™ Cloud runtime, the Paremus Service Fabric supports a number of open-source and commercial NoSQL alternatives, making it the natural Platform as a Service (PaaS) solution for your next generation of NoSQL-based applications.
 
 
 
     
 
 
Terms of Use and Privacy Policy
Paremus, Paremus Nimble and Making Modularity Manageable are trademarks of Paremus Ltd. All rights reserved.
Copyright © Paremus Ltd 2001-2010