When making a strategic cloud decision, organizations can follow either one of two ideologies: open or closed.

In the past, major software technologies have been widely accepted because an emerging market leader simplified the initial adoption.  After a technology comes of age, the industry spawns open alternatives that provide choice and flexibility, and the result is an open alternative that quickly gains traction and most often outstrips the capabilities of its proprietary predecessor.

After an organization invests significantly in a technology, the complexity and effort required steering a given workload onto a new system or platform is, in most cases, significant. Switching outlays, shifting to updated or new software/hardware platforms, and the accompanying risks may lead to the ubiquitousness of large, monolithic and complex ERP systems – reason not being that they offer the best value for an organization, but rather because shifting to anything else is simply – unthinkable.

There’s no denying that these are critical considerations today since a substantial number of organizations are making their first jump into the cloud and making preparations for the upsetting shift in how IT is delivered to both internal and external clientele. Early adopters are aware of the fact that the innovation brought about by open technologies can bring dramatic change, and hence are realizing how crucial it is to be able to chart their own destiny.

As the cloud buzz is getting louder with every passing day you are tempted to take the big leap into the cloud but may have restrained yourself paranoid by ad infinitum cloud security discussions floating on the web. No one can deny the fact that your data is the lifeblood your business. So, undoubtedly its security is of paramount importance for survival of your business.  As cloud computing is a paradigm shift from the traditional ways of using computing resources, you must understand its practical security aspects.

Is Cloud Computing Safe?

There can’t be a binary answer (Yes or No) to this question. But with my experience and as an authority on the subject I can tell you that technologies enabling Cloud services are not in any way less secure than the traditional or on-premise hosting model.  Also, with the evolution of technology, the cloud providers are getting matured and almost all the providers are offering built-in security, privacy, data backups and risk management as a part of their core service.If you are not a big IT company then you must ask yourself:

·         Can an on-premise solution or a traditional hosting provider match the same level of standard security and privacy requirement as provided by the specialist cloud provider whose core competency lies in providing state of the art security and privacy?

Since its foundation, HSG has been a leader in Business Rule Management Systems Training and Consulting services by way of the Blaze Advisor Rule Engine.  Over the years we have provided such services to many of the worlds largest corporations and government institutions whose respective backgrounds include credit card processing, banking, insurance, health and medicine and more, much more.  Such training and consulting services have included:

Create a wrapper object model in either Java, .NET or XML

Identify and catalog business rules

Develop a rule architecture within Blaze Advisor that isolates rule repositories as they relate to functionality and corporate policies

Configure, develop and implement a variety of interfaces to the rule engine from disparate systems ranging from mainframe applications written in Cobol to UNIX/Windows applications using Enterprise Java Beans, Windows Services, Web Services, Fat Clients, Java Messaging Services and Web Applications.

Review and update code to boost efficiency either by way of

    Removing functions calls within conditional statements

    Ensuring that database calls are essential or can be rearchitected in some other manner

    Employing the rete algorithm where necessary

    Paring down extensively large class models

    Deploying such appliations in multi-threaded systems

·         ...

Call us if you:

    are in need of Blaze Advisor Expertise
    are developing SMEs in Blaze
    want to speak directly with an expert (no placement agencies)
    want an affordable alternative to FICO
    want to work with an industry leader

I will begin our blog on Java Tutorial with an incredibly important aspect of java development:  memory management.  The importance of this topic should not be minimized as an application's performance and footprint size are at stake.

From the outset, the Java Virtual Machine (JVM) manages memory via a mechanism known as Garbage Collection (GC).  The Garbage collector

• Manages the heap memory.   All obects are stored on the heap; therefore, all objects are managed.  The keyword, new, allocates the requisite memory to instantiate an object and places the newly allocated memory on the heap.  This object is marked as live until it is no longer being reference.
• Deallocates or reclaims those objects that are no longer being referened. 
• Traditionally, employs a Mark and Sweep algorithm.  In the mark phase, the collector identifies which objects are still alive.  The sweep phase identifies objects that are no longer alive.
• Deallocates the memory of objects that are not marked as live.
• Is automatically run by the JVM and not explicitely called by the Java developer.  Unlike languages such as C++, the Java developer has no explict control over memory management.
• Does not manage the stack.  Local primitive types and local object references are not managed by the GC.

So if the Java developer has no control over memory management, why even worry about the GC?  It turns out that memory management is an integral part of an application's performance, all things being equal.  The more memory that is required for the application to run, the greater the likelihood that computational efficiency suffers. To that end, the developer has to take into account the amount of memory being allocated when writing code.  This translates into the amount of heap memory being consumed.

Memory is split into two types:  stack and heap.  Stack memory is memory set aside for a thread of execution e.g. a function.  When a function is called, a block of memory is reserved for those variables local to the function, provided that they are either a type of Java primitive or an object reference.  Upon runtime completion of the function call, the reserved memory block is now available for the next thread of execution.  Heap memory, on the otherhand, is dynamically allocated.  That is, there is no set pattern for allocating or deallocating this memory.  Therefore, keeping track or managing this type of memory is a complicated process. In Java, such memory is allocated when instantiating an object:

String s = new String();  // new operator being employed
String m = "A String";    /* object instantiated by the JVM and then being set to a value.  The JVM
calls the new operator */