Theory
Apps જ્યારે apps સાથે વાત કરે
અત્યાર સુધી બધું તમારા server અને માણસના browser વચ્ચેની વાત હતું. પણ ક્યારેક એક program ને બીજા program સાથે વાત કરવી પડે છે. ધારો કે કૉલેજની mobile app ને FestConnect ની events ની list જોઈએ છે, કે કોઈ ભાગીદાર site ને એ બતાવવી છે. એમને HTML નું page નથી જોઈતું; એમને કાચો data જોઈએ છે, જેને એ પોતાની રીતે વાપરી શકે.
Web service એ જ કામ માટે છે: એ એક application ને વેબ પર બીજી application બોલાવવા દે છે અને યંત્રથી યંત્ર સુધી ઘાટબદ્ધ data ની આપલે કરાવે છે. આ સમાપન કરતો ટેકનિકલ વિષય એની મૂળભૂત વાતો અને એની સાથે આપલે કઈ રીતે થાય તે આવરી લે છે.
Theory
Web service એટલે શું
Web service પોતાની કામગીરી વેબ પર એવી રીતે ખુલ્લી કરે છે કે બીજા programs (browser સામે બેઠેલા માણસો નહીં) એને વાપરી શકે. Web page પાછું આપવાને બદલે એ એવો ઘાટબદ્ધ data પાછો આપે છે જેને બોલાવનાર program પ્રક્રિયામાં લઈ શકે.
પરંપરાગત રીતે બોલાવનાર અને service HTTP પર SOAP નામના protocol થી XML સંદેશા આપલે કરે છે. Service એક કરાર પ્રગટ કરે છે, એટલે કે WSDL દસ્તાવેજ, જે બરાબર વર્ણવે છે કે એ કઈ ક્રિયાઓ આપે છે અને એ કયો data લે તથા પાછો આપે છે, જેથી બોલાવનારને એની સાથે વાત કરવાની રીત ખબર પડે. એનું ઓળખાણ આપતું લક્ષણ: એ ભાષાથી સ્વતંત્ર છે. .NET માં લખાયેલી web service ને Java, PHP કે બીજા કોઈ પણ program માંથી બોલાવી શકાય છે.
Formula
મુદ્દો interoperability નો છે
XML અને SOAP ના સંદેશા તથા WSDL ના કરાર પર પ્રમાણ કેમ બાંધવું? જેથી કોઈ પણ platform એ service ને બોલાવી શકે. .NET માં લખાયેલી FestConnect ની events service ને Java વાળી Android app, PHP વાળી website, કે બીજી .NET app પણ વાપરી શકે છે, કારણ કે એ બધાં HTTP પરના એક જ સંદેશા-ઘાટ પર સંમત છે.
આ platform ને ઓળંગતા સહકારને interoperability કહે છે, અને web services અસ્તિત્વમાં હોવાનું આખું કારણ એ જ છે: એવી વહેંચાયેલી કામગીરી જેને બોલાવનાર કઈ ભાષા બોલે છે એની પરવા નથી.
Theory
એને બનાવવી અને વાપરવી
પરંપરાગત ASP.NET માં તમે web service ને .asmx file તરીકે બનાવો છો: એટલે કે એવો class જેની બોલાવી શકાય એવી methods પર [WebMethod] લક્ષણ લગાડેલું હોય. ફક્ત એ લક્ષણ વાળી methods જ બોલાવનારાઓ સામે ખુલ્લી થાય છે.
Web service ને વાપરવા (બોલાવવા) માટે client program એનો reference ઉમેરે છે. ઓજારો service નું WSDL વાંચે છે અને proxy બનાવે છે: એટલે કે એ જ methods વાળું સ્થાનિક બદલી object. પછી client એ methods ને જાણે એ સ્થાનિક હોય એમ બોલાવે છે, અને પડદા પાછળ proxy request મોકલવાનું તથા response મેળવવાનું સંભાળે છે. છેવટે દૂરની service સાથે આપલે કરવી એ સામાન્ય method બોલાવવા જેવું જ લાગે છે.
Practical
FestConnect ની નાનકડી web service, અને એને બોલાવવી
// CREATE: expose a method other programs can call (in an .asmx service)
public class EventsService : System.Web.Services.WebService
{
[WebMethod] // this attribute makes it callable
public string[] GetEventNames()
{
return new[] { "Robotics Workshop", "Coding Contest", "Music Night" };
}
}
// CONSUME: after adding a reference, a client calls it like a local method
// var svc = new EventsService();
// string[] names = svc.GetEventNames(); // proxy handles the web callQuiz
Web service નો ઓળખાણ આપતો હેતુ શું છે?
- માણસ મુલાકાતીઓને સરસ શણગારેલાં HTML pages બતાવવાનો
- બીજા programs ને એને વેબ પર બોલાવવા દેવાનો અને એમની ભાષા કે platform ને ધ્યાનમાં લીધા વગર ઘાટબદ્ધ data ની આપલે કરવાનો
- Application માટે connection string સંઘરવાનો
- Database ને XML file થી બદલી નાખવાનો
Show the answer
બીજા programs ને એને વેબ પર બોલાવવા દેવાનો અને એમની ભાષા કે platform ને ધ્યાનમાં લીધા વગર ઘાટબદ્ધ data ની આપલે કરવાનો
Web service પોતાની કામગીરી વેબ પર બીજા programs વાપરી શકે એ રીતે ખુલ્લી કરે છે અને ભાષાથી સ્વતંત્ર રીતે ઘાટબદ્ધ data (પરંપરાગત રીતે XML અને SOAP) ની આપલે કરે છે, એટલે .NET ની service ને Java, PHP કે કોઈ પણ platform બોલાવી શકે. વિકલ્પ A માણસો માટેનાં સામાન્ય web pages નું વર્ણન છે; web service programs ને સેવા આપે છે, browsers ને નહીં, અને એ data પાછો આપે છે, શણગારેલું HTML નહીં. વિકલ્પ C એને web.config સાથે ગૂંચવે છે, જે settings રાખે છે. વિકલ્પ D ખોટો છે: web service કોઈ data નો ભંડાર નથી અને database ને બદલી નાખતી નથી; એ તો બીજી applications બોલાવે એવું આંતરમુખ છે. મુખ્ય વિચાર ભાષાઓ અને platforms ને ઓળંગતી યંત્રથી યંત્ર સુધીની interoperability નો છે.
Think first
Database સીધું વહેંચવાને બદલે web service શા માટે ખુલ્લી કરવી?
ભાગીદાર app ને FestConnect ના events જોઈતા હોય, તો એને database ની સીધી પહોંચ કેમ ન આપી દેવી? વિચારીને પછી tap કરો.
Show the answer
કારણ કે web service તમને કાબૂમાં રહેતું, સ્થિર અને સલામત આંતરમુખ આપે છે, જ્યારે database ની સીધી પહોંચ ઘણું બધું આપી દે છે. તમે ભાગીદારને તમારા database ની ઓળખાણ સોંપી દો, તો એ તમારું આખું schema જુએ, જે data વહેંચવાનો તમારો ઇરાદો જ નહોતો એ વાંચી કે બદલી પણ શકે, અને તમે કોઈ table નું નામ બદલો એ ક્ષણે એમની app તૂટી પડે. Web service ફક્ત તમે પસંદ કરેલી ચોક્કસ ક્રિયાઓ જ ખુલ્લી કરે છે, જેમ કે GetEventNames, અને બીજું કશું નહીં; બોલાવનાર તમારાં tables ને કદી અડતું નથી, તમારું અંદરનું માળખું જોતું નથી, કે તમારો database નો password રાખતું નથી. Service ની પાછળ તમે validation, સલામતી અને નિયમો ઉમેરી શકો છો, અને જ્યાં સુધી service નો કરાર (એનું WSDL) એ જ રહે ત્યાં સુધી તમે તમારું database છૂટથી ફરી ગોઠવી શકો છો. વળી એ ભાષાથી સ્વતંત્ર પણ છે, એટલે કોઈ પણ platform એને બોલાવી શકે, જ્યારે કાચું database connection બોલાવનારને ચોક્કસ drivers અને ઓળખાણ સાથે બાંધી દે છે. ટૂંકમાં, web service એ ઇરાદાપૂર્વકનો મુખ્ય દરવાજો છે: આખી ઇમારતની ચાવીઓ સોંપી દેવાને બદલે એ બરાબર તમે ઇચ્છો એટલું જ, સલામત અને સ્થિર રીતે વહેંચે છે. આંતરમુખ ખુલ્લું કરો, તમારું અંદરનું નહીં.
Summary
Key takeaways
- Web service એક application ને વેબ પર બીજી application બોલાવવા દે છે, યંત્રથી યંત્ર સુધી, browser ને pages આપવાને બદલે.
- એ પોતાની કામગીરી બીજા programs સામે ખુલ્લી કરે છે અને ઘાટબદ્ધ data પાછો આપે છે, પરંપરાગત રીતે HTTP પર SOAP દ્વારા XML સંદેશા.
- WSDL દસ્તાવેજ એ service નો કરાર છે, જે એની ક્રિયાઓ અને એમનો data વર્ણવે છે જેથી બોલાવનારને એની વપરાશની રીત ખબર પડે.
- Web services ભાષાથી સ્વતંત્ર છે: .NET ની service ને Java, PHP કે બીજા કશામાંથી બોલાવી શકાય, અને એથી interoperability શક્ય બને છે.
- પરંપરાગત ASP.NET માં તમે service ને .asmx file તરીકે બનાવો છો જેમાં methods પર [WebMethod] લગાડેલું હોય; ફક્ત એ જ બોલાવી શકાય છે.
- Client reference ઉમેરીને service વાપરે છે; બનેલું proxy એને દૂરની methods સ્થાનિક methods ની જેમ બોલાવવા દે છે.
- યાદ રાખવાની કડી: web service એ programs માટેનો સલામત મુખ્ય દરવાજો છે, જે કોઈ પણ ભાષા સાથે data વહેંચે છે.