Microsoft Windows 10 Installation

Introduction:

Windows 10 launched on 29-July-2015, Microsoft is released its new OS in waves. Furthermore, some users are having trouble with Windows. If you have a genuine copy of Windows 7 or Windows 8.1, Microsoft’s Windows 10 Media Creation Tool, and an Internet connection. This process will take a bit longer than going through Windows Update. It’s the manual version of everything the “Get Windows 10″ tool is supposed to handle for you. Back up everything and make sure you’re ready.
If you’re running a 32-bit copy of Windows, download the tool from here. If you’re running a 64-bit copy of Windows, download the tool from here. If you’re not sure, hold the Windows key and press the pause/break button. See what it says under “System type.”

You should see the following after downloading and launching the tool:

Click on Next button and Windows 10 will start to download, which may take a while based on your network connection speed.

The verification of the download should be quick.

The Windows 10 installer is now being put together.

Once download completed, now the Windows 10 installer is being loaded.

The Windows 10 installer will do a few checks.

And more.

Click on “Accept” on this screen.

This part was automatic for me, but either way you’ll be given the choice again later.

Microsoft still needs to check if there are updates you may need before the installation.

And again, a few more checks.

Finally, the preparation is complete.

You can change what the Windows 10 installer will keep, but be warned that if you hit “Back” you’ll have to go through the updates and checks again.

Once started installation the first screen you should see, before your computer restarts:

The first step is copying files. You’ll then get a warning about a restart:

And then you’ll be on this screen for probably the longest part of the upgrade process:

After this is all done, just type in your password, hit Next, and go through the standard process of setting up the new OS.

Before long you should be back at your Windows desktop, as if nothing has changed. But a lot has: You now have Windows 10!

continue reading

The Red Hat JBoss Fuse Architecture

Introduction

IT system integration is one of the biggest challenges facing modern enterprises. Red Hat JBoss Fuse; one of the modern open source integration platform, using a lightweight standards-based, loosely-coupled approach. By relying on standards, JBoss Fuse reduces the chances of vendor lock-in. By advocating loose coupling, Red Hat JBoss Fuse reduces the complexity of integration.

An ESB is a standards-based integration platform that combines messaging, web services, data transformation, and intelligent routing to reliably connect and coordinate the interaction of significant numbers of diverse applications across extended enterprises with transactional integrity.

An ESB is typically defined by the list of services it provides. Services commonly included are:

• Transport mediation—not all applications and services that need to be integrated use HTTP or JMS.
• Dynamic message transformation—not all services use SOAP and are unlikely to require the same message structures.
• Intelligent routing—not all messages emanating from a source are intended for the same destination. The target destination will likely depend on some criteria inherent in the message.
• Security—only authorized and authenticated users need have administrative access to the JBoss Fuse runtime; services and brokers that handle sensitive information may restrict access by unauthorized or unauthenticated clients only; similarly, messages that contain sensitive information may be encrypted as they transit their routes.

An ESB simplifies the complexity of integration by providing a single, standards-based infrastructure into which applications can be plugged. Once plugged into the ESB, an application or service has access to all of the infrastructure services provided by the ESB and can access any other applications that are also plugged into the ESB.

Architecture

Red Hat JBoss Fuse has a layered architecture that consists of the following three layer as shown below.

Kernel layer

The Red Hat JBoss Fuse kernel layer is based on Apache Karaf, an OSGi-based runtime that provides a lightweight container into which you can deploy various components and applications.

The kernel layer interacts with the Services layer to set up, coordinate, and manage logging, and security; and to manage transactions on a per service basis. It also interacts with the Service layer to set up message broker instances with the configuration specified in the supplied activemq.xml file.

The kernel layer provides these features:

Console

The Red Hat JBoss Fuse console is a shell environment that enables you to configure all JBoss Fuse components and to control the JBoss Fuse runtime, including brokers and messages, JBoss Fuse kernel instances, logging, and so on.

Logging

