Infosys | Microsoft

Posted by Sidharth Ghag at 6:33 PM | Permalink | Comments (0) | TrackBacks (0)

As Service Oriented Architecture is becoming more and mainstream and enterprises start reaping the benefits of implementing them, there is a general trend in SOA implementation that each and every functionality be exposed as web service (read SOAP based service).

Many enterprises and external facing web sites have started following this and getting trapped into unduly excessive larger time to market and in turn losing business opportunities to competitors or else joining another failed SOA initiative.

If you happen to be part of team implementing SOA or following trends in web services implementation, surely you would have come across terms like Service Contracts, Policies, Web Services standards like WS* specifications–> WS- Reliable Messaging; WS-Security; WS-Interoperability; WS- Transaction; WS-policy; Service Discovery, Service registry, Service Governance, Service Versioning, SOAP message structure (header/body/faults), SOAP Protocols, XML Schema, etc..etc.

Each of the above term is quiet heavy and adds to complexity in rolling out web services based large SOA initiatives, however successfully dealing with these complexities fetches several benefits though.

To realize the Enterprise SOA vision and in turn expose functionality as services, does each one of the initiative have to go through this pain of dealing with so many complexities?

Probably not, and hence to address some of these complexities in web services implementation, there is a new style of web services architecture called REST (Representational State Transfer).

Representational State Transfer (REST) is an architectural style of building services on World Wide Web (WWW). It does so by leveraging the existing WWW architecture(http being backbone) which provides a way to navigate through web of resources like URLs, static or dynamic pages, Files, images, videos, and so on. REST logically organizes these resources and expose them through URIs to be consumed by external world. REST is a way or style to design services to be exposed in this manner. It is not proprietary to Java or .Net or any other technology or platform.

Some analyst address REST as simple XML without SOAP.

Before we dwell deep in to REST principles, let us revisit the key tenets of SOA

1. Boundaries are Explicit

2. Services are Autonomous

3. Services share schema and contract, not class

4. Service compatibility is determined based on policy

On the similar lines, REST based services are to built by using certain fundamental principles as below

1.Every Resource that merits being identified should be identified by Unique Id; it should be noun and not verb. To model REST based services, Map URIs to resource which may or may not represent application logic.

e.g. http://ibuy.com/Order/1234  identifies Order with an order id 1234. Order details like for which customer, list of products, total amount etc. can be captured as part of content of the document.  Customer, product are also potential resource and can also be uniquely identified using URIs.

2. Once URIs are identified for a resource, Use these id’s or URIs to link them together

A customer placed sample Order is depicted as follows

<Order ref   =”http://ibuy.com/order/1234”/>

                <amount> 15000 </amount>

<product ref= “http://ibuy.com/product/455” />

<customer ref =”http://ibuy.com/customer/20084 />

</Order>

3. Http methods are means to interact with these URIs

Use Standard http methods like GET (Read), POST (Create or Append), PUT (Update), DELETE (delete) to operate on these identified resources. These are the only verbs or methods/operations available in REST world as against many operations available under service in SOAP world.

Following is the mapping of SOAP operations to REST methods

 Resources are updated by sending the updated document or XML to the URL.

E.g. In RESTful system an Order will be updated by submitting the updated Order XML or document at the respective URI.

4. Allow multiple representation for same resource

Same Order can be represented in XML, Word Document, PDF, (X) HTML, JSON, ATOM and in various other formats.

5.Communication with Resource should be always stateless, if needed implement transactions through resource organization.

E.g. Save Checked out basket as resource and provide the Resource URL.

With the ground covered so far, by now certainly there are questions popping up, how can it deal with the complexities of business operations? Can it handle Transactions, Message Reliability, and Security; can it be used to build interoperable system, are organizations implementing REST? Is it main stream? Etc. Etc.

While I will try to deal with some of these over next a few blogs, here are some starters.

Google, photo site flickr, Yahoo services, and several other social sites like Facebook are built using REST based services. Amazon and ebay provides both SOAP and REST based services.

One word of caution though, REST will not completely replace SOAP Services, nor it is intended to, but some scenarios would definitely be easily addressed through REST than SOAP based Services. In other words REST can definitely start resting SOAP in some enterprise scenarios.

Posted by Sudhanshu Hate at 11:56 AM | Permalink | Comments (0) | TrackBacks (0)

I came across an interesting blog post written by Kris Horrocks where he has talked about building a textual DSL using MGrammar for home automation. The reason why he decided to build a DSL like this was to understand the gap between the Oslo team vision and the current state of the bits that customers are using. It’s worth reading this interesting post titled - "Oslo is running my house", to understand the power/potential of the Oslo platform. This I feel is a great example of how we can utilize the Oslo platform to do tasks other than just creation of enterprise applications or framework components. I am sure that this is just the beginning and going forward we would see more such interesting DSLs being written to solve interesting "real life" problems using the Oslo M Language. In fact we can already find some interesting stuff in the "M" Language Gallery. The "M" Language Gallery is the place to find grammar and schema definitions implemented by both Microsoft and the community.

Posted by E. Krishna Kumar at 5:38 AM | Permalink | Comments (0) | TrackBacks (0)

MS decided to "refresh" the January CTP to fix two issues with “three-pane mode” sample in Intellipad. This was mainly done because MS recieved quite a few reports of instability and performance issues with large grammars. You can download the "refreshed" Oslo SDK January CTP from here. Hope going forward we don't see the Intellipad crashing often!

Posted by E. Krishna Kumar at 9:27 AM | Permalink | Comments (0) | TrackBacks (0)

I wrote a small MGrammar for creating my own DSL and all I wanted to do was to make my DSL a Case Insensitive one. I thought this would be an easy task with the CaseSensitive attribute that I found in the MGrammar Language Specification Document that gets installed when you install the Oslo SDK. But when I used the attribute in my grammar, it just didn't work! Being a nascent technology, I couldn’t find much help on the web, but when I went through the Release Notes of the Oslo SDK Jan 2009 CTP, I could find a section for breaking changes, where I could find the fix for this problem. In fact MS has renamed the attribute to CaseInsensitive. It was just that the MGrammar Language Specification document had not been updated (don't know how could they miss this!) to reflect the same. CaseSensitive attribute was part of the earlier MGrammar specification.

So now if you want to make your DSL case insensitive you can decorate your language with the @{CaseInsensitive} attribute as shown below:

module HelloWorld {
    @{CaseInsensitive}
    language HelloWorldLanguage {
        syntax Main
          = Hello World;
        token Hello
          = "Hello";
        token World
          = "World";
        interleave Whitespace
          = " ";
    }
}

The above language doesn't just recognize "Hello World", but also recognizes "hELLO WoRLD", "HELLO world", "HeLLo wORlD" etc.

Posted by E. Krishna Kumar at 8:37 AM | Permalink | Comments (0) | TrackBacks (0)

Posted by Atul Gupta at 8:47 AM | Permalink | Comments (0) | TrackBacks (0)

Isaac Asimov imagines a world called Gaia. It’s a perfect world where the inhabitants communicate by consciousness. Through their collective consciousness they can heal themselves or even predict and avert a natural disaster. Science Fiction of a few decades ago tends to become technology in not far a future. So how far is the present day software from realizing Asimov’s Gaian hypothesis.

One of the foremost characteristics of an intelligent software is its ability to be autonomous. A system is autonomous to the extent that its behavior is determined by its own experience.

Service Orientation has taught us to think about software architecture and design in terms of actual business flows. But even as we try to take technology closer to business, one vital step we haven’t tried to address is the dynamism and uncertainty of business. For instance, a MoveItemToFolder service has no way of understanding the actual business need as to when and why the “item” needs to be moved to the “folder”. But like the humble slave, does its job whenever asked to do so.

Let’s assume the service knows a few good things about its business. And over a period of time, it keeps observing the items and where they are being moved. It begins to create patterns and actions out of them, and after a while begins to automatically move the “item”s to their respective “folder”s whenever required. Say, it observes that you always tend to move mails from “Barack Obama” into your Outlook archive named “Obamaniac” – it automatically creates a rule which does the work for you!

This might have been a very rudimentary example. But extrapolating this concept to a much larger level would enable us to create software which becomes more efficient and better performing the more you use it. That is, the larger its knowledge base (built out of observing its own behavior) the better is its performance, and hence its business benefit. It would also be a way of creating Predictable and Self-Healing applications – applications which can understand its own defects and take a corrective action if appropriate.

In the next post, we’ll discuss a very fundamental, but important aspect essential for developing such autonomous software – how do you make the software "understand" what you are doing.

Posted by Kishore Gopalan at 5:20 AM | Permalink | Comments (0) | TrackBacks (0)

So what is this whole thing about creating “intelligent” software? To understand where we need to go, we need to understand where we came from. So let’s take a step back and think of the most important thing (apart from learning your syntax) that you need to write your code.

Logic. The most important characteristic of writing any software is the underlying “logic”. In 1957, Herbert Simon and Allen Newell created the GPS (General Problem Solver) which takes in “Logic” and does a “Means-Ends Analysis”. Something like this,

"I want to go to the market to buy some seeds. What’s the difference between what I have and what I want? The distance. How do I reduce the distance? Using an automobile. What automobile do I have? A car. My car ran out of gas. Where to buy gas? In a Gas station..."

And so goes the Means-Ends analysis. This is useful to analyze a given problem and come up with a logic to find the solution. This, to a fair extent, actually reflects the human thought process of arriving at a logic to solve a problem. Given the year it was proposed, Means-Ends analysis was useful. But it does not say what to do when several actions can achieve the same goal, or when no action will completely achieve it.

When a present day software architect sits down to think of architecture for a Web Application, he has innumerable queries running in his mind. Clearly, we need ideas which are smarter than the Means-Ends analysis. Especially, if we want the software to be intelligent enough to understand and react to logic.

But will there ever be a limit to what a software can do? Over the years, many scientists have tried answering that question. The classic case being the Turing Test, that Alan Turing proposed in his seminal paper, “Computer Machinery and Intelligence” in 1950. Despite extensive research, no software program has developed enough sophistication to pass the Turing Test. But there are other schools of thought as well. The Infinite Monkey Theorem states that,

"a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will almost surely type a given text, such as the complete works of William Shakespeare."   (Source: Wikipedia)

In more concrete terms, monkey is a metaphor for a device (or software) that produces a random sequence of letters for infinite time. And the probability of Statistical Independence, in fact, proves mathematically that this theorem is true.

Corollary, if “random” intelligence of the Infinite Monkey Theorem has a probability of greater than Zero, then the probability of “deliberate” intelligence embedded as “Logic” within a software should also be possible at a much lesser and more definite time than infinity. So, we could safely say that the limits of software intelligence can be stretched to alteast such an extent that it passes the Turing test.

In this post, we establish the fact that “Intelligent” software is not a theoretical proposition, but a concrete notion, achievable in finite time. In the next post, we’ll continue to delve deeper into this notion.

Posted by Kishore Gopalan at 8:17 AM | Permalink | Comments (1) | TrackBacks (0)

We are at the forefront of a revolution in Software Development paradigms. Over the years, we’ve moved way ahead from struggling to manage the computer memory for our programs to writing globally distributed software services. But software development continues to be a dumb old process of writing reams of design documents, understanding and writing tons of lines of code.

In this new series titled “Next Generation Software Factories”, I will be discussing some ideas, outlooks and theories  of creating “intelligent” Software, based on our research. An intelligent software is one that understands its environment, is autonomous, reactive, proactive and social. Every now and then, I shall implement some of the ideas using upcoming Microsoft Technologies like Oslo and other technologies which will enable such development.

I’ll start off next, with a series of posts where I attempt to discuss the various aspects of an Intelligent Software.

Posted by Kishore Gopalan at 10:06 AM | Permalink | Comments (0) | TrackBacks (0)

Earlier today I came across this very interesting blog on how you can use english words to specify dates without having to use the Date dropdown control.

I tried adding Indian holidays to the Calendar and then search for them, but it didn't work. Let me see if I can figure out a way to do this, but the concept of finding dates by names is great. If you know how to add personal named dates, do share?

Posted by Atul Gupta at 6:32 AM | Permalink | Comments (0) | TrackBacks (0)

Posted by Archana Sachin Ghag at 4:14 AM | Permalink | Comments (0)

Cloud technologies being fairly nascent and the space evolving rapidly with the emergence of new players and re-positioning of leading platform players honing their products for the cloud has given way for several new and innovative opportunities to be explored but then its rapid adoption is being hindered due to several concerns primarily revolving around data privacy, loss of control, reliability etc... I shall touch upon reliability here.Read on..

The evolution of technologies such as the Internet, SOA and Virtualization which have laid the cornerstone for the Cloud, read more here, provides the following key benefits:

1. Low Cost
2. Global Scale
3. Better Agility

From a Technical standpoint, requirements could be as listed below:

1. Critical systems can still go on in spite of a network outage to the cloud
2. Client does not lose ability to execute even if cloud is down. Cloud is used for scalability and performance. But if required customer can turn off and roll back immediately. Get flexibility and benefit of cloud but don’t lose control.
3. No single point of failure
4. Access to near real time information at all times

From a Business standpoint, requirements could be as listed below:

1. What if the Cloud is not available tomorrow, will my business stop functioning?
2. Information available to me from my systems should be near real time if not real time.

I would attempt to address this problem statement by considering the Azure technology stack available from Microsoft today. And here are my thoughts behind developing, an Architecture for the cloud which is both reliable as well as resilient,

1. Code deployed on the Windows Azure platform will be on .NET and which is portable to run both on the cloud as well as on-premise AS-IS. Code can be executed on any platform that has the .Net Framework installed. The code you build for the cloud will not be locked-in.
2. Service based architecture will inadvertently address the integration issue. Hosting the service endpoints on the Azure .NET Services, provides for location transparency enabling service clients to be independent of the physical location of services. In our case a client request  can be transparently routed either to the cloud service or in case of failure to an On-Premise instance of the running service hence switch from active to passive link rather seamless for clients accessing the cloud.
3. In order to address the outage or unavailability issue, the Enterprise can host a failover site with a similar architecture running in an Enterprise Disaster Recovery data center. Although the Cloud by nature is designed to be available at all times, in times of eventualities when the Cloud itself goes down, a Low cost DR site or a Hosted Infrastructure will have to be kept alive with the “Lights On”
4. Cloud storage can also be a single point of failure. We can address that in this scenario  by using a 2-way sync / replication approaches using either SQL Server or the Microsoft Sync Framework

Below is a figure which depicts my proposed Reliable and Resilient architecture model that leverages the Cloud as well as the On-Premise world, with benefits realized by this design.

The application components get published on the cloud at the same time deployed to the data center during the Go-Live. A redundant set of binaries would exist which are duplicated on the cloud as well as in the data center. The binaries in the data center will seldom be used.

As can be seen, the additional DR site may marginally add to the overall TCO of an enterprise. However enterprises will have to weigh the costs with respect to the criticality of having an application available guaranteed 99.999% of the time to keep the business processes operational at all times.

Alternatively desktop applications can function in the absence of a cloud by providing offline storage and synchronization capabilities. This design is especially relevant in the following scenarios:

a. Augment to the functionality of on-premise  legacy applications by leveraging the cloud

b. Applications which have intermittent connectivity to the cloud

c.  Software + Services scenarios

More on this design pattern covered in my next blog.

Posted by Sidharth Ghag at 11:20 AM | Permalink | Comments (0) | TrackBacks (0)

A couple of weeks back I was trying to set up the Olso SDK (January 2009 CTP) on my system when I met with this problem. What was the problem? The problem was that whenever the setup tried to install the Repository database, it failed. The error message that I saw on the console didn’t help me much, neither did the entry in the RepositorySetup.log in the temp folder. Something which was very evident while going through the setup was that Repository setup GUI only supported creating a repository database on the default instance on the current machine. Another restriction is that the Oslo repository database can only be created on the 2008 version of SQL Server. Now the resolution to this problem was to do the setup by running the CreateRepository.exe by specifying the correct instance name of the SQL Server 2008 on our machine using /s switch.

The problem, cause and the resolution is given below:

Problem:

Oslo Repository creation not successful.

The RepositorySetup.log in temp folder says:
[2/19/2009 - 9:1:59]Start execution of: "C:\Program Files\Microsoft Repository\CreateRepository.exe" /s:. /v+
Microsoft (R) code name "Oslo" Repository Creation Tool version 3.0.1619.5
Copyright (c) Microsoft Corporation. All rights reserved.
Message: Creating repository database ...
Cannot assign a default value to a local variable.
Must declare the scalar variable "@login".
[2/19/2009 - 9:2:0]Completed execution of: "C:\Program Files\Microsoft Repository\CreateRepository.exe" /s:. /v+

Cause:

• The Repository setup GUI only supports creating a repository database on the default instance on the current machine.
• A Repository database can only be created on the 2008 version of SQL Server.

Resolution:

Run the CreateRepository.exe by specifying the actual instance using the /s switch.

D:\MS Oslo\My Samples\GeeksModel>"C:\Program Files\Microsoft Repository\CreateRe
pository.exe" /s:<MachineName>\<DBInstanceName> /v+
Microsoft (R) code name "Oslo" Repository Creation Tool version 3.0.1619.5
Copyright (c) Microsoft Corporation. All rights reserved.

Message: Creating repository database ...
Created repository database Repository on SQL Instance :<MachineName>\<DBInstanceName>
Message: Repository database statistics:
Message: Repository Status: Status=ONLINE, Updateability=READ_WRITE, UserAccess=
MULTI_USER, Recovery=SIMPLE, Version=655, Collation=Latin1_General_CI_AS, SQLSor
tOrder=0, IsAnsiNullsEnabled, IsArithmeticAbortEnabled, IsAutoCreateStatistics,
IsAutoUpdateStatistics, IsFullTextEnabled, IsLocalCursorsDefault
Message: Repository Size:    2048.00 MB
Message: Repository Owner: sa
Message: Repository Created: Feb 19 2009

Posted by E. Krishna Kumar at 3:49 AM | Permalink | Comments (0) | TrackBacks (0)