Recent visitors to Alcatraz found the Main Prison open to SharePoint SME's. They were asked to fill in their SharePoint experience on boarding the cruise to get to the Rock. Not to mention, not all who on boarded the Cruise to the Rock get to board it back to the mainland.
Raja say's - All SharePoint SME's RUN FOR YOUR LIFE
Disclaimer: This photo is a modified version of the real thing. Just poking fun at myself and the rest of my clan...
Raja
Rather strange blog coming from a technophile, you might be thinking!
I was reading the newspaper this morning and this rather interesting table caught my eye
MALLESHWARAM UNDERPASS | CAUVERY JUNCTION UNDERPASS |
| Construction | Conventional | | Total Length | 180 meters | | Estimated Cost | Rs. 16.41 Crore ($ 4M) | | Actual Cost | Rs. 26 Crore ($ 6.5M) | | Work Started | July 2006 | | Status | Incomplete | | | Construction | Pre-Cast | | Length | 20 meters | | Estimated Cost | Rs. 1.5 crore ($ .37M) | | Actual Cost | Rs. 1.8 Crore ($ .44M) | | Work Started | January 16, 2008 | | Completed | February 20, 2008 | |
The accompanying article talks about how the Bengaluru Corporation Public Works is considering to bid adieu to the conventional method of constructing underpasses because of the obvious gains and less pains and the speed at which the works could be completed.
The gains that are discussed are these
1. Speed of completion of work - Imagine an underpass being completed in 35 days straight as opposed to 600+ days!
2. Save Money by avoiding dependencies on contractors who perpetually up their rates on various pretexts
3. According to estimates, the Malleshwaram underpass could have been completed using the precast elements in 60 days at a cost of less than $ 1.25 M. thus reducing the burden of citizen, road users and saving enormous amount of time, fuel and impact on the environment.
So what does it means to us - technophiles???
Here is the lesson - World is moving away from custom built, ground up solutions. More and more people are using technology to ensure that solutions are composed of pre-built blocks that could be assembled to suit the need on hand.
This is big lesson for software engineering. This shift towards low cost off the shelf components is certainly going to be more pronounced in the days to come. We are already seeing it.
1. Many more companies are implementing some sort of ERP system like SAP. They feel that it makes better sense to get something up quickly and customize it is fairly easier as opposed to invest in ground-up IT development and spend $$ and Time.
2. SharePoint as opposed to custom ASP.NET is another example. 81 of Fortune 100 are on SharePoint today. Obviously all of them cannot be collectively wrong on this.
3. Time is Money - A solution that is available now - is far useful than something that will come say 9 months later. Its like a bird in hand is worth two in the bush
4. Being able to start from Level 3 as opposed to ground zero has its own advantages
What does it all mean to us. Why should we be trying to quote this example and spending time reading this blog...
Good Question! I feel we as systems teams, should focus mainly on building these blocks that can be reused across. We should strive to get out of the project scenarios. We should think services, we should think what is the next pre-cast block that i can design and implement? How can i ensure that what i design today, can be easily reconfigured to do something else for someone looking for similar solution? How do I contribute to reduce the time involved in overall solution delivery (from conception to deployment).
We do have great technology examples for thinking about pre-cast blocks. SharePoint Features, Encapsulating app functionality behind Web Services, Service orientation of your software landscape are all great examples of this bent of mind. Our Core Platforms are designed to be your pre-cast blocks. Lets get an example out there to supplant the data in the table above with something that we did for E&D, that would be worth the while.
-Raja-
Here are some useful links for Development and Customization best practices for SharePoint
· Best Practices: Using Disposable Windows SharePoint Services Objects (http://go.microsoft.com/fwlink/?LinkId=105945&clcid=0x409)
· Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 (Part 1 of 2) (http://go.microsoft.com/fwlink/?LinkID=101494&clcid=0x409)
· Best Practices: Common Coding Issues When Using the SharePoint Object Model (http://go.microsoft.com/fwlink/?LinkId=105946&clcid=0x409)
· SharePoint Products and Technologies customization policy (http://go.microsoft.com/fwlink/?LinkId=105947&clcid=0x409)
The simple answer - it means different things to different people. But, to all of those different people it conveys the same idea - 'a portal is an entrance leading to something grand!'
Ever since I started developing for the web and during my first technical interview (about 9 years ago) this one question has confronted me - "What is a Portal?". Its only today that I got the time to validate my understanding with the accepted definition for the term. And its been an interesting discovery :)
So lets go back in time...when humans barely knew how to use metals, they were building portals...out of stone!
image source: Paulnabrone Portal Dolmen
What we see above is a portal dolmen, these were the grand entrances that our predecessors built for their dead. It was literally a 'gateway to heaven' for these folks at that time.
Then, as civilizations improved and the artist-engineer in us got more and more dominant, so did the portals.
Portals in architecture is a general term used to describe a grand entrance to an important structure. These might have been gates, fortified openings and even windows.
So, historically portals were used to control entries and exits. Due to the fact that they were among the first things that people experienced while entering that chapel or a palace or a fort, Portals were decorated and fortified with all that was necessary to make them beautiful, safe and secure.
We continue to do this even today. Our portals, the software kind, look a lot less imposing, but they are no less functional in what they achieve.
image source: Duke_Chapel_Portal
Today, our enterprise portals are software infrastructure. A framework that helps integrate information, people and processes across organizational boundaries. This infrastructure serves a myriad purposes. Like fractals, portals can be thought of as fractals, take small building blocks, compose them to work together in many iterations till you end up with a visually appealing image. That's your Portal.
Fractals are a shapes constructed of recursive containment of similar shapes, so are Portals.
What fascinates me about both is that the possibilities of creation are endless. In this age and in this time, we need to be creative, we need to be artists. Artists who create solutions. Most importantly, these are images of infinite complexity, but the building blocks are simple shapes.
Other interesting Facts about Portal:
1. Portal is a city on the Canadian border in north Dakota. Portal sits near the Canadian border and is a major port of entry for road and rail traffic. It is one of three 24-hour ports in North Dakota
2. Portal is a large large vein that carries blood from the digestive tract to the liver.
-Raja-
Uploading Images is quite easy with Windows Live Writer. This is my profile pic from TechMela.
Answers to these and more questions on this well made PPT deck. Have a look when you have some free time…
http://www.ronjacobs.com/Noodle/default.htm
I am so excited to test the blogging feature of Office 2007 Beta 2. I am typing this blog entry in word and all I have to do is say publish from within the comfort of Word 2007.
All the best Word 2007! You guys rock!!!
Just upgraded to Beta 2 of Windows Workflow and opened up my beta 1.2 Host Communication Project. Ended up with 11 Errors and a missing Namespace. I went through the code and the documentation and compiled a list of changes for the Host Communications part. Here my list of changes from Beta 1.2 to Beta 2 with respect to Host Communications.
Since i am seeing a lot of problems in inserting a table into this blog, i will have the following format:
System.Runtime.Messaging changed to System.Runtime.Activities
Change Description
Messaging namespace has gone and the local communications functionality has been moved to Activities namespace.
If your code looked like this in Beta 1.2
using System.Workflow.Runtime.Messaging;
It would look like this in Beta 2.0
using System.Workflow.Activities;
WorkflowMessageEventArgs changed to ExternalDataEventArgs
Change Description
WorkflowMessageEventArgs has been renamed to ExternalDataEventArgs. This is just a rename and as long as you use the correct name, your code should work.
If your code looked like this in Beta 1.2
internal class myServiceEventArgs : WorkflowMessageEventArgs
It would look like this in Beta 2.0
internal class MyServiceEventArgs : ExternalDataEventArgs
DataExchangeService changed to ExternalDataExchange
Change Description
ExternalDataExchange is the workflow communication interface that defines the contract between a local service and a workflow.
If your code looked like this in Beta 1.2
[DataExchangeService] internal interface IMyService
It would look like this in Beta 2.0
[ExternalDataExchange] internal interface IMyService
ExternalDataExchangeService has been made visible to the outside world
Change Description
This class has been exposed in Beta2.0. In the current release, you will have to instantiate this class, add it to the runtime and then add your local services to this class. In Beta 1.2, you were able to add the local service directly to the runtime.
If your code looked like this in Beta 1.2
WorkflowRuntime workflowRuntime = new WorkflowRuntime();
LocalServiceImpl localService = new LocalServiceImpl();
workflowRuntime.AddService(localService);
It would look like this in Beta 2.0
WorkflowRuntime workflowRuntime = new WorkflowRuntime();
// Create our local service and add it to the workflow runtime's list of services
ExternalDataExchangeService dataService = new ExternalDataExchangeService();
workflowRuntime.AddService(dataService);
LocalServiceImpl votingService = new LocalServiceImpl();
dataService.AddService(localService);
InvokeMethod Activity changed to CallExternalMethodActivity
Change Description
The InvokeMethod Activity has been renamed to CallExternalMethodActivity. OnMethodInvoked and onMethodInvoking Events have been added. “Verb+ED” events will fire after the action has happned and “Verb+ING” events will fire before the action has happened. So, in this case, the OnMethodInvoked event will fire after method invocation and OnMethodInvoking event will fire before method invocation.
EventSink Activity changed to HandleExternalEventActivity
Change Description
The EvenkSink has got a new name and a new event. So in place of EventSink, you will find HandleExternalEventActivity. OnInvoked Event has been added. This is will be fired after the Activity is invoked.
The Workflow Designer has got some enhancement in the property window and avoids the confusions when adding properties and accessing properties. It gives you much more information. Overall a pleasant change from the 1.2
That’s it on the Host communications, Enjoy Beta2….
Back after a long gap [:D]
Recently the partner that i am currently working with came up with an interesting question, they were planning for a Office 2000 migration and wanted to know what had changed in Office 2000, what are the features introduced in Office 2003 etc.
At first this information was not found anywhere, even the product team says that there is no such list. But, there is however a white paper that describes the delta of changes between Office 2000 and Office 2003. (Note: Such a list is actually being worked upon by the product team for Office 12 changes and this would be available to everyone through MSDN and TechNet.
The whitepaper could be found on this url:
http://www.microsoft.com/downloads/details.aspx?FamilyID=24946d36-002e-4137-af13-50c92ed86ed9&DisplayLang=en
I would like to thanks Kay Warren for helping me out on this issue and providing the link and the information.
Refer to my earlier post of on the
Infopath+Service Broker Cocktail well what a punch it delivers. I am almost ready with the sample. Watch this space!!!
Today, unlike most days, i have achieved something. Yesterday was also similar. I had to rebuild the my laptop. Re-load all the software, restart my life!
My laptop, is probably most worthy work tool that i have with me nowadays. I lug it along with me every day, day in and day out. Its my paraphernalia.
I work as a Solution Architect and a major percentage of my time goes into prescribing the best practices, right way of solving problems and well...solving problems. One morning, i went to my client office, started unpacking my bag and setting up my laptop. This thought struck me...what is the difference between a fortune teller and me?
A fortune teller, sits in the bazaar, has a set of tarots and has his parrot that picks up a card at random. I have a laptop, i have a stack of tarots (patterns) that i save in a part of my brain, i have experience (which is my parrot) that picks up the right pattern for the problem at hand. Most of the times my parrot is not as lucky as the fortune tellers parrot as it has to work on an infinite set of tarots that are getting added to the stack over time. My laptop is my gateway to the world of information and my tool for communication.
Enough of horse manure...you say...lets come back to my story as i originally began writing it...
My laptop due to indiscriminant abuse (loading softwares and mostly beta stuff) was getting bogged down, its precious processing cycles were getting eaten up by myriad of software pieces, remnants of old programs that wont go away, programs that i always wanted to know more about but never found the time to know, programs that i never know existed on my laptop, programs that i was planning to use, programs that i used...overall a shitload of programs!!!
So this day i decided to give a fresh lease of life to the laptop...cleaned up the laptop and loaded carefully only what i wanted to load. Once its done, i see a fresh glisten whenever i start it up. I used to boot it up earlier...now the laptop seems to smile at me every time she starts.
That gives me a sense of achievement...i have managed to give a new lease of life to a seemingly inanimate object, and, that objects responds favourably!amazing isnt it?
Thats why i get this feeling of achievement!
I am trying to make InfoPath work as a preferred client for SQL 2005 Native Web services. Here is what I have in Mind
- SQL 2005 native web services and Service broker form a tremendous pair for developing asynchronous solutions. For Example, a workflow framework that is hosted in SQL.
- InfoPath with the XML support is a natural choice for throwing out user readable forms. This data thus captured/edited/acted upon in any other way can be sent to SQL through a simple SOAP post.
- I have worked on and sorted out the post part and also have the mechanisms necessary to get the Service Broker logic started. But the problem lies in consuming the some web services (Receive WS).
- This is where I was stuck. I thought we could write some sort of an InfoPath/SQL 2005 adapter that would make things easy for InfoPath to receive data like error messages, status updates etc.
- I have already explored the Secondary data source route…but wanted to know if there was a more standard and reusable way to get this to happen.
- I would not want to introduce an ASP.NET WS (.asmx) unless it’s absolutely necessary as it’s an extra layer and I want to eliminate that extra infrastructure.
Any pointers???
I have been having animated discussions on using Infopath as the frontend for 3 tier applications. Infopath forms are very good XML consumers, throw a schema at it and it throws back a rich UI. They are also fantastic XML generators. If you want to use ASP.NET instead, you will have to do the custom XML parsing yourself and also have to handle the code for generating the UI and the bindings.
Lets suppose we have a situation where in you have some predefined schema's of data that need to be captured. You are using XML capable DB server like SQL2005. Also assume that you have a well defined set of business components that implement all the necessary logic for creation of the business entities (as XML schema instances) and also you have your DB accept predefined schema instances through users. Here comes the big lollypop...all your clients already have Office 2003 (SP1) installed....
In this situation, would it not be easier to just snap on a web services facade on the business layer and then have Infopath access this facade? Or would ASP.NET web pages be the way to go...
I know i am trying to compare apples and oranges here, but the crux of the matter is that Infopath templates can be published with some logic in them, they can saved onto a users machine and submitted once the user is online....they represent a paradigm shift with respect to usage of Smartclients as opposed to browser based thin clients. But, and its a big but in this case, does Infopath usage be justified as an optimum solution, how would users react to accessing a crucial applications through Infopath without any 'comfort feeling' of having either a Windows Forms app or a web site that would logically give them some feeling of a real application?
On the usage aspect, i feel, users ( and developers alike) are not used to the idea of 'not' having a windows form client or a web application. Today most developers seem to think that any 3 tier application development has to have a Web interface, they have to have a HTTP endpoint and some submits and some page navigation etc etc...I have participated in one too many discussion where developers vehemently oppose any idea of anything else other than a browser based client ( leave alone Infopath) as the UI, my experiences prompt me to ask these questions:
- Why do developers feel that all application development is only Web application development?
- Am I isolated in these experiences?
- Are there others who have experienced such situation?
- Am I missing something here that is glaringly evident to everybody else on this side of the planet?
Any ideas???
I have been trying hard to understand SQL Server 2005 (Yukon) from the XML perspective. OPENXML, SQLXML and the works. I had used Infopath since its XDocs days and knew that it had a lot of XML capabilities. Recently I developed a kind of fancy towards SQL Service Broker because of my belief that it was one of the tools that we all can play with today to learn about Services and Service Oriented Systems.
One day (not under the bodhi tree!) i got a sort of an idea, how about a message oriented architecture using Infopath, SQL2K5 and SQL2005 and Yukon. SQL Server 2005 is my service facade, hosts my app logic ( SP's) like any good application server does and also acts as a Service broker and enables reliable, once only and in order delivery of messages. Not to mention maintains all my data like a good dB :).
Infopath talks to SQL2005 Http/Soap EndPoints and then plainly submits to the webservice. Infopath is good at submitting to Web services and it pretty cool at receiving data through web services. More to come about how to achieve this. There is a little mantra that we need to use....its called as "wsdlsimple" mantra.
The SQL2005 webservice is nothing but an exposed Stored Procedure. This stored procedure processes the payload. The payload processing part is to create a dialog conversation on behalf of Infopath user and submit a message to a predefined queue.
Once the message has been submitted to the queue, the stored procedure can return safely and joyfully as its work is complete. The infopath forms can also joyfully announce to the user that the message is in safe hands and is guaranteed to go to the intended receipient. This is where the cool things start to happen...
The message is then processed by the Service Broker, by an activated Service Application, this application can work on behalf of the Infopath user and route the message to other services in a truly asynchronous manner. And also update the status of the processing in some dedicated queue meant for the Infopath users or this can be a notification to the user using SQL services Notification services of SQL server 2005.
I knew xml was powerful, but to realize that it can do so many things for you , if used properly...is such a pleasant surprise.
On the road to Indigo...( thats Richard Turner..right??) you will pass through Yukon Service Broker. The Service broker is a set of services on the data base layer that provide the framework for distributed, aysnchronous message based database applications.
I got really excited when i saw this, we can actually build service oriented applications today just by writing a couple of T-SQL statements. Yes you read it right. Now you can decouple your applications and distribute them over time spans and geographies and export them as services on a network just by using T-SQL.
Its actually powerfull stuff. Pat Helland ( of Metropolis Fame) is the architect of this rather cool piece of infrastructure.
If you want to learn the aspects of Indigo, but dont know where to go...learn the concepts by using Yukon Service Broker. Yukon is in its second beta and comfortably stable.
Get started on Service Broker, get a feel of how a SOA app should work...experiment...burn the midnight oil...its well worth the investment.
Get back to see what i post as i learn the Service Broker based apps.