A dynamic logging back end supports different APIs (JDK 1.4, JCL, SLF4J, Avalon, Tomcat, OSGi). By default, Red Hat JBoss Fuse enters all log messages in a single log file, but you can change this behavior by configuring different log files to store log messages generated by specific JBoss Fuse components.

Deployment

We can manually deploy applications using the osgi:install and osgi:start commands, or you can automatically deploy them by copying them to the hot deploy folder. When a JAR file, WAR file, OSGi bundle, or FAB file is copied to the InstallDir/deploy folder, it's automatically installed on-the-fly inside the Red Hat JBoss Fuse runtime.

Fuse Application Bundle (FAB)

FABs automate the creation and maintenance of OSGi bundles, freeing application developers to focus on building their applications.

Provisioning

Applications are provisioned through hot deployment, the Maven repository, and remote downloads.

Configuration

The properties files contained in the InstallDir/etc directory are continuously monitored, and changes are automatically propagated to the relevant services at configurable intervals.

Security

The security framework is based on Java Authentication and Authorization Service (JAAS). You can secure separately, Red Hat JBoss Fuse's OSGi container, deployed instances of the embedded messaging service, and deployed instances of the embedded routing and integration service.

OSGi container

We can deploy a variety of packages and files into Red Hat JBoss Fuse's OSGi container including Fuse Application Bundles, OSGi bundles, JARs, WARs, Blueprint, and Spring.

Dependency injection frameworks

The supported dependency-injection frameworks facilitate deploying new OSGi applications and updating existing ones dynamically:

• Blueprint
• Spring

Services layer

The Red Hat JBoss Fuse services layer consists of all of the interfaces and implementation classes for each of the embedded services. It interacts with the application layer to communicate with user-developed applications that want to access and use these services.

• Messaging

Using Red Hat JBoss Fuse's messaging service, based on Apache ActiveMQ, we can create JMS message brokers and clients, then deploy them as OSGi bundles. JBoss Fuse comes with a default message broker that autostarts when you start up JBoss Fuse, but you can replace it with your own message broker implementation.

• Routing and integration

Using JBoss Fuse's routing and integration service, based on Apache Camel, we can define routes and implement enterprise integration patterns, then deploy them as OSGi bundles.

• Web services

Using JBoss Fuse's web services framework, based on Apache CXF, you can create JAX-WS web services, then deploy them as OSGi bundles.

• RESTful services

Using JBoss Fuse's RESTful services framework, based on Apache CXF, you can create JAX-RS web services, then deploy them as OSGi bundles.

• JBI

Using JBoss Fuse's JBI service you can create and deploy Java Business Integration (JBI) 1.0 service assemblies and service units in JBoss Fuse. See Using Java Business Integration for an introduction to JBoss Fuse's JBI environment.

• Transaction Manager

JBoss Fuse's transaction framework employs a JTA transaction manager, based on Apache Aries, to expose various transaction interfaces as OSGi services. The transaction manager enables you to create and deploy JTA-based or Spring-based transacted applications in JBoss Fuse. Both the embedded messaging service and the embedded routing and integration service provide easy means for interacting with the transaction manager to implement JMS transactions.

• Normalized Message Router (NMR)

The JBoss Fuse NMR is a general-purpose message bus whose primary role is to transmit messages between the various application bundles deployed into the OSGi container. In this case, no normalization is required because OSGi places no restrictions on the format of message content.

However, when the JBI container is also deployed, the NMR is also used to transmit messages between OSGi and JBI applications. Normalization must be performed on messages transmitted to a JBI endpoint, because JBI requires that message content be formatted in XML, as defined in a WSDL service description.

JBoss Fuse provides a simple Java API for creating NMR endpoints that receive and process messages from the NMR and for writing clients that send messages to NMR endpoints.

Application layer

The JBoss Fuse application layer is where user-developed applications reside. JBoss Fuse provides many APIs with which you can create client and service applications that access and use the embedded services running within JBoss Fuse.

• Messaging—Client-side APIs
• Routing and integration—The Embedded Routing and Integration Service
• Web and RESTful web services—Front end options.

Download

S.No	File Name	Download
1	The Red Hat JBoss Fuse Architecture.pdf	Download

continue reading