Archive for the ‘general information’ category

Service-Oriented Architecture and Enterprise Architecture Part1

September 7th, 2010

PS. อ้างอิงและสรุปจาก Link นี้ครับ —> http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise1/index.html

ซึ่ง Article ในชุดนี้มี 3 ตอนครับ และผู้แปลไม่ได้ใส่ความเห็นลงไปใน Article นี้เลย

Part1: A framework for understanding how SOA and Enterprise Architecture work together

แนวคิด SOA และ EA นั้นเป็นแนวคิดที่มีการมองระบบไอทีในภาพรวมเหมือนกัน แต่แตกต่างกันที่มุมมอง

ซึ่งบทความนี้พยายามแสดง เปรียบเทียบ ชี้นำปัญหาและเสนอแนวทางการแก้ปัญหา ในการประยุกต์ใช้ร่วมกันของ 2แนวคิดนนี้

โดยประเด็นหลักๆที่เกิดขึ้นในการประยุกต์ใช้ 2แนวคิดนี้ร่วมกันก็อย่างเช่น

- ขอบเขตของ EA และ SOA และจุดที่ทับซ้อนกัน

- ความสัมพันธ์ระหว่าง SOA Center of Excellent (CoE) และ EA governance boards

- ความรับผิดชอบและผู้ดูแลของ SOA Infrastructure เช่น ESB นั้นควรจัดอยู่ในส่วนไหนของ Enterprise Infrastructure และมันควรใช้เฉพาะ SOA หรือไม่

ก่อนจะกล่าวถึงความเหมือนและแตกต่างของ 2แนวคิดนี้นั้น ขอเริ่มด้วยการอธิบายนิยามและมุมมองของ 2แนวคิดนี้ก่อนครับ

» Read more: Service-Oriented Architecture and Enterprise Architecture Part1

Introduction to Master Data Management

July 14th, 2010

ที่มาของเอกสารนี้มาจาก http://www.dataflux.com ผมอ่านและสรุป ตัดออกบ้าง
เกริ่นก่อ

ในโลกยุคปัจจุบันที่เป็นยุคแห่งการแข่งขันเรื่องข้อมูลข่าวสาร การแลกเปลี่ยนข้อมูลข่าวสารระหว่าง แผนก,องค์กร เป็นเรื่องที่เกิดขึ้นกันเป็นปกติเนื่องจากยิ่งมีการเชื่อมต่อระหว่างพันธมิตรมีมากเท่าไหร่ก็ทำให้เรามีความได้เปรียบทางการ แข่งขันมากขึ้นเท่านั้น แต่อย่างไรก็ตาม เราพบว่ายิ่งเราพยายามแบ่งปันข้อมูลมากขึ้นและการแยกการประมวลผลข้อมูลของแต่ละกลุ่มของ ธุรกิจให้อิสระต่อกันให้มากขึ้น สองสิ่งนี้นำเราไปสู่การสร้างกลุ่มของการประมวลผลที่ผูกติดแน่นต่อกัน โดยที่แต่ละกลุ่มจะมีข้อมูลบางชุดที่ใช้งานเหมือนๆกันโดยที่แต่ละกลุ่มเองก็จะมีโครงสร้าง definition,dictionary ที่เป็นของตัวเองโดยอิงกับความต้องการทางธุรกิจของตัวเอง
ผลสืบเนื่องต่อมาอีกคือในองค์กรขนาดใหญ่เราจะพบว่าจะมีการเก็บข้อมูลที่ดูเหมือนว่าจะเป็นข้อมูลของสิ่งๆเดียวกันในหลายๆที่ โดยที่แต่ละที่จะมีองค์ประกอบของข้อมูลที่แตกต่างกันเล็กน้อย และมีซ้ำกันทั้งใน Operational และ Analytical process และตอบไม่ได้ว่าถ้าเราต้องการข้อมูลที่ถูกต้องที่สุดเราต้องไปหยิบจากระบบไหน
ดังนั้นเพื่อเป็นการแก้ปัญหานีองค์กรเหล่านั้นจะต้องหาวิธีที่จะนำมาใช้สำหรับ การแยกแยะข้อมูล อธิบายมุมมองของการใช้งานข้อมูลในกลุ่มธุรกิจต่างๆ รวมไปถึงการควบรวมข้อมูลเหล่านั้นเพื่อให้ข้อมูลเหล่านั้นสามารถถูกนำกลับไปใช้งานโดยหน่วยงานต่างๆได้เหมือนเดิม ซึ่งจะส่งผลให้องค์กรมีความสามารถในการ จัดการและบริหารข้อมูลได้อย่างมีประสิทธิภาพมากขึ้น
อย่างไรก็ตามหลังจากโลกไอทีของเราย้ายฝั่งไปที่ฝั่ง Distributed ระยะหนึ่งตอนนี้มันกำลังย้ายกลับมาที่ฝั่งของ Centralized เราเริ่มเห็นแนวโน้มแล้วจากระบบที่เป็นหัวใจสำคัญเช่น Data Warehouse ที่มีการปล่อยให้ข้อมูลเกือบทั้งหมดขององค์กรไหลเข้าสู่ระบบ DW และทำการ Transform และ Cleansing เพื่อนำไปทำการออก Analytical Report แต่อย่างไรก็ตามกระบวนการ Transform และ Cleansing นั้นส่งผลกระทบให้ข้อมูลที่นำไปใช้ออก Report ไม่สอดคล้องกับข้อมูลต้นทาง นี่จึงเป็นอีกเหตุผลที่ส่งเสริมให้องค์กรควรจะสร้างสิ่งที่เรียกว่า Single Source of Truth สำหรับข้อมูลบางกลุ่มขึ้นมาสำหรับทุกๆส่วนขององค์กร ไม่ใช่เพียงเพื่อทำ Analytical Report เท่านั้นและนี่เองเป็นจุดเริ่มต้นของการทำ Master Data Mangement
เพื่อให้เห็นภาพมากขึ้นเราจะดูตัวอย่างเพื่อให้เห็นภาพมากขึ้นเช่นเราลองนึกภาพถึงเรื่องของ customers เรามักจะพบเสมอว่าจะมีการใช้งาน customers กระจายไปใน domain ต่างๆของธุรกิจไม่ว่าจะเป็น Sales, Finance, Customer Services โดยที่คำว่า Customers ในแต่ละ Domain จะมีลักษณะการมองและรายละเอียดที่แตกต่างกันบ้าง นอกจากนี้ customers ในบางกรณีก็ไปเกี่ยวเนื่องกับมุมอื่นอีกเช่นบางครั้งอาจจะไปเป็น Vendors, Suppliers ดังนั้นจากความแตกต่างที่กล่าวขึ้นมา ทำให้เกิดข้อแม้สองข้อในการทำงานคือ หนึ่งเราจะรู้ได้อย่างไรว่าการทำงาน ของเราจะไม่เกิดความผิดพลาด จากกรณีที่มีความแตกต่างของข้อมูลของ Customers ในจุดต่างๆและข้อมูลต่างๆเหล่า นั้นจะถูกต้องหรือไม่เมื่อเรานำมันไปประมวลผลเพื่ออก Report
ดังนั้นในเมื่อการบันทึกธุรกรรมต่างๆนั้นถูกกระทำไปโดยมองจากมุมของธุรกิจที่แตกต่างกัน ดังนั้นเพื่อแก้ไขปัญหาเรา สามารถสรุปทางออกได้สองข้อ
1 ทำการ intergrate ข้อมูลชุดต่างๆที่ใช้ร่วมกันเข้ามาให้เหลือเพียงจุดเดียว (หรือเสมือนจุดเดียว)
2 ทำให้ application ต่างๆมองเห็นข้อมูลในมุมมองเดียวกันทั้งระบบ
ต่อไปเราจะมาดูกันว่าคำว่า “Master Data” ทีแท้แล้วคืออะไรถ้าให้อธิบายแบบง่ายที่สุด Master Data คือชุดของข้อมูลที่ถูกใช้งานข้ามระบบในองค์กรเช่น Customer, Product, Service, Part, Suppliers, Location ยกตัวอย่างเช่นถ้าหนึ่ง Transaction ที่เกิดขึ้นในระบบสามารถเขียนได้เป็นคำพูดดังนี้ “David Loshin purchased seat 15B on US Airways flight 238 from Baltimore(BWI) to San Francisco(SFO) on July 20, 2010” เราอาจจะแยกเอา Master Data ออกมาได้หลายตัวจาก Transaction นี้เช่น
Customer: David Loshin
Product: seat 15B
Flight: 239
Location: BWI
Location: SFO

ถ้าเราหยิบแค่ Customer มาดูในระบบเราอาจะมี David Loshin ในหลายๆที่และหลายมุมมองด้วยเช่น

แล้ว Master Data Management คืออะไร
MDM คือส่วนประกอบของ Business Application, Methods และ Tools สามสิ่งนี้ทำให้เกิด Policies, Procedures และ Infrastructures เพื่อทำให้เกิดการรวมศูนย์ข้อมูลในองค์กรและทุกๆส่วนขององค์กรสามารถเข้าถึงข้อมูลที่ถูกต้อง มีความเที่ยงตรง มีขนาดกระทัดรัดได้เหมือนกัน

ดังนั้นเราจะมอง MDM ไม่ใช่เป็นแค่เทคโนโลยีเพียงอย่างเดียวมันคือกระบวนการที่ประกอบไปด้วยขั้นตอนหลักๆดังนี้
ประเมินและสำรวจการใช้งาน Core Information Object, Data Value Domain และ Business Rules ของ Application ที่สำคัญๆ(ก่อน) ของทั้งองค์กร

  • ทำการระบุ Master Data โดยการเลือกเอา Business Process ที่สำคัญต่อองค์กรหลายๆตัวเป็นหลักและดูว่าส่วนไหนที่ทำ เป็น Centralize แล้วจะเกิดประโยชน์สูงสุด
  • ทำการร่าง Standard Model โดยการหาส่วนที่ซ้ำกันของ Data จาก Business Process และ Application ที่เราเลือกไว้
  • ข้อมูลที่เป็น Master Data จะต้องถูกจัดการให้สามารถเข้าถึงได้ จากทุกส่วนขององค์กรที่มีความจำเป็นต้องใช้งานและ กำหนดให้มันเป็นหนึ่งในเครื่องมือของการทำ Consolidation
  • สร้างถังเก็บข้อมูลกลาง โดยการทำการรวบรวมและ Harmonize เพื่อสร้าง unique instance
  • ทำการ integrate ข้อมูลที่ถูก harmonized แล้วเข้ากับ application เดิมที่มีอยู่หรือ application ใหม่ที่กำลังจะถูกสร้าง ผ่านทาง Service Oriented Architecture
  • ข้อสุดท้ายที่สำคัญที่สุดคือการสร้างกฎและข้อบังคับขึ้นในระดับองค์กรในเรื่องของการใช้งาน Master Data เพื่อให้มันทำ หน้าทีรักษาความถูกต้องของข้อมูลต่อไปในอนาคต

Architecture Approach to MDM
หลังจากที่เราได้เห็นขั้นตอนและกระบวนการทำ MDM แล้วส่วนต่อมาคือพิจรณา Architecture Approach ที่เหมาะสมกับองค์กรของเราซึ่งปัจจุบันนี้มีอยู่ 3 approaches ด้วยกันคือ Central Master Data System, Mapped Master System และ Hub Repository เรามาดูตัวแรกกันก่อน
Central Master Data System: วิธีการนี้จะเป็นการนำเอา attributes ต่างๆของข้อมูลที่่ถูกใช้ร่วมกันในองค์กร มารวมกันไว้ในที่ที่เดียวเป็น Master System และเจ้า Master system นี้จะทำหน้าที่ publish ข้อมูลออกไปให้กับระบบ ต่างๆที่ต้องการใช้ข้อมูล โดยระบบปลายทางมีหน้าที่ที่จะต้องจัดการ attributes อื่นๆที่ไม่อยู่ในกลุ่มของ Master Data เอง ในกรณีของการสร้างข้อมูลใหม่นั้นจะถูกทำที่ระบบปลายทางและหลังจากนั้นจะต้องมีการ Sync ข้อมูลกลับมาที่ Master System เสมอและข้อมูลทั้งหมดจะต้องสามารถถูกอ้างได้ถึงกันหมดผ่าน Global ID

Mapped Master System: วิธีการนี้จะแตกต่างจากแบบแรกคือเราจะต้องตัดสินใจเลือกก่อนว่าระบบใดจะเป็นเจ้าของ ข้อมูลก่อนเช่น CRM เป็นเจ้าของข้อมูล Customer และ Product ดังนั้นกรพบวนการสร้างข้อมูลสองอย่างนี้ต้องทำที่ CRM ก่อนแล้วจะทำการ Publish ออกไปให้กับระบบปลายทางใช้งานแต่อีกสิ่งหนึ่งที่ทำให้แตกต่างจาก Central Master คือวิธีแบบนี้จะไม่มี Global ID ระบบจะทำการ transform ข้อมูลที่จะส่งไปให้กับระบบปลายทางให้อยู่ในรูปแบบที่ต้องการ นอกจากนี้ระบบปลายยังสามารถเพิ่ม attributes ที่ตัวเองต้องการเข้าไปได้อีกเช่นกัน

Hub Repository: วิธีการนี้เป็นแบบ Extreme คือมีที่เก็บข้อมูลที่เดียวคือ Master Data Hub และจะไม่มีการ Replicate ข้อมูลไปที่ระบบอื่นๆเลยดังนั้นการสร้างการแก้ไขใด้ๆก็ตามต้องส่งมาทำที่ Hub เท่านั้น

อย่างไรก็ตามสามวิธีการนี้เป็นแนวทางที่เป็นที่นิยมในปัจจุบันซึ่งจริงๆแล้วยังมีวิธีการทำ MDM อีกสองถึงสามวิธีแต่ไม่ขอ กล่าวถึงในเอกสารนี้
ความท้าทายในการทำ DMD ในองค์กร
เนื่องจากว่าการทำ MDM ต้องถูกมองให้เป็น Program หรือแผนแม่บท มันไม่สามารถถูกมองให้เป็นระบบได้ดังนั้น เพื่อเป็นการป้องกันความล้มเหลวในการทำ MDM ขอให้ทำตามขั้นตอนด้านล่าง

  • Organization Preparedness: เนื่องจากการทำ MDM จะเป็นการเปลี่ยนมุมมองของข้อมูลจากที่เคยเป็น Loosely Couple กันแต่ละระบบให้เป็นแบบ Tightly-Couple กับ Master Data มากขึ้น เพื่อเป็นการป้องกันการเข้าใจผิด องค์กรควรจัดการสัมมนาหรือเทรนเรื่อง MDM Concept ให้กับผู้ที่มีส่วนเกี่ยวข้องทั้งหมดก่อน
  • Data Governance: กระบวนการสำคัญอีกข้อสำหรับ MDM คือการสร้าง Policies และ Procedures ขึ้นมาเพื่อใช้สำหรับ ควบคุมคุณภาพของ Master Data ดังนั้นระหว่างที่เราทำการเผยแพร่ข้อมูลนี้และทำการเก็บความคิดเห็นของส่วนต่างทั้ง องค์กรเราจะสามารถสร้าง Stewartship Framework ขึ้นมาได้เพื่อใช้สำหรับการทำ Data Transition ในองค์กรของเรา
  • Technology Integration: เตรียมพร้อมเรื่องของการ Integrate Technology เข้ากับ Process แทนที่การปรับ Process ให้เข้ากับ Technology เพื่อหลีกเลี่ยงปัญหาการผูกติดเทคโนโลยีเข้ากับ product package
  • Anticipating Change: การสร้าง MDM ขึ้นมาในองค์กรย่อมทำให้เกิดการเปลี่ยนแปลงขึ้นมากมาย ดังนั้นอีกสิ่งที่สำคัญ คือเราต้องท้าทายให้พนักงานที่เกี่ยวข้องกับ MDM มีใจยอมรับความเปลี่ยนแปลงและคิดว่าเป็นการเรียนรู้สิ่งใหม่ๆ

Spring MVC 3 มันเป็นยังไง

June 25th, 2010

จริงมีเนื้อหาสำหรับ Spring MVC มาแล้วสามตอนด้วยกันคือ SpringMVC ภาค 1, SpringMVC ภาค 2 และ SpringMVC ภาค3 หรือสามารถเข้าไปหาหาจาก Tag SpringMVC ได้ครับ
แต่วันนี้มาดูของใหม่ใน Spring MVC 3 กันหน่อยว่าสวยงามกว่าเดิมขนาดไหนก่อนอื่นให้ไป Check Out โค้ดตัวอย่าง mvc-basic และให้เพิ่ม jetty plugin เข้าไปเพื่อความสะดวกในการทดสอบเพราะไม่อยาก build เป็น war
เมื่อเรียบร้อยแล้วเรามาดูกันทีละไฟล์ไปว่ามีอะไรน่าสนใจบ้างไฟล์แรกที่เราจะดูคือ web.xml ส่วนแรกคือ UrlRewriteFilter โอวจริงมันเป็นของที่เพิ่มเข้ามาเพื่อทำให้ URL สวยงามตามมาตรฐาน REST (ตัวโปรเจคอยู่ที่ urlrewritefilter ได้รับอิทธิพลจาก mod_rewrite)

<!-- Enables clean URLs with JSP views e.g. /welcome instead of /app/welcome -->
<filter>
<filter-name>UrlRewriteFilter</filter-name>
<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
</filter>

<filter-mapping>
<filter-name>UrlRewriteFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

ส่วนต่อมาคือ app-config.xml ส่วนนี้ไม่มีอะไรน่าตื่นเต้นสิ่งที่เราใส่ไว้คือการเปิดใช้ Component Scanning ที่จะช่วยเราหา bean แบบอัตโนมัติและพ่วงท้ายด้วยการ import ตัว spring mvc config เข้ามาด้วย

<!-- Configures Spring MVC -->
<import resource="mvc-config.xml" />

และสำหรับ mvc-config.xml เองมีเรื่องน่าสนใจคือเราจะใช้สิ่งที่เรียกว่า annotation-driven tag

    <!-- Configures the @Controller programming model -->
    <mvc:annotation-driven />

หน้าที่ของ tag จะจัดการใส่ HandlerMapping และ HandlerAdapter เข้าไปใน @Controllers นอกจากนี้มันยังทำการกำหนดค่า default ต่างๆที่เรามีไลบารี่อยู่ใน Class Path ของเราเช่น
รองรับการทำ formatting Number fields ด้วย @NumberFormat
รองรับการทำ formatting Date, Calendar, และ Joda Time fields ด้วย @DateTimeFormat, ถ้า Joda Time อยู่ใน classpath
รองรับการทำ validating @Controller ด้วย @Valid,ถ้า JSR-303 Provider อยู่ใน classpath
รองรับกาอ่านและเขียน XML, ถ้า JAXB อยู่ใน classpath
รองรับการอ่านและเขียน JSON,ถ้า Jackson อยู่ใน classpath
ส่วนต่องมาที่น่าสนใจคือ

    <!-- Forwards requests to the "/" resource to the "welcome" view -->
    <mvc:view-controller path="/" view-name="welcome"/>

เบื้องหลังการทำงานเราจะเห็นว่า mvc:view-controller ทำการใส่ ParameterizableViewController ที่จะทำหน้าที่เลือก view สำหรับการ render ยกตัวอย่างเช่นเมื่อมีการเรียก “/” จะมีการเปลี่ยนค่าเป็น welcome.jsp ที่อยู่ใน /WEB-INF/views แทน
ส่วนต่อไปใน mvc-config จะแสดง

    <!-- Configures Handler Interceptors -->
    <mvc:interceptors>
        <!-- Changes the locale when a 'locale' request parameter is sent; e.g. /?locale=de -->
        <bean class="org.springframework.web.servlet.i18n.LocaleChangeInterceptor" />
    </mvc:interceptors>

mvc:interceptors ช่วยให้เราใส่ HandlerInterceptors เข้าไปใน Controller ได้ซึ่งมันจะช่วยอำนวยความสะดวกให้เราได้มากขึ้นเพราะก่อนหน้านี้เราต้อง register interceptor ลงไปใน HandlerMapping เป็นตัวๆไปแต่ปัจจุบันเราสามารถระบุผ่าน URL ได้เลย
Data Binding Simplification
ส่วนที่น่าสนใจที่สุดสำหรับผมคือเรื่องการ Binding เราสามารถทำ Binding ได้ง่ายเหมือนเดิมรวมถึงสามารถใช้ Validation Annotation ได้ด้วย

public class Account {
    private Long id;
    @NotNull
    @Size(min = 1, max = 25)
    private String name;
    @NotNull
    @NumberFormat(style = Style.CURRENCY)
    private BigDecimal balance = new BigDecimal("1000");
    @NotNull
    @NumberFormat(style = Style.PERCENT)
    private BigDecimal equityAllocation = new BigDecimal(".60");
    @DateTimeFormat(style = "S-")
    @Future
    private Date renewalDate = new Date(new Date().getTime() + 31536000000L);
    ...
}

ในส่วนของ Controller เองก็สามารถใช้ Annotation ได้มากขึ้นและไม่ต้องมีกระบวนการภายใน Controller เองเยอะเหมือนสมัยก่อน ยากตัวอย่างเช่น Validation ที่ Model Level สามาถถูกเรียกใช้ด้วยการใช้ @Validate ตัวอย่างด้านล่างเป็นการรับ POST request ที่ Spring จะทำการ Bind ตัว Request กลับมาเป็น Account account ให้เราเองเลย

    @RequestMapping(method = RequestMethod.POST)
    public String create(@Valid Account account, BindingResult result) {
        if (result.hasErrors()) {
            return "account/createForm";
        }
        this.accounts.put(account.assignId(), account);
        return "redirect:/account/" + account.getId();
    }

ส่วนการรับ GET request ก็ทำได้หลายแบบเช่นจังหวะการ initiate Form กับ Object ที่จะใช้รับค่าก็ทำได้ดังนี้

    @RequestMapping(method = RequestMethod.GET)
    public String getCreateForm(Model model) {
        model.addAttribute(new Account());
        return "account/createForm";
    }

และถ้าเราต้องการดูรายละเอียดของ Account ที่เราต้องการด้วยการรับ accountId เข้ามาก็สามารถทำได้

    @RequestMapping(value = "{id}", method = RequestMethod.GET)
    public String getView(@PathVariable Long id, Model model) {
        Account account = this.accounts.get(id);
        if (account == null) {
            throw new ResourceNotFoundException(id);
        }
        model.addAttribute(account);
        return "account/view";
    }

ตัวหย่างนี้เป็นการใช้ springMVC3 แบบบ้านที่สุดตอนต่อไปคือเราจะมาลองดูกันว่าถ้าเราจะทำ RESTful WS ด้วย SpringMVC 3 เราจะสามารถทำได้ไหม

Maven คืออะไร

May 26th, 2010

What is Maven?
เรามาทำความรู้จักMavenกันก่อน Maven นั้นเกิดในยุดของการสร้าง Web Application ด้วย  Web Framework ในช่วงแรกๆ (Apache Turbine Web Application Framework) โดยสาเหตุหลักที่ทำให้เกิด Maven ขึ้นมาเพราะเมื่อก่อนเราจะใช้ Ant หรือ Build Script ที่เราสร้างขึ้นมาเอง ในการ build โปรเจคซึ่งสองสิ่งนี้มีความยืดหยุ่นสูงมากและในทางกลับกันพอเรามีโปรเจคมากขึ้น การใช้สองสิ่งนั้นมันดูยุ่งยากและจัดระเบียบในเรื่องต่างๆไม่ว่าจะเป็น Project Structure หรือ Library Management ได้ค่อนข้างยาก ผลคือทำให้เกิด Maven ขึ้นมาโดยที่มันเองก็เป็น build tool อีกตัวนึงที่สามารถทำในสิ่งที่ Antและ Build Script ทำได้ยากได้ ดังนั้น Mavenจึงเป็น build tools อีกตัวนึง ที่เอาไว้ใช้ build, compile, test, clean, deploy โปรเจคของเรา นอกจากนั้นMavenยังสามารถทำ dependency management,Javadoc ,siteและอื่นๆได้อีกด้วย มันจะทำให้การทำงานในโปรเจคของเราทำงานได้อย่างเป็นระเบียบ, ยืดหยุ่น โดย Maven จะมีไฟล์ config ของโปรเจคที่เป็น xml เพียงไฟล์เดียว ทำให้แก้ไขได้ง่าย และไม่รกต่อไฟล์ของโปรเจคเรา

ทำไมเราต้องใช้Maven, Problem?
ข้อดีของMavenมีมากมายก่ายกอง แต่ผมจะยกมาให้ดูเพื่อเห้นภาพซัก2ตัวอย่างว่าทำไมเราต้องใช้Maven
1. Maven จะมีStructure ของโปรเจคที่เป็น standard อันนี้เป็นข้อดีอย่างมาก ถ้าลองนึกภาพดู ถ้าเกิดเรามีโปรเจคซัก 6-7โปรเจค พอเวลาprogrammer จะเขียนโปรแกรมทีนึงแต่ละคนก็จะกำหนด structureของแต่ละคนทีนึง แล้วถ้ามีโปรเจคอยู่6-7 โปรเจค เท่ากับว่ามีstructureของโปรเจคทั้ง6-7แบบ
ปัญหา : ถ้าเราจะศึกษาโปรเจคนั้นเท่ากับว่าเราก็ต้องศึกษาstructure ทั้งหมดนะสิเหนื่อยตายพอดีครับ
ทางแก้ : Mavenเขาก็เลยกำหนดstandardขึ้นมาซะ ทำให้เราศึกษาแค่ตัวstandardของมันเพียงตัวเดียว เทากับว่าเราก็สามารถเข้าใจได้ในทุกๆโปรเจค

Standard directory organization

จากรูปด้านบนแสดงให้เห็นถึงเมื่อว่าเราทำงานในหลายๆ โปรเจคด้วยกัน แต่ละโปรเจคก็จะมีstructure เดียวกัน และแต่ละโปรเจคไฟล์configก็จะถูกเก็บไว้ไฟลืเดียวคือ pom.xml ทำให้ structure ของโปรเจคเรามีระเบียบมาก และถ้าเกิดrogrammerคนต่อไปมาพัฒนาต่อ ก็จะทำให้พัฒนาต่อได้โดยไม่ต้องมานั่งศึกษาstructureของโปรเจคต่ออีกมาก

2. Maven สามรถทำ Dependency management ได้ ทำให้programmer ไม่ต้องมาคุบควมdependencyที่จะเรียกมาใช้งาน
ปัญหา : ถ้ามีโปรเจคย่อยอยู่6-7โปรเจค แต่ละคนก็ใช้ dependency ของแต่ละคน เท่ากับว่าทุกโปรเจคต้องมาset pathของdependency ทุกโปรเจค
ทางแก้ : Maven จะมี repositoryที่รวบรวม dependencyไว้ให้บนinternetโดยเราไม่ต้องห่วงว่าจะใช้dependencyตัวนี้จะต้องโหลดที่ไหน เพียงเราแค่กำหนดชื่อ กับversionของdependencyที่เราจะใช้เข้าไป config ที่ pom.xml นอกนั้Maven จะจัดทำการเรียกหาdependencyให้เราเอง

Dependency management
เจ้าdependency management ตัวนี้หรอจะพูดได้อีกอย่างว่า ตัวจัดการlibraryให้เรานั้นเอง เราแค่กำหนดชื่อ และversionให้เท่านั้น ก็จะทำการเลือกหา dependency

จากรูปด้านบนแสดงให้เห็นถึงเมื่อว่าเราทำงานในหลายๆ โปรเจคด้วยกัน แต่ละโปรเจคก็จะมีstructure เดียวกัน และแต่ละโปรเจคไฟล์configก็จะถูกเก็บไว้ไฟลืเดียวคือ pom.xml ทำให้ structure ของโปรเจคเรามีระเบียบมาก และถ้าเกิดrogrammerคนต่อไปมาพัฒนาต่อ ก็จะทำให้พัฒนาต่อได้โดยไม่ต้องมานั่งศึกษาstructureของโปรเจคต่ออีกมาก

2. Maven สามรถทำ Dependency management ได้ ทำให้programmer ไม่ต้องมาคุบควมdependencyที่จะเรียกมาใช้งาน
ปัญหา : ถ้ามีโปรเจคย่อยอยู่6-7โปรเจค แต่ละคนก็ใช้ dependency ของแต่ละคน เท่ากับว่าทุกโปรเจคต้องมาset pathของdependency ทุกโปรเจค
ทางแก้ : Maven จะมี repositoryที่รวบรวม dependencyไว้ให้บนinternetโดยเราไม่ต้องห่วงว่าจะใช้dependencyตัวนี้จะต้องโหลดที่ไหน เพียงเราแค่กำหนดชื่อ กับversionของdependencyที่เราจะใช้เข้าไป config ที่ pom.xml นอกนั้Maven จะจัดทำการเรียกหาdependencyให้เราเอง

Dependency management
เจ้าdependency management ตัวนี้หรอจะพูดได้อีกอย่างว่า ตัวจัดการlibraryให้เรานั้นเอง เราแค่กำหนดชื่อ และversionให้เท่านั้น ก็จะทำการเลือกหา dpendencyมาให้เราใช้ในโปรเจคให้เราเอง

height=316

ในรูปนี้คือปัญหาของเราในการทำโปรเจค เพราะ แต่ละโปรเจคก็จะมีการเรียกใช้ depedency ที่ทั้งแตกต่างกันและซ้ำกัน โดยdepedencyที่ซ้ำกันไปเก็บไว้คนละที่กัน

height=311

เนื่องจากปัญหาดังรูปด้านบนที่ทำให้มีการเก็บdependencyที่เหมือนๆกันหลายที่โดยเจ้าmaven ก็เลยแก้ปัญหาโดยการสร้างที่เก็บกลาง หรือ local repository

height=288

ต่อจากภาพด้านบน เมื่อเราทำlocal repository หรือที่เป้นที่เก้บdependencyกลางนั้น แล้วเราจะเอาdependencyมาจากไหนละ?
คำตอบคือ Maven เตรียมให้เรียบร้อยแล้ว โดยเราจะทำการdownload dependencyที่เราจะใช้งานในinternet มาเก็บไว้ที่local repository นั้นเอง ถ้าสังเกตตอนใช้maven ครั้งแรกจะนานมากๆ เพราะต้องdownload dependency จากinternet มานั้นเอง
แล้วจากที่อ่านมาสงสัยรึเปล่าว่าทำไมในโปรเจคเราต้องใช้depedency ด้วยละ?
เนื่องจากJava นั้นมี libraryเป้นล้านแปด แล้วแต่ละตัวก็มีversionอีกมากมาย แล้วถ้าเราจะทำซักโปรเจคนึงเราต้องโหลดเจ้าlibraryเป็นล้านแปดมาหรอ? ฉะนั้นเราก็ต้องกำหนดเฉพาะที่จะใช้ในโปรเจคเท่านั้น
ทำไมใช้dependency แล้วต้องกำหนดversionด้วยละ?
อย่างที่ข้อด้านบนบอก library เองก็มีversionเยอะมากมายแล้ว ถ้าเกิดนายAใช้ version 1.2 แล้วนายAเกิดลาออกจากงานไป ทำให้นายBต่องมารับช่วงโปรเจคต่อ แล้วนายBไปใช้version 1.3 ละ คราวนี้ก็ซวยสิครับ ฉะนั้นเราจึงกำหนดversionให้มันอย่างละเอียดซะ จะได้ไม่เกิดปัญหาภายหลัง