Microsoft Courier: A Secret Tablet

It's tablet-tablet everywhere, we have heard a lot about Apple iPad, Amazon Kindle, Cisco Cius, Dell Streak and now 'Microsoft Courier' to join the bandwagon. Courier: Microsoft answers to gadget world?

I have been following the news for quite some time that Microsoft is working on secret project headed by J Allard, Entertainment and Devices tech chief, which is close to its final prototype stage. I got curious to find the answers to some of the interesting questions like: What is so cool about this device? Is it worth to compare Courier with other tablet devices like iPad, a device from the UI guru Apple? Let's look at the device snapshot to find out:

Microsoft Courier is exact opposite of Apple’s iPad, it has twin screen that would fold like a book, a mashup of a pen (stylus) dominated interface with several types of multitouch finger gestures, and multiple graphically complex themes, modes and applications, 3x megapixel digital camera, pdf and MS Office support. Courier will use specialized version of Windows CE with a caveat that courier will only allow the applications that are designed to support courier booklet form factor. So, no-no to windows native applications.

Here is the link to check out more on Microsoft Courier:

http://www.youtube.com/watch?v=UmIgNfp-MdI

That sounds sounds so much to see in this digital-journal!

Well, we may not be able to see this device ever commercially. I read another news sometime back at Microsoft Blog that Microsoft killed the project completely. As per Microsoft VP of communications Frank Shaw: “At any given time, across any of our business groups, there are new ideas being investigated, tested, and incubated. It’s in Microsoft’s DNA to continually develop and incubate new technologies to foster productivity and creativity. The 'Courier' project is an example of this type of effort and its technologies will be evaluated for use in future Microsoft offerings.”

Right after this news I started seeing other hardware companies like Asus who has originally launched their tablet projects with Microsoft Windows 7 are now switched to Android.

Muhammad Rizwan

Cloud Computing and Retail

The much talked about topic these days is Cloud Computing but, does it make any sense to associate Retail with Cloud Computing?! We have often read this phrase at many business and technical articles that “Cloud has good potentials” and we often heard the big5 companies doing serious investments in this area. I think it is important to relook the concept of cloud computing before associating this technology with retail industry.

Not many businesses truly understand the concept of IaaS, PaaS and SaaS and the difference between public, private and hybrid clouds. But to me it’s a make-it or break-it decision while choosing the right cloud model for your business. We will investigate these models in a different blog.

Salesforce.com who I think are the real leaders for cloud computing identified a specific need; that it’s hard for a small to midsize business to manage big systems like CRM. With Salesforce.com, now those same companies only need a web browser. Another very important example is Amazon who has rated number 1 as the strongest retailer in 2010 according to RIS news.

Here are some of the top benefits a retailer would get out of cloud.

Quick and cost effective deployments: Salesforce.com is being used by the Japanese government to implement a nationwide eco-point program. Consumers get points for buying eco-friendly appliances and receive credits that they can use towards future purchases – and the entire system was built on Force.com site technology in three weeks.

Close relationship with customer: the most important step to build the relationship with customer is to know the specific customer needs. Cloud makes it easy to track customer buying pattern, which can further used for customer-basket-analysis and help to approach with right product at right time.

Cost effective inventory investment: cloud helps business to maintain daily sales, inventory reorder level and reporting. Cloud services also allows retailers to plan demand patten through online services dynamically whether that is directly in-house or through their suppliers.

Variety of platform supported: cloud enables retailers to reach out their customers through Web, mobile, or hybrid-applications that use the cloud.

Muhammad Rizwan

Of Pizza Boxes and Enterprise Payments

The enterprise payment world is undergoing a change. The days of proprietary payment systems, where everything from hardware to software to configuration was spelt out by software suppliers, no longer exists. Fueled by the fierce competitiveness in the payments world, innovation in enterprise payment systems are no longer being fore-fronted by payment companies or networks, but rather by companies who are looking for greater control and the ability to offer quick innovative solutions to the world.

I was asked in a recent interview what drives payments solutions in ISTS, and my answer was that we dream and realize development savings for our clients while delivering value, flexibility and robustness in an enterprise payment solution. That’s our guiding light. Technology. Innovation. Cost benefits.

We have never believed in a proprietary world, and have always advocated in affordable systems that can run on proprietary hardware using a lot of open source coupled with the best of the breed market systems to create layered and modular architectures that can be scaled up depending upon a client need or a client’s growth. We have never felt the need for a small retailer to go for a multimillion dollar hardware and software implementation.

Some of our very huge installation bases, which warrant astounding throughputs levels now, started with single boxes that we have clustered and scaled up over time, causing little or no investments to our customers. We have been able to do this by continuous product innovation and research in new technologies, and our ability to implement them in solutions. We have replicated this model successfully for different levels of enterprises, in geographies all around the world.

The future for enterprise payment systems would be driven by a number of factors,

1. How flexible and customizable enterprise systems are without people undergoing a huge learning curve, so that implementors and enterprises themselves could quickly customize them according to their needs

2. How much of service oriented architecture is provided so that work duplication is reduced to a minimum

3. What is the scalability model on the enterprise? Does the investment on day 1 have to be everything, or can it be scaled over time?

Let’s face it. If Google can run their entire real-time search bots on commodity hardware and scale up uninterrupted for the longest time, we see no reason why payment systems can't replicate that model.

Vivek Awasthi

Enterprise Class switches: Design Approach

While recently working on an almost year long enterprise project at ISTS, a bunch of us here at ISTS were required to spend a fair amount of time in thinking, designing and implementing the solution. At high-level business requirements was simple; we were supposed to build a system which should have capability to receive messages from merchant host systems and pass that message to a pre-paid card processor and yes must log the transaction activities to some persistent store. a.k.a Switch.

Complexity was not in the initial design; complexity arises further when message volumes, response times and multiple integration points are analyzed. During requirement analysis phase we analyzed that system has to:-

• Receive message from multiple host systems using multiple transmission and messaging protocols
• In-coming message based on card’s BIN number, message attributes and transaction types must route to a pre-defined processor
• Rules and Workflow has to be part of the system so that every message can be validated and certain business component can worked upon in-coming message
• Integration with multiple processors using their different transmission and messaging protocols
• Transaction log persistent
• Guaranteed response return to host system
• …and a lot more

Key designing factors to come up with a solution for fulfilling the requirements were not only using the industry proven well-known methodologies or design patterns but also the growing business needs. More merchant on boarding, multiple integration points, and adding extensive ‘unknown’ future-ability based on custom messaging protocols and addition of business components were some growing business needs.

After spending time on learning and designing, the known approaches and methodologies, we finally succeed in identifying, decoupling various parts of system based on their responsibility. Decoupling of various sub-systems and unified integration between these sub-systems helped a lot in building, managing and enhancing sub-system independently without affecting other pieces of the system.

Here is what the final design comprised of:

• Adapter (Receive and Transform): An adapter is an acquiring (receiving) side sub-system of Transaction Switch that is exposed to the acquiring merchant for accepting transactions. Adapter is responsible for accepting connections on a specific protocol on a specific exposed messaging specification. System is capable enough to accommodate as many as adapters are required.
• Core (Workflow, Rules and Persistent): Core functionality of the Transaction Switch is independent of any particular protocol, adapter or cartridge. All subsystems such as processor specific cartridges or adapters existing in the Switch is utilize directly or indirectly the functionality provided by the core system. All subsystems might have dependency on core system but the core system itself does not have any dependency with any subsystem. Core system will work based on the workflows and rules defined. All workflow and rules worked on IMF (Internal Message Format).
• Cartridges (Outbound Processor Implementation): Cartridges are implementation of issuer/ processor specification. Cartridges are responsible for establishing network connectivity with issuer/ processor, sending various requests to issuer/ processor and receiving response from issuer/ processor.

Some key frameworks/products used to develop this system are:

• Java: System is based on pure Java/J2EE platform and can run on Windows as well as on multiple flavors of Linux and UNIX.
• jPOS: jPOS is a open source Java® platform-based mission-critical financial transaction library/framework that can be customized and extended in order to implement financial interchanges, protocol converters, payment gateways, credit card verification clients and servers (merchant/issuer/acquirer). jPOS can help realize product or project in a significantly reduced time period which most often translates into greatly reduced costs.
• GigaSpaces: GigaSpaces is an implementation of JavaSpaces Technology. The JavaSpaces technology is a high-level tool for building distributed application. It is a tie, space & Data Grid based architecture. Communication between Cartridges, Adapter & Issuer participant happens through the GigaSpaces. Also all static configuration information can be stored in GigaSpaces for faster retrieval.

Summary:

Key design considerations, technologies helped us in achieving the peak TPS of 900 transactions per second and peak daily transaction volume about 4.5 million transactions. Because of the open nature of design, we have been able to whip up around 35 acquiring channels, and have interfaced with more than 100 processors/institutions.

Sanjay Mishra