Jounrney to old Hoysala tempels in Mandya.
Check the picture here
http://picasaweb.google.com/praveen.kulakarni/MandyaTrip
The journey begin from Mandya in My New car Turbo DLG..
My freinds as come from Bangalore to Mandya in bus and later joined me in Mandya.
our journey begin at 9 from Mandya on 21st OCt Sunday 2007,
Started with Tiffin in Shivalli(Dudha) near Mandya and went to Melkote
MELUKOTE:
Yoga Narasimha Temple:
After driving up a few narrow winding streets we reached the parking place at the foot of the hill.We reached Melukote at 10.30 am. On the top of the hill there is a temple of Yoga Narasimha. To reach here you have to take big steps( half way you can go by vehicles . There are around 30 to 40 steps to reach temple. Temple is 1,777 mtr above from the sea level. After reaching the temple we could able to see a beautiful nature surrounding. It is a 1000year old temple and here we could not find that beautiful architecture still is looks good.We spent 30min in the temple.
AKKA TANGI KOLA:
This KOLA(pond) is near to the temple.There are two ponds in one pond there is dirty water(in Akka kola) and in another pond there is clean water(TANGI kola). We asked the reason for this to one old lady she told "The younger sister was willing to build a pound but elder sister was not interested for this. At last both built a different ponds, in younger sister's pond there was a clean water but in elder sister's pond dirty water because she was not interested for this". The main thing is we could able to differentiate both pond water.
Tiru Narayana:
Then we head in to the town there a big Tiru Narayana temple. We parked the car and started walking towards the temple, on the way we got a beautiful KALYANI (water pond surrounded by steps). Here people were taking bath and praying to god. After that we entered to temple, this is a large temple surrounded by an open veranda in side that there were so many beautiful carved pillars. We spent some time there and took many photographs. I asked Praveen "how was they able to do this type of design in stone?" He gave a smile and replied they were intelligent.
Now its 12 noon, we left for the Hosaholalu its nearly 27km from here near K.R.Pete.
Hosaholalu:
We reached K.R.Pete at 12.45 and had lunch and started driving towards Hosahoralu. It is trikuta (three shrined) Lakshminarayana temple. Here the temple was closed and we could able to see only from the outside. The outer wall is with the beauties of deities made up of stone. Here i surprised by seeing this sculptures. It is worth going here. And again I asked the same question to praveen "how was they able to do this type of design in stone?" and got the same reply.We spent more than 45min here.
Praveen explained me some sculptures meaning. Before this i never used to enjoy in temple but this time i enjoyed and got to know so many things. Thanks to Praveen.
Govindanahalli:
This was our main destiny to see, whole journey started to see this panchalingeswara temple...
Its nealy 15km from the K.R.Pete . Its difficult to reach here by bus and we did't see a single board to show the way.Here we had to struggle little bit to reach here.
On the way we saw an accident between bike and Maruthi Omni ,..just a small hit from bike caused lot of damage to maruthi omni car,..The bike person head has come out and the child sitting inside maruthi got fractured..
So,..started driving carefully.......
We reached the temple by 2.30 and here also temple was closed. Its a very big temple panchkuta (five shrined) Shiva temple. In the entrance two Veera bhadhreshwara sculpture and opposite to the main entrance a beautiful sculpture Nandi. We spent 20min by seeing out side the temple after that one lady came and opened the door of the temple. Inside the temple there are mainly five Lingu's situated with the different names and there are number of lined carved pillars and as usual so many sculptures on the wall.
One thing which i wanted to tell is,.. we should give proper publicity to these type of places,..
till we come here we never thought it will be such a nice place with cool atmosphere,...
Govt. and also the people should give proper publicity and help to preserve these old temples....
From here we started journey back to Bangalore at around 3.15pm. On the way to mandya we stopped in AALE MANE(the place to prepare jaggery) near Bedara Halli pandava pura distict. HeY.. we had a mugs of nice sugercane juice and fresh jaggery(it will be in jelly state).
Even thoe I had these alemane experence many times in my child days , its a different exp for my bangalore fnds,..
Even I enjoyed a lot ....
Please see the pics in this URl
Picture of trip
Tuesday, October 23, 2007
Friday, October 19, 2007
What is UDDI
Note On UDDI
What is UDDI
Web service standards have made outstanding progress. However, let's take a quick step backwards to examine an older standard called Universal Description, Discovery and Integration of Web services (UDDI).
The UDDI specification defines a SOAP-based Web service for locating Web services and programmable resources on a network. It offers a foundation for sharing information about internal services across the enterprise and public services on the Internet.1
UDDI Programming Model
XML Web Services has been the toast of the .NET Framework, however Web Services are not a .NET invention – they were available before .NET. So why are they so popular under .NET? Because the set of tools available under Microsoft .NET Framework lets the developer build sophisticated Web Services with little difficulty. Developers are embracing Web Services at an exponential rate under the .NET framework. With this popularity increase, UDDI is emerging as the preferred mechanism to discover the Web Services. This article is aimed at advanced users familiar with UDDI so I will be skipping the introductory lessons and dive into UDDI details from the start. In the second half of this article we will put our knowledge into use by building an ASP.NET UDDI browser using web forms.
We will first explore the UDDI data structures, then we will investigate the UDDI API version 2.0, this is the most recent version of the UDDI API. The best place to find more technical details on UDDI is www.uddi.org.
UDDI API Data Structures
UDDI has 4 main data structures.
All the information is stored as predefined XML formats. First we will try to understand the responsibilities of each structure. Then we will learn how these structures work together to create UDDI.
Business information ( businessEntity XML Format)
Service Information ( businessService XML Format)
Binding Information ( bindingTemplate XML Format)
Specifications for the services offered ( tModels XML Format)
businessEntity Data Structure
You only need a businessEntity element to publish data within a UDDI repository. The other data elements are optional. During the discovery phase, the businessEntity element serves as a handle to retrieve pertinent information about a company.
businessService Data Structure
Service information deals with technical and business descriptions. Each Web Service has one or more technical web descriptions. These technical descriptions include information to communicate with clients. Those could be:
URLs, addresses to communicate to child Web Services.
Configuration options on the host web server.
Prerequisite Web Services that should run before this Web Service.
Load Balancing information on the host web server.
bindingTemplate Data Structure
The information about invoking a Web Service is documented in a XML structure called bindingTemplate.. The bindingTemplate"binds" technical and business data to a Web Service. So what information do we bind? We need to know all the technical information for seamless integration of the Web Service. Here are some of those questions if we implement a Web Service to handle purchase orders.
We need to know the format of our purchase orders?
Are they in a specific XML format geared towards online transactions? (eg. OBI – Open Buying on Internet)
What are the required security implications to access purchase orders?
In order to integrate the Web Service we need to answer all these questions, therefore we need XML structures to represent this information inside the Web Service bindings. These structures are commonly referred to as "tModel".
tModel Data Structure
This is probably the most interesting data structure. UDDI draws a distinction between abstraction and implementation with its concept of tModels. The tModel structure, short for "Technology Model", represents technical fingerprints, interfaces and abstract types of metadata. Binding templates are the concrete implementation of one or more tModels. Inside a binding template, one registers the access point for a particular implementation of a tModel. tModels can be published separately from the binding templates that reference them.
Each tModel also gets a unique identifier, this will enable other applications to refer to it, these tModels make up bindingTemplate structures. The tModels represent all the integration information to consume a Web Service. The different service providers can easily build a software product to consume the Web Service as long as the tModels are compatible.
check this link for more details
http://www.microsoft.com/windowsserver2003/technologies/idm/uddi/default.mspx
What is UDDI
Web service standards have made outstanding progress. However, let's take a quick step backwards to examine an older standard called Universal Description, Discovery and Integration of Web services (UDDI).
The UDDI specification defines a SOAP-based Web service for locating Web services and programmable resources on a network. It offers a foundation for sharing information about internal services across the enterprise and public services on the Internet.1
UDDI Programming Model
XML Web Services has been the toast of the .NET Framework, however Web Services are not a .NET invention – they were available before .NET. So why are they so popular under .NET? Because the set of tools available under Microsoft .NET Framework lets the developer build sophisticated Web Services with little difficulty. Developers are embracing Web Services at an exponential rate under the .NET framework. With this popularity increase, UDDI is emerging as the preferred mechanism to discover the Web Services. This article is aimed at advanced users familiar with UDDI so I will be skipping the introductory lessons and dive into UDDI details from the start. In the second half of this article we will put our knowledge into use by building an ASP.NET UDDI browser using web forms.
We will first explore the UDDI data structures, then we will investigate the UDDI API version 2.0, this is the most recent version of the UDDI API. The best place to find more technical details on UDDI is www.uddi.org.
UDDI API Data Structures
UDDI has 4 main data structures.
All the information is stored as predefined XML formats. First we will try to understand the responsibilities of each structure. Then we will learn how these structures work together to create UDDI.
Business information ( businessEntity XML Format)
Service Information ( businessService XML Format)
Binding Information ( bindingTemplate XML Format)
Specifications for the services offered ( tModels XML Format)
businessEntity Data Structure
You only need a businessEntity element to publish data within a UDDI repository. The other data elements are optional. During the discovery phase, the businessEntity element serves as a handle to retrieve pertinent information about a company.
businessService Data Structure
Service information deals with technical and business descriptions. Each Web Service has one or more technical web descriptions. These technical descriptions include information to communicate with clients. Those could be:
URLs, addresses to communicate to child Web Services.
Configuration options on the host web server.
Prerequisite Web Services that should run before this Web Service.
Load Balancing information on the host web server.
bindingTemplate Data Structure
The information about invoking a Web Service is documented in a XML structure called bindingTemplate.. The bindingTemplate"binds" technical and business data to a Web Service. So what information do we bind? We need to know all the technical information for seamless integration of the Web Service. Here are some of those questions if we implement a Web Service to handle purchase orders.
We need to know the format of our purchase orders?
Are they in a specific XML format geared towards online transactions? (eg. OBI – Open Buying on Internet)
What are the required security implications to access purchase orders?
In order to integrate the Web Service we need to answer all these questions, therefore we need XML structures to represent this information inside the Web Service bindings. These structures are commonly referred to as "tModel".
tModel Data Structure
This is probably the most interesting data structure. UDDI draws a distinction between abstraction and implementation with its concept of tModels. The tModel structure, short for "Technology Model", represents technical fingerprints, interfaces and abstract types of metadata. Binding templates are the concrete implementation of one or more tModels. Inside a binding template, one registers the access point for a particular implementation of a tModel. tModels can be published separately from the binding templates that reference them.
Each tModel also gets a unique identifier, this will enable other applications to refer to it, these tModels make up bindingTemplate structures. The tModels represent all the integration information to consume a Web Service. The different service providers can easily build a software product to consume the Web Service as long as the tModels are compatible.
check this link for more details
http://www.microsoft.com/windowsserver2003/technologies/idm/uddi/default.mspx
Friday, October 12, 2007
Differences between using web controls and using HTML controls in dotnet application
This is a note on differences between using web controls and using HTML controls in dotnet application,which I feel more useful and sharing with you all.
The confusion that I had, and I think some of you may also have, is that why provide two type of controls that almost provide similar functionality, i.e. that both the controls are executed on the server side , both the controls are providing nearly similar events and have similar usage when creating forms or other pages. All this is true that both controls are nearly similar, but they have a vast difference that exists between them. The ASP .NET Server Controls are more rich in functionality as compared to their HTML Server Control counterparts. Let's take a look at some other differences that exist between these controls.
1. Control Abstraction:A HTML Server Control has similar abstraction with its corresponding HTML tag and offers no abstraction.ASP .NET Server Controls have higher level of abstraction. An output of an ASP .NET server control can be the result of many HTML tags that combine together to produce that control and its events.
2. Object Model:The HTML Server Controls follow the HTML-centric object model.ASP .NET Server Controls have an object model different from the traditional HTML and even provide a set of properties and methods that can change the outlook and behavior of the controls.
3. Browser Compatibility:The HTML Server Controls have no mechanism of identifying the capabilities of the client browser accessing the current page.ASP .NET Server Controls can however detect the target browser's capabilities and render themselves accordingly.
Despite the differences you can still use these controls together by mixing them in an ASPX form or page. These controls can also be used together in the build up of user controls that you can design according your requirements and needs. As far as the question which control to use when? is concerned, I would say that its up to you to decide that what you are comfortable with and what you can handle easily. If you want to convert your existing HTML based template pages to ASPX based pages then it would be better for you to convert the tagged HTML controls within them to HTML Server Controls as this would only require you to add the runat="server" attribute to them. If preparing new ASPX based template pages that you want to easily target browsers according to their capabilities, e.g. a page that can have the same view on a mobile phone as it has on the Internet Explorer, would require you to use the ASP .NET Server Controls.
I am listing some difference between these two types of controls, If you find any other point please add to this
1. Server Controls Trigger Server side events. Where as HTML controls only trigger client side events.
2. State ManagementServer Controls provides State Management - Data entered in a control is maintained across requests.State Management in HTML Controls can be achieved using Page-level scripts.
3. AdaptationServer controls automatically detects & adapts display appropriately.HTML Controls - No automatic detection is possible.
4. PropertiesServer controls - Provides a good set of properties that can be manipulated from server side code.HTML Controls - It has the basic set of HTML attributes attached to each element.
5.server control inherits from System.Web.UI.Webcontrols but html not
The confusion that I had, and I think some of you may also have, is that why provide two type of controls that almost provide similar functionality, i.e. that both the controls are executed on the server side , both the controls are providing nearly similar events and have similar usage when creating forms or other pages. All this is true that both controls are nearly similar, but they have a vast difference that exists between them. The ASP .NET Server Controls are more rich in functionality as compared to their HTML Server Control counterparts. Let's take a look at some other differences that exist between these controls.
1. Control Abstraction:A HTML Server Control has similar abstraction with its corresponding HTML tag and offers no abstraction.ASP .NET Server Controls have higher level of abstraction. An output of an ASP .NET server control can be the result of many HTML tags that combine together to produce that control and its events.
2. Object Model:The HTML Server Controls follow the HTML-centric object model.ASP .NET Server Controls have an object model different from the traditional HTML and even provide a set of properties and methods that can change the outlook and behavior of the controls.
3. Browser Compatibility:The HTML Server Controls have no mechanism of identifying the capabilities of the client browser accessing the current page.ASP .NET Server Controls can however detect the target browser's capabilities and render themselves accordingly.
Despite the differences you can still use these controls together by mixing them in an ASPX form or page. These controls can also be used together in the build up of user controls that you can design according your requirements and needs. As far as the question which control to use when? is concerned, I would say that its up to you to decide that what you are comfortable with and what you can handle easily. If you want to convert your existing HTML based template pages to ASPX based pages then it would be better for you to convert the tagged HTML controls within them to HTML Server Controls as this would only require you to add the runat="server" attribute to them. If preparing new ASPX based template pages that you want to easily target browsers according to their capabilities, e.g. a page that can have the same view on a mobile phone as it has on the Internet Explorer, would require you to use the ASP .NET Server Controls.
I am listing some difference between these two types of controls, If you find any other point please add to this
1. Server Controls Trigger Server side events. Where as HTML controls only trigger client side events.
2. State ManagementServer Controls provides State Management - Data entered in a control is maintained across requests.State Management in HTML Controls can be achieved using Page-level scripts.
3. AdaptationServer controls automatically detects & adapts display appropriately.HTML Controls - No automatic detection is possible.
4. PropertiesServer controls - Provides a good set of properties that can be manipulated from server side code.HTML Controls - It has the basic set of HTML attributes attached to each element.
5.server control inherits from System.Web.UI.Webcontrols but html not
Subscribe to:
Posts (Atom)