Хөгжүүлэгч буюу Хөтөлбөрлөгч

Нөхөр буюу Дайсан

Технологийн чиглэлийн компанийн гүйцэтгэх дарга болон жинхэнэ ёсоор туурвил хөгжүүлдэг хүмүүсийн хооронд үүсдэг соёлын зөрчлийн талаар нэгэн найзтайгаа би саяхан мэтгэлцээн өрнүүлсэн юм. Энэ нь анзаарахгүй орхиж үл болох таагүй уур амьсгалын эх сурвалж болоод зогсохгүй хий дэмий ажил үрэх, шаардлагагүйгээр цаг сунжруулах нэг гол шалтгаан болдог.

Ихэнхи тохиолдолд би иймэрхүү асуудлаас зайлсхийхийг чармайдаг. Хэрвээ компанийн шийдвэр гаргагчид туурвил хөгжүүлэлтийг надаас өөр өнцгөөр хардаг бол ийм компанид ажиллахгүй байх нь дээр гэж би үздэг. Ингэх олон шалтгаан бий. Нэгдүгээрт, төсөл бүтэлгүйтэн нурахыг би тэвчдэггүй, тэр тусмаа соёлын мөргөлдөөнөөс болж төсөл шатах магадлал өндөр. Хоёрдугаарт, соёлын эрс ялгаанаас улбаалан туурвил хөгжүүлэх үйл явцад юуг үр дүнтэй, амжилттай гэж үзэх талаар бөөн будилаан, эргэлзээ төрнө. Хэрэв хэн нэгэн этгээд миний сайн хийж буй зүйлийг үнэлэхгүй бол өөрийгөө үнэлүүлэх гэж зүтгэх нь ямар ч утга учиргүй зүйл болж хувирна.

Тэгэхлээр осолтой цэгүүдийг би хэрхэн олж тогтоодог вэ? Үгээр таних тэмдгүүдийн нэг бол шийдвэр гаргагчдын зүгээс туурвил хөгжүүлдэг хүмүүсийг "хөтөлбөрлөгчид" гэж нэрлэж байгаа эсэхээр тандах нэг арга байж болно. Тэдгээр гүйцэтгэх дарга нарын өсөж өндийсөн аварга системийн орчинд хариуцлагын маш тодорхой хилийн шугам төлөвшсөн байх агаад код бичдэг хүмүүс нь зөвхөн кодоо л бичнэ. Тооцоолуурын хөтөлбөр, өөрөөр хэлбэл код бичихэд бүх цагаа зарцуулдаг учраас тэднийг хөтөлбөрлөгчид гэж нэрлэх нь зүйн хэрэг.

Харин Майкрософт хамтлаг шал өөр соёлтой. Тэднийг Майкрософт Хөтөлбөрлөгчдийн Сүлжээ гэх биш, харин Майкрософт Хөгжүүлэгчдийн Сүлжээ гэж нэрлэдэг.

"Хөгжүүлэгчид" нь "хөтөлбөрлөгчдөөс" илүү өргөн хүрээтэй хариуцлага үүрнэ. Тодруулбал, хөгжүүлэгч болно гэдэг нь зөвхөн код бичихээс гадна туурвил хөгжүүлэх бусад олон асуудал дээр анхаарлаа хандуулна. Бэлдэцийн судалгаа хийх, сорилт бичих, шаардлагуудаа төвхнүүлэх гэх мэт - тухайн нөхцлөөс хамааран хэн нэгэн хөгжүүлэгч энэ бүхнийг бүгдийг нь юмуу заримыг нь хийж болно.

Үнэн чанартаа, тавьсан зорилгодоо хамгийн цөөн мөр бичих замаар хүрэх нь өнөөгийн туурвилын ертөнц дэхь чанар чансааны гол хэмжүүр болоод байна! Энэ нь уйгагүй эрэл хайгуул хийх, бодож тунгаах, зохиомжлох, зарим үед туршилт хийхийг шаардана. Тухайн даалгаврыг хийхийн тулд кодоо оргүй хоосноос шинээр эхлэхийн оронд хэн нэгний бичсэн бэлэн кодуудыг нэгтгэн зангидаж хийвэл гарах үр дүн нь хамаагүй найдвартай, хурдан байх билээ.

Хатуу төмөр дэвсгэртэй, нэг ёсондоо цехийн дамжлагаар хүмүүжсэн хүмүүс үүнийг барагтай бол ойлгохгүй. Тэдний бодлоор, туурвил хөгжүүлнэ гэдэг нь цэвэр механик үйл явц.

Нэгэн цагт, систем гэгч нь хангалттай энгийн хялбар байх үед механикаар ажиллах нь хэдий оновчтой зөв шийдэл байгаагүй боловч байж болох хувилбар байлаа. Харин одоо ийм үйл явц ёстой бүтэхгүй.

Амжилттай ажиллахын тулд, юмыг хэрхэн шийдэх талаар өргөн цар хүрээнд харах чадварыг хөгжүүлэгч хүн эзэмшсэн байх ёстой. Тухайн систем юу хийх талаархи ерөнхий ойлголтыг шийдвэр гаргагчид хянаж чаддаг байх ёстой гэдэг боловч өндөр хурдацтай өөрчлөгдөн буй технологийн хөгжил болон туурвил хөгжүүлэх үйлдвэрлэл дэхь арга техникийн хувьслын нөлөөгөөр хөгжүүлэлт хэрхэн хийгдэх ёстой талаар оновчтой шийдвэр гаргахад шийдвэр гаргагчдын ур чадвар яалт ч үгүй дутдаг. Тэд, тухайлбал, хөгжүүлэлтэнд туслах юмуу хурдасгахад ямархуу гуравдагч /third party/ технологи хэрэглэх нь илүү ашигтай вэ гэдэг талаар ухаалаг шийдвэр гаргаж чаддаггүй. Иймэрхүү болон өөр бусад олон асуудлууд дээр хөгжүүлэгч хүмүүс нь өөрсдийгөө шийдвэр гаргагчид хэмээн үздэг хүмүүсээс илт давуу шийдвэр гаргах чадвартай байдаг.

Үүнийг хүлээн зөвшөөрөх нь тэдэнд маш хэцүү. Үүний тулд ядруухан хөтөлбөрлөгчдөд хэзээ ч хүлээлгэж байгаагүй тийм их итгэл, хариуцлагыг хөгжүүлэгчдэд хүлээлгэх шаардлага гарна. Мэдээж хэрэг, өөрийн сул талыг хүлээн зөвшөөрнө гэдэг ямар ч хүний хувьд хүнд бэрх даваа.

Гэвч, хэрвээ үүнийгээ хүлээн зөвшөөрөхгүй бол тэд өөрсдийгөө хэд хэдэн төрлийн зовлонд унагана. Нэгдүгээрт, хөгжүүлэх үйл явц руу элс цацсанаараа, тэд асуудлыг илүү хүндрүүлж байна. Хоёрдугаарт, олонхи тохиолдолд, өөрчлөгдөн буй технологи болон үйлдвэрлэлийн хувьсан буй соёлтой авцалдахгүй бүрхэг ойлголт дээрээ тулгуурлан "яаж" гэдэг асуудал руу өнгийснөөрөө, тэд төсөл бүтэлгүйтэх эрсдлийг нэмэгдүүлж байна.

Шилдэг хүмүүсийг өөрийн байгууллагаасаа дайжихад хүргэж буйгаар тэд бас давхар хохирол амсана. Авъяаслаг хүмүүс хөгжүүлж буй системийнхээ талаар шийдэл гаргах боломжоо хумиулан зөвхөн механик эрэг шургийн үүрэг гүйцэтгэхийг тэсвэрлэж чаддаггүй. Энэ бол зөвхөн сэтгэлзүйн дарамт төдий үзэгдэл биш - энэ нь тухайн хүн цааш ахиж дэвжихэд нь бас хөнөөлтэй. Хэрвээ тэд хөгжүүлэлттэй холбоотой бүх төрлийн хариуцлага үүрэх явдлаас чөлөөлөгдвөл ирээдүйд гарах олон боломжууд тэдний өмнө хаагдана.

Техникийн Ахлах Ажилтан (ТАА) гэдэг ухагдахуун анх гарч моодонд орж байхад нь би үүнийг бүх талаараа дэмжиж байлаа. Учир нь ТАА нь технологийн асуудлыг шийдэх тал дээр байгууллагуудад үнэхээр тус дэм үзүүлнэ гэдэгт итгэж байв. Гэвч харамсалтай нь ТАА-тай нягт хамтран ажиллах явцдаа хийсэн хувийн дүнгэлтээс харахад тэд хөгжүүлэлтийг хурдасгах биш харин сааруулах хүчин зүйл болох нь элбэг байсныг дурдах хэрэгтэй. Эндээс ажигласан нэг зүйл гэвэл туурвил хөгжүүлэгч бид мэтийн хүмүүсийг тэдний өөрсдийнх нь хэлээр ердөө л "хөтөлбөрлөгч" гэж үздэг нь төслийг амжилтанд хүргэхэд томоохон саад бэрхшээл учруулдаг гол хүчин зүйл болж байгаа юм.

http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=239

Жич: Төсөл хугацаандаа амжин дуусаж чадах эсэх нь удирдлага, зохион байгуулалт буюу менежмент хэр сайн муу байхаас шалтгаална гэсэн үзэл санаа дэлхий дахинаа түгээмэл тархсан байдаг. Энэ нь туурвил /software/ хөгжүүлэх үйл явц бол цехийн шат дамжлагаар явагддаг цэвэр механик шинжтэй үйл ажиллагаа, энэ үйл ажиллагаанд тавих хөндлөнгийн хяналтыг сайжруулснаар амжилтанд хүрч болно гэсэн итгэл үнэмшил дээр суурилдаг. Хөндлөнгийн хяналтыг сайжруулах ажлын хүрээнд нэг өдөр, нэг долоо хоног, эсвэл нэг сарын хугацаанд бичигдэх кодын мөрийн тоонд хяналт тавих (гол төлөв хэдийчинээ олон мөр код бичнэ, төдийчинээ сайн гэж үзэх), түгээмэл гарах алдааны статистик бүртгэл хөтлөн мэдлэгийн сан бүрдүүлэх гэх мэт ажлууд ордог. Уг нь бол зөв санаа.

Гэвч өнөө цагт технологи маш эрчимтэй хөгжиж байна. Ялангуяа түгээмэл алдаануудаас зайлсхийх, цөөн мөрөөр их ажил амжуулах гэх мэтийн олон автомат хэрэгслэл, багажууд тоо томшгүй олон янзаараа борооны дараахь мөөг мэт үүсэн гарч байна. Ийм нөхцөлд ажлын бүтээмжийг мөрийн тоогоор үнэлэх ч юмуу эсвэл мэдлэгийн сан байгуулна гэх мэт зорилтууд ямар ч утгагүй, цаг барсан илүү ажил болон хувирч байна.

Тэр тусмаа өнөөдрийн гол асуудал нь мэдлэгийн сан байгуулах явдал биш, харин мэдлэгийн сан яаж байгуулахгүй байх ёстой вэ гэсэн эсрэг утга руугаа тэмүүлж байна. Бид хэдийчинээ өнгөрснөөсөө хурдан салж чадна, цаг үетэйгээ төдийчинээ хурдан зохицож чадна. Мэддэг зүйлээсээ хурдан татгалзаж салж чаддаг байх хэрэгтэй. Учир нь бидний мэддэг зүйл маань урагш хөгжихөд маань маш том саад учруулдаг. Шинэ технологи нь ямагт хуучнаасаа татгалзах, өмнөхөө үгүйсгэх замаар цааш хөгждгийг санацгаая.

Өнөөдөр сайн багаж, сайн технологи нь төслийн хувь заяанд шийдвэрлэх ач холбогдолтой болж байгаа гэдэгтэй миний бие санал бүрэн нийлдэг. Жишээ нь хүмүүсийн гаргадаг алдаа дэлхий даяар нийтлэг байдаг. Ийм алдаануудад дүн шинжилгээ хийгээд мэдлэгийн сан бүрдүүлсэн сайт ч олноороо байдаг. Бас шилдэг техникүүдийн мэдлэгийн сан, өөрийгөө сорих сорилтуудын сан (үүнийг туршиж үзвэл их зүгээр) гээд хүн бүрийн мэдэж байвал зохих хэрэгслэлүүд бий. Тийм болохоор бидний хувьд жишээ нь туршлагаа үлдээнэ, баримтжуулна гэдэг нь цаг үрсэн, илүүц ажил болж харагдаад байна.

Хэдэн жилийн дараа, эсвэл хэдэн сарын дараа кодоо дахин эргэж харахад тулах цэг хэрэгтэй, тэр тулах цэг нь кодын тайлбарууд, баримтууд, гарсан алдаанууд, түүнийг шийдсэн шийдлүүд гэх мэт олон зүйлийг хамарсан мэдлэгийн сан байна гэдэг. Буруу биш. Гэхдээ өнөөгийн software re-engineering tools хангалттай өндөр түвшинд кодонд дүн шинжилгээ, задаргаа хийн шаардлагатай бол кодыг автоматаар шинэчлэн бичиж бас чадна. Үүнд маш бага хугацаа орно. Энэ салбарт өнөөдөр AI буюу хиймэл оюун ухааныг өргөн ашиглаж байна. Ийм багажуудын үнэ ханш ч өдөр ирэх тусам бууж байгаа. Хэрвээ бид цаг үеийнхээ асуудалтай хэт их зууралдаж цаг алдвал, хэрвээ бид мэддэг зүйлээсээ хурдан татгалзаж чадахгүй бол шинэ үеийн технологиудад бут цохигдох магадлал өндөр бий гэдгийг дашрамд тэмдэглэх нь зүйтэй болов уу.

Асуудлыг бүрэн олж харахын тулд маш өргөн хүрээнд сэтгэх шаардлага бий. Энэ удаад үүгээр өндөрлөе. Дараа өөр олон асуудлуудыг хөндсөн блог тэмдэглэл олж орчуулах болов уу хэмээн найдъя.

Жишээ нь agile development tools-ын талаар хэзээ нэгэн цагт дурдах хэрэг гарах болов уу, энэ нь ерөнхийдөө туршилт + сорилт + continuity + integration маягийн багаж гэж төсөөлж байна. Зарчмын хувьд урьдчилан төлөвлөх, хяналт тавихаас аль болох татгалзах чиг хандлагатай, хувь хүний эрх, эрх чөлөө, хариуцлага маш өндөр байхыг шаардсан өөрөө өөрийгөө хянах тогтолцоо гэж ойлгож байна. Ойрын ирээдүй иймэрхүү дүр төрхтэй болох болов уу, тиймээс бид ч бас энэ чиг хандлага руу аажмаар дөхөх ёстой юм болов уу гэж бодож байна.

Алдаатай дайн зарлах биш, харин алдаатай ойртон нөхөрлөх аргачлалд суурилсан хөгжүүлэлтийг өөрөөр test driven development гэдэг. Өөгүй тогтолцоо хэзээ ч ажилладаггүй гэсэн инженерийн алтан дүрэм байдгийг энэ дашрамд дурдаад тэмдэглэлээ өндөрлөе.

Java EE 5 Хөрсний давуу талууд

Аль болох богино хугацаанд их ажлыг чанартай хийж гүйцэтгэхийг хүн бүхэн хүсдэг. Аливаа шинэ технологийн зорилго нь хүний хүчин зүйлийг аль болох багасгаж ач холбогдол багатай хэрнээ цаг хугацаа их шаарддаг "бохир" ажлуудыг автоматжуулах явдал байдаг. Бохир ажлууд олон бий. Багаж гэдэг зүгээр нэг хөдөлмөрийн зэвсэг төдий биш. Өнөө цагт энэ нь өөртөө бүхэл бүтэн гүн ухаан, шинэ сэтгэлгээ, шинэ хандлага, шинэ арга барил, шинэ урлагыг агуулдаг. Зөвхөн хүнийг хөгжүүлнэ гэсэн өрөөсгөл хандлагаар үйлдвэрлэлийн бүтээмжийн асуудалд хандах нь учир дутагдалтай, бас эрсдэлтэй. Нэгэн цогц шийдлийг агуулсан шинэ багаж, шинэ технологийн талаар хийсэн нэгэн ярилцлагыг та бүхэнд толилуулъя.

Java EE 5 Хөрсний давуу талууд: Мэргэшсэн Инженер Билл Шеннонтой хийсэн ярилцлага.

Жава Хөрс, Enterprise Edition 5 (Java EE буюу J2EE) хэрэглээнд гарлаа. Шинэ хувилбарын тасархай онцлог гэвэл шинэ бүтээгдэхүүнийг зах зээлд гаргах цагийг ихээхэн хэмнэхэд чиглэгдсэн илүү эвлэг, илүү хүчтэй, илүү цомхон шийдлүүд юм. Энэ юу болох талаар Sun Microsystems пүүсийн Мэргэшсэн Инженер Билл Шенноноос асууж тодруулсан юм.

А: Java EE 5 ашиглан хөдөлмөрөө хөнгөвчлөх ямар боломжууд нэмэгдсэн талаар тодруулахгүй юу?

Х: Хөгжүүлэгчдийн хөдөлмөрийг хөнгөвчлөх маш олон зүйл сэдсэн, гэхдээ яг юунаас эхлэхээ мэдэхгүй байна. Тоймолж хэлбэл таны ашиглах багаж чинь эрс сайжирсан гэх болов уу.

Юуны өмнө заавал байрлуулалт тодорхойлогч /deployment descriptor/ ашиглах шаардлагагүй болж байна. Хамгийн энгийн зүйл хийхэд, жишээ нь олон модуль нэгтгэн "ear" файл үүсгэхийн тулд тэдгээр модуль хаана байгаа жагсаалтыг байрлуулалт тодорхойлогч дотор бичих шаардлага гардаг. Одоо бол ингэх шаардлагагүй, ердөө л тохирох газар нь тохирох файлаа хийх хэрэгтэй, жишээ нь бүх нийтийн сангуудаа "lib" дотор хийнэ гэх мэт.

Хялбар жишээ авч үзье. Урьд нь вэб үйлчилгээ байгуулахын тулд тухайн вэб үйлчилгээгээ тодорхойлсон Жава үүд /interface/, мөн тухайн вэб үйлчилгээг хэрэгжүүлсэн Жава анги, контайнертаа зориулан тухайн үйлчилгээний талаархи мэдээллийг дүрсэлсэн байрлуулалт тодорхойлогч, хийгээд вэб үйлчилгээ ажиллуулагч орчиндоо /runtime/ зориулан вэб үйлдлүүд болон жава ангиудын хамаарлыг тусгасан тогтоцын /configuration/ файл зэргийг бичих шаардлага гардаг байсан. Хэрэглэгдэхүүн /application/ бүрийн хувьд эдгээр нь бараг өөрчлөгддөггүй ижилхэн давтагддаг зүйл байлаа. Жава ЕЕ 5 гарснаар тухайн вэб үйлчилгээг хэрэгжүүлсэн цорын ганц анги бичих замаар энэ бүхнийг хийх боломжтой болсон. Эх код дотор оруулсан товчлол /annotation/, эсвэл товчлолгүй үед яах ёстойг заасан заяамал дүрэм зэрэг дээр тулгуурлан үлдсэн бүх ажлыг контайнер өөрөө автоматаар хийнэ.

Хялбархан вэб үйлчилгээний кодыг бүрэн эхээр нь дор харууллаа:

package endpoint;

import javax.jws.WebService;

@WebService

public class Hello {

public String sayHello(String param) {

return "Hello " + param;

}

}

Хэмнэх хугацаа

А: Өмнөх хувилбартайгаа харьцуулахад Жава ЕЕ 5 ашигласнаар хөгжүүлэгчдийн enterprise хэрэглэгдэхүүн бичихэд зарцуулагдах хугацаа нь хэр зэрэг хэмнэгдэхийг барагцаалан хэлж болох уу?

Х: Мэдээж үүнийг хэмжих нь түвэгтэй, ямар төрлийн хэрэглэгдэхүүн бичиж буйгаас ихээхэн хамаарна. Харьцангуй хялбар хэрэглэгдэхүүний хувьд, хэрэглэгдэхүүнийг хөгжүүлэхэд зарцуулах хугацаа нь тухайн хэрэглэгдэхүүн дэхь кодын мөрийн тоотой шууд хамааралтай. Энэ тохиолдолд, мөрийн тоо бараг хоёр дахин цөөрсөн гэж болно. Мөн иймэрхүү хэрэглэгдэхүүн бичихийн тулд ойлгож мэдсэн байх шаардлагатай ухагдахуунуудын тоо цөөрсөн гэдгийг нэмэж тооцвол хэмнэлтийн хэмжээ бүр их гарна. Томоохон хэмжээний хэрэглэгдэхүүний хувьд гэвэл, хэрэглэгдэхүүний амин сүнс нь бизнесийн логик хэсэг байдаг, энд сүрхий ялгаа гарахгүй. Харин судлаж эзэмших ёстой ухагдахуунуудын тоо цөөрч тогтолцоо бүхэлдээ хялбарчлагдснаар ийм хэрэглэдэхүүн байгуулахад илүү амар хялбар болно. Та жинхэнэ ёсоор нь бүх анхаарлаа зөвхөн бизнесийн логик дээрээ төвлөрүүлэх боломжтой боллоо.

А: Жава ЕЕ 5 дахь товчлолын талаар арай дэлгэрэнгүй тайлбарлана уу?

Х: Жава ЕЕ нь enterprise хэрэглэгдэхүүн хөгжүүлэх олон асуудал дээр мэдэгдэл бичих /declarative/ хандлагыг ямагт түлхүү анхаарч ирсэн. Хөтөлбөрлөлийн иймэрхүү хэв маяг Жава хэлэнд байдаггүй тул мэдэгдлийн мэдээллийг хадгалахдаа байрлуулалт тодорхойлогч хэмээх тусдаа файл ашигласаар ирсэн. Товчлол бий болсноор иймэрхүү мэдээллийг байх ёстой газар нь болох эх код дотор бичих боломж нээгдсэн.

Тодруулбал, контайнераар ямар нэгэн зүйл хийлгэхийг хүсэхдээ заавал API дуудах, хажуугаар нь байрлуулалт тодорхойлогч хөтлөөд түүнийгээ бичиж буй кодтойгоо нягт уялдуулах гэх мэт олон шаардлага байхгүй болсон. Та контайнерын хүсэлтээ код дотроо шууд бичихэд л болно. Тухайлбал, "энэ анги бол веб үйлчилгээ мөн" гэх юмуу "энэ арга бол гүйлгээ мөн" гэх мэт.

Мэдээж хэрэг, эдгээр шинэ чадвар нэмэгдлээ гээд хуучин нь устаж мөхнө, хэрэгцээнээс гарна гэсэн үг биш. Үнэхээрийн шаардлагатай үе тохиолдох цагт байрлуулалт тодорхойлогч ашиглах нь зөв зүйтэй алхам болох болов уу.

А: Өд сөд нь ургаж гүйцээд Жава ЕЕ 5 руу орохоор ид шохоорхон буй 1000 авъяаслаг хөгжүүлэгчдийн өмнө үг хэлэх боломж гарвал та тэдэнд юу хэлэх вэ?

Х: Энэ бол аавын чинь мэддэг Жава ЕЕ огтхон ч биш!

J2EE бол дэндүү түвэгтэй хэмээн айн сүрдэж явсан хүмүүст хандан хэлэхэд одоо ингэж айх хэрэггүй болсныг уламжлая. Spring, Hibernate зэрэг өөр технологийг тахин шүтдэг хүмүүст хэлэхэд тэдгээр технологийн олон сайхан санаанууд Жава ЕЕ технологид нэвтэрсэн болохыг дуулгая.

Та Жава ЕЕ 5 технологийг сонирхон судлаад бүх зүйл хичнээн амар хялбар болсныг гайхан бишрэх болно.

Enterprise JavaBeans 3.0 болон the Java Persistence API

А: EJB 3.0-д EJB хөтөлбөрлөлийн загвар хэрхэн хялбаршсан талаар ярина уу. EJB 3.0 дотор Уламжлалт Жава Обьект /POJO - Plain Old Java Object/ ашиглан хөтөлбөрлөлийг яаж хялбаршуулах вэ?

Х: Юуны өмнө хэлэхэд, хүмүүсийн яриад буй "EJB 3.0" гэдэг зүйл нь хоёр тусдаа юмнаас бүрддэг. EJB хөтөлбөрлөлийн сонгодог загварыг асар их хөнгөвчилсөнд EJB 3.0-ийн мөн чанар оршино. Ялангуяа шинээр гаргасан Java Persistence API бол яах аргагүй гайхалтай ажил.

Java Persistence нь олон талаараа EJB CMP (Container Manager Persistence)-ийг орлоно, гэхдээ энэ нь CMP огт байхгүй болсон гэсэн үг биш. Java Persistence нь Жава обьектыг хүснэгтэн /relational/ өгөгдлийн сантай холбох илүү авсаархан чиг хандлага бөгөөд Hibernate, TopLink, болон JDO (Java Data Objects) зэрэг бусад бүтээгдэхүүн, технологиудад гарсан шинэ санаагаар ихэд баяжсан юм. Тэднээс суралцсан сургамжууд, түүнчлэн EJB CMP ашигласан олон жилийн туршлагаас Java Persistence үүссэн. Java Persistence нь EJB CMP -ээс эрс ялгаатай хэрнээ дурдагдсан бусад технологийг илүү их санагдуулах болно. Товчлол бүхий POJO дээр Java Persistence тулгуурлана. Жава ЕЕ-ийн бүрэлдэхүүн дотор, эсвэл Жава ЕЕ-ийн гаднахь Жава SE орчин дотор гэсэн хоёр янзаар Java Persistence-ийг ашиглаж болно.

Түүнчлэн бид EJB хөтөлбөрлөлийн загварыг онцгой хялбарчилж бас чадсан. EJB контайнерын гүйлгээ хийх чадварыг бүрэн ашигласан төлөвтэй болон төлөвгүй компонентуудыг бичихэд маш хялбархан болсон. Тухайлбал ердөө л @Stateless товчлол бүхий POJO ашиглан EJB компонент бичиж болно. Заяамал тохиргоо ёсоор, тухайн компонентын бүх ил аргуудыг үйлчлүүлэгчээс дуудах боломжтой бөгөөд тэдгээр арга нь гүйлгээ дотор ажиллана. Гүйлгээний шаардлагууд болон аргуудын аюулгүй байдлын шаардлагыг удирдах зориулалттай өөр нэмэлт товчлолуудыг ч бас хэрэглэх боломж бий.

JavaServer Faces болон Вэб Хэрэглэгдэхүүний Зохиомж

А: JavaServer Faces (JSF) технологи нэмэгдснээр вэб хэрэглэгдэхүүний зохиомж хэр зэрэг эвлэг болсон бэ?

Х: JSF нь вэб хэрэглэгдэхүүн бичихийг хялбарчлах болон их хэмжээний код бичих ажлаас чөлөөлөх гэсэн хоёр чиглэлээр вэб хэрэглэгдэхүүн хөгжүүлэлтийг илүү эвтэйхэн болгож байгаа.

JSF рүү чиглэсэн гуравдагч /third-party/ компонентийн зах зээл хангалттай хөгжөөд байгаа нь өндөр чанартай, арилжааны бэлэн компонентуудыг өөрийн хэрэглэгдэхүүн дотроо ашиглах өргөн боломжийг хөгжүүлэгчдийн өмнө нээн өгч байна. JSF бол IBM, Oracle, BEA, JBoss, болон Borland зэрэг томоохон үйлдвэрлэгчдээс өргөн дэмжлэг авсан Java Community Process (JCP) стандарт юм. Өөрөөр хэлбэл, зах зээл нь сайтар төлөвшсөн гэдэг утгаараа JSF рүү оруулсан таны хөрөнгө оруулалтын үр өгөөж ямагт өндөр байх болно.

JSF-ийн арга барилын хувьд эвлэг байдал нь өмнөх технологитой харьцуулахад хийсвэрлэлийн илүү өндөр түвшинд хэрэглэгчийн үүдээ /user interface/ зохиох боломжийг хуудас зохион бүтээгчдэд олгодог түүний компонент загвар дээр тулгуурладаг. JSF нь вэб хэрэглэгдэхүүн бүтээхэд төрөл бүрийн багажууд ашиглах боломжтой Swing маягийн үзэгдлийн загвар ашигладаг давуу талтай.

GlassFish-ийн ач холбогдол

А: GlassFish болон нээлттэй кодчлолын хамтлагийн гол ач холбогдол юу вэ? Нээлттэй кодчлолын хамтлаг Жава ЕЕ 5-ын талаар юу ойлгох ёстой вэ?

Х: GlassFish хамтлаг нь Жава ЕЕ 5-ийг бүхэлд нь хэрэгжүүлсэн үнэгүй, нээлтэй кодчлол бүхий хэрэглэгдэхүүн үйлчлэгч /application server/ бүтээж байна. Энэ хамтлаг дотор Sun болон Sun-бус оролцогчдын аль аль нь бий. Тухайлбал, GlassFish доторхи Java Persistence хэрэгжүүлэлт /implementation/ бол Oracle-ийн оруулсан хувь нэмэр юм. GlassFish бол үнэхээрийн хамтач үйл ажиллагааны илрэл мөн. Жава ЕЕ зүйлчлэлийн /spec/ туршилтын хэрэгжүүлэлтийг /reference implementation/ бүтээхэд туслахыг хүссэн хүн бүхний өмнө GlassFish хамтлагын үүд үргэлж нээлттэй.

GlassFish бол үнэгүй, бас код нь нээлттэй. Давтан хэлье: GlassFish үнэгүй, код нь нээлттэй. GlassFish нь OSI-итгэмжит CDDL лиценз ашигладаг.

А: Жава ЕЕ-ийн ирээдүйн хөгжилд хөгжүүлэгчид хувь нэмрээ яаж оруулж болох вэ?

Х: Жава ЕЕ-ийн ирээдүйн хөгжилд хувь нэмэр оруулах олон арга зам бий. Магадгүй хамгийн зөв хандлага бол Жава ЕЕ төв хуудас руу орж, хичээл уншиж, SDK татан авч ажиллуулж үзээд санал сэтгэгдлээ хуваалцах явдал байх болов уу.

"Энэ бүхэн яаж ажиллаад байна" гэдгийг ойлгохыг сонирхсон хөгжүүлэгч бүхэн GlassFish -ийг нарийвчлан ухаж төнхөхийг хүсэх нь лавтай.

Хөгжүүлэгчдэд зориулсан ашигтай санамж, зөвлөмж, болон жишээ хөтөлбөрүүд GlassFish вэб буудал /site/ дээр бий. GlassFish төсөлд бодит хувь нэмэр хэрхэн оруулах тухай зааварчилгаа бас тэнд бий.

Эцэст нь, Жава ЕЕ зүйлчлэлийн ирээдүйн хөгжилд шууд оролцохыг хүссэн хөгжүүлэгчид нь JCP гишүүнээр элсэн ноорог зүйлчлэлийг /draft spec/ нягтлан шалгаж, зүйлчлэл боловсруулах ирээдүйн багт оролцох талаар одооноос анхаарах шаардлагатай.

А: Жава ЕЕ 5-ийн талаар мэдэх ёстой хамгийн чухал зүйлийг ганц үгээр тодорхойл гэвэл юу гэхсэн бол?

Ердөө л ганцхан зүйлийг нэрлэнэ гэвэл маш хэцүү. Жава ЕЕ 5-ийг бүхэлд нь хамран хөтөлбөрлөлийн загварыг хөнгөвчилсөн гол түлхүүр бол товчлол мөн гэдэг нь эргэлзээгүй. Persistence, вэб үйлчилгээ, гүйлгээ, аюулгүй байдал болон Жава ЕЕ-ийн бусад хүчирхэг чадваруудыг хөнгөвчлөхдөө бид товчлолыг ашиглаж байна. Бидний тооцож байгаагаар, хэрэглэгдэхүүн хөгжүүлэх товчлолын хандлагыг хөгжүүлэгчид хурдан ойлгож нэвтрүүлэн улмаар Жава ЕЕ 5-ийн боловсронгуй persistence болон вэб үйлчилгээний чадварууд руу нэвтрэн орох болов уу.

Бүтээгдэхүүний архитектур туурвилын нүдээр

Би саяхан компаныхаа бүтээгдэхүүний зохиомжийг нэгтэн төлөвшүүлэх "бүтээгдэхүүний налархай /holistic/ архитектур" бүтээхээр Enterprise Архитектур багтай ажилласан юм. Бид ажлаа эхлэхдээ "бүтээгдэхүүний архитектур" гэж яг юу вэ гэдгийг сайн мэдэхгүй байсан тул миний бие Google ашиглан хайлт хийгээд доорхи тодорхойлолтыг олсон юм:

Архитектурын тодорхойлолт хоёр хэсэгтэй:

• Архитектурын эхний хэсэг нь бүтээгдэхүүнийхээ юу хийж чадах бүдүүн тойм чадваруудаа сайтар тодорхойлогдсон эрдмүүд /function/ болгон нарийвчлан задлаад тэдгээр эрдмүүдийг биежүүлэх үүрэгтэй бүтээгдэхүүний бэлдмэл хэсгүүдээ эцэслэн тогтоох явдал байна.

• Тодорхойлолтын хоёрдахь хэсэг нь бэлдмэл /component/ хоорондох үүдийн /interface/ зүйлчлэл /spec/ байна, өөрөөр хэлбэл, бүтээгдэхүүн дотроо бэлдмэлүүд өөр хоорондоо хэрхэн цогц байдлаар харьцаж ажиллах вэ гэсэн үг.

Бусад бэлдмэлдээ нөлөөлөхгүйгээр бүтээгдэхүүн дотроо байгаа нэг бэлдмэлийг өөр төстэй бэлдмэлээр орлуулан солих бололцоо олгохуйц уян хатан архитектур зохиомжлон гаргахад үүдийн зүйлчлэл онцгой үүрэгтэй.

- Ron Sanchez : IMD их сургуулийн Стратеги, технологийн удирдахуйн ухааны профессор

Рон цааш нь дүгнэхдээ бүтээгдэхүүний архитектур гэдэг нь ганц нэг бүтээгдэхүүн бүтээнэ гэхээсээ илүү бүтээгдэхүүний бүхэл бүтэн бүл үүсгэх боломжтой бүтээгдэхүүний хөрс суурь бүтээх тухай ойлголт мөн гэжээ. "Бүтээгдэхүүний архитектурын" ийм тодорхойлолт надад таалагдаж байна, гэхдээ "бүдүүн тойм чадваруудыг нарийвчлан задлана" гэж юу болохыг тодруулах шаардлага байгаа болов уу гэж бодож байна.

Бүтээгдэхүүний архитектур нь бизнесийн болон техникийн шинжтэй асуудлуудын хоорондох хил заагийг ялгаж салгадаг, гэхдээ энэ нь бизнес эзэмшигчийн (гол төлөв Бүтээгдэхүүн Эрхлэгч) хийх ажил. Тодорхой бизнесээр дагнан эрдэмжсэн бэлдмэл /functional component/ нь бизнесийн шинэ чадварыг /шинэ бүтээгдэхүүн/ угсран гаргах боломжтой бэлдэц байдаг.

Бизнесээ ингэж төсөөлөн алдарт Model-View-Controller (MVC) гэдэг туурвилын /software/ архитектурыг авч үзье: MVC нь бүтээгдэхүүний архитектурын суурь болж чадах уу?

MVC бол хэрэглэгдэхүүний өгөгдлийн загвар, хэрэглэгчийн үүд болон удирдлагын логик гурвыг нэгнийх нь өөрчлөлт нөгөөдөө хамгийн багаар нөлөөлдөг байх ялгаатай бэлдцүүд болгон тусгаарласан модулар архитектур билээ. MVC нь туурвилын архитекторч хэн бүхний зайлшгүй эзэмших ёстой маш сайн архитектур мөн үү гэвэл мөн ... гэхдээ бүтээгдэхүүний архитектурын зүй ёсны суурь болоход нь тулгарах нэг ноцтой саад байна: MVC-д бэлдмэлийн задаргаа хийх үндэс нь бизнесийн эрдэм, чадвар биш.

Үүний нөгөө талд, Service Oriented Architecture (SOA)-д бэлдмэлийн задаргаа хийхдээ бизнесийн эрдэм чадварыг задаргааны нэгж болгон авдаг. SOA бол хэрэглэгдэхүүн бүтээхдээ бизнес чиглэлийн ялгаатай үйлчилгээнүүдийг нэгтгэн холбодог модулар архитектур (тиймээс нийлмэл хэрэглэгдэхүүн гэдэг) юм.

Үүнийг арай дэлгэрүүлэн тайлбарлахыг оролдъё. SOA өөрөө MVC-ээс илүү гарах бүтээгдэхүүний архитектур биш, гэхдээ нэгэн бүл бүтээгдэхүүний архитектурын загварыг хэрхэн дүрслэх тал дээр SOA бол сайн багаж.

Ихэнхи туурвил бүтээгдэхүүнүүд нь бизнесийн үйл явцыг автоматжуулдаг. Тухайн бүтээгдэхүүний архитектур нь уг бизнесийн үйл явцыг хэрэгжүүлэхэд шаардагдах араг ясыг /framework/ босгодог. Хэрвээ тодорхой үйл явцын алхамууд болон тэдгээр алхамуудыг хэрэгжүүлсэн бизнесийн бэлдмэл хоорондын холбоо ойлгомжтой байх аваас бизнес эзэмшигч нь архитектураа сайн ойлгож /бас саналаа нэмэрлэж/ болох талтай.

Тэгэхлээр "бүдүүн тойм чадваруудыг нарийвчлан задлана" гэж юу болохыг дахин авч үзье... Үүнийгээ ингэж дэлгэрүүлэе: бүдүүн тойм чадваруудыг бизнес-чиглэлийн ялгаатай эрдмүүд болгон нарийвчлан задлана...

Хэрэв та бизнес-чиглэлийн эрдмүүдийг зөв тодорхойлохоос ажлаа эхлэх аваас эцсийн бүтээгдэхүүн чинь арчлахад амар хялбар, ирээдүйд гарах өөрчлөлтөд дасан зохицох чадвар сайтай байх болно гэдэг нь эргэлзээгүй.

Бизнес-чиглэлийн гэдэг нэр томъёо зохиогүй гэдгийг би мэдэж байна.. гэхдээ энэ бүхнийг хөөн хэлцэх цорын ганц зам бол бизнес эзэмшигчтэйгээ ярилцах явдал мөн билээ. Яриагаа өрнүүлцгээе.

SUN пүүсийн инженер John Reynold-ийн блог тэмдэглэлээс авав.