SOA คือ

รวมลิงค์

http://www.isriya.com/node/953
http://www.ku.ac.th/e-magazine/march45/it/web3.html
http://www.guru-ict.com/mambo/index.php?option=com_content&task=view&id=104

Read More

Portlet คือ

เอามาจาก Narisa ครับ

http://www.narisa.com/forums/lofiversion/index.php?t4749.html

Portal หรือบางคนเรียกว่า Dashboard เป็น front end ให้ผู้ใช้สามารถดู/วิเคราะห์/ใช้ข้อมูลจากองค์กรตามลักษณะงานของผู้ใช้ เช่น Portal ของฝ่ายขายจะมีข้อมูลผลิตภัณฑ์จากฝ่ายผลิต ข้อมูลสินค้าคงคลังจากฝ่าย inventory ข้อมูลยอดขายของตน และอื่นๆ ในขณะที่ Portal ฝ่ายลูกค้าสัมพันธ์จะแสดงข้อมูลของบริษัทในรูปแบบอื่น ประเด็นสำคัญคือการใช้ single sign-on ล๊อกอินครั้งเดียว แล้วสามารถดึงข้อมูลจากหลายๆระบบในองค์กรได้ครับ

จากคุณ นายข้าวโพดหวาน

Read More

IOC คืออะไร

ก๊อบมาจาก http://cp27.linux.eng.chula.ac.th/index.php?act=Print&client=printer&f=13&t=1031 มันต้องล็อกอินอ่ะ

วันนี้ว่างครับ เรามาเริ่มที่ IoC กันก่อนดีกว่า 1. Introduction to Spring Frameworkบอกไว้ก่อนว่า code ทั้งหมดเป็น C#1.1 IoCก่อนจะไปดู Spring เรามาทำความเข้าใจกับ IoC ก่อน1.1.1 IoC ย่อมาจากอะไรInversion of Control1.1.2 ความหมายของ IoCความหมายตรงตัว แต่การแปลตรงตัวอาจจะยังไม่ชัดเจนเท่าที่ควร การอธิบายด้วย code ดีที่สุดครับ
CODE
public interface IA { int I { get; } IB B { get; }}public class A : IA { private int i; private IB b; public int I { get { return i; } } public IB B { get { return b; } } public A() { i = 100; b = new B1(); }}public interface IB {}public class B1 : IB {}public class B2 : IB {}
จากไอ้ code เวรข้างบน ดูเผินๆ มันก็ไม่มีอะไรที่ไม่ดี แต่ข้อจำกัดของมันคือ ไอ้ Properties ทั้งสองตัว ของ A มันถูก Hardcoded ไว้แล้ว ถ้าอยากเปลี่ยน ต้องมาแก้โค้ด ของ A อย่างเดียวเท่านั้นต่อมาเรามาดูไอ้สิ่งที่เรียกว่า IoC กัน
CODE
public class AWithIoCByConstructor : IA { private int i; private IB b; public int I { get { return i; } } public IB B { get { return b; } } public AWithIoCByConstructor() : this(100, null) { } public AWithIoCByConstructor(int i, IB b) { this.i = i; this.b = b; }}public class AWithIoCBySetter : IA { private int i; private IB b; public int I { get { return i; } internal set { i = value;} } public IB B { get { return b; } internal set { b = value;} }}public class AFactory { public IA CreateAWithIoCByConstructor() { return new AWithIoCByConstructor(100, new B1()); } public IA CreateAWithIoCBySetter() { a = new AWithIoCBySetter(); a.I = 100; a.B = new B1(); return a; }}
อย่างที่เห็นครับ ไอ้ข้างบนนี้เรียกว่า IoC คือ จะมีเมทอดอื่นมาใส่ค่าที่ต้องการให้กับตัว instance ของเรา ตัวอย่างข้างบน ใช้ FactoryMethod Pattern ไอ้ IoC (ที่กูคิดออก) มีอยู่สองแบบ คือ ใส่ค่าผ่าน Constructor กับ ผ่าน Setter ซึ่งเลือกใช้ตามความชอบจะเห็นว่า ถ้าเราอยากได้ B2 แทน B1 ก็ไม่จำเป็นต้องแก้ AWithIoC* เลย แก้ตัวFactoryแทน ภาระที่เพิ่มขึ้นก็คือต้องมาเขียน ไอ้การใส่ค่าเองแต่!!! สุดท้าย ก็ต้องมีการ แก้ code อยู่ดี กูมีทางออกง่ายๆครับ ใช้ property file เอาก็ได้ว่า เราจะใส่ค่าอะไรบ้าง วิธีนี้ทำให้ไม่ต้องแก้ code เลยครับ ส่วนนี้เป็นเรื่องของ IoC ครับ จะยังไม่พูดถึง Spring แต่จะบอกไว้ก่อนว่า Spring ก็มีวิธีคล้ายๆกันนี้ ทำให้ไม่ต้องแก้ code เลยคิดว่าตอนนี้คงเข้าใจ IoC แล้ว (และ คงเข้าใจแล้วว่า Spring ไว้ทำอะไร) ต่อไป จะพูดถึง DI1.2 DI1.2.1 DI ย่อมาจากอะไรDependency Injection1.2.2 ความหมายของ DIไอ้ DI จริงๆแล้วมันก็คือส่วนที่น่าสนใจของ IoC เนี่ยแหล่ะครับ แต่เป็นชื่อที่นิยมใช้กันมากกว่า เพราะว่า มันเห็นภาพมากกว่าไอ้ IoC ถ้าดูจากไอ้ interface IA กับ IB ใน code ของ IoC ข้างบน IB เรียกว่าเป็น Dependency ของ IA คำว่า Dependency Injection คือไอ้การ ใส่ค่าจาก เมทอด ข้างนอก นั่นเอง (โดยส่วนตัวแล้ว คำว่า DI มันเห็นภาพชัดกว่า ไอ้คำว่า IoC)จริงๆแล้วมันจะมีอีกคำ คือ Dependency Lookup (J2EE สุดสมันใช้วิธีนี้ด้วย JNDI) ซึ่งมันไม่ค่อยช่วยอะไรมาก จะไม่ขอพูดถึง1.3 Java Beanเนื่องจาก Spring Framework เริ่มต้นที่จาวา งั้นเรามารู้จักจาวาบีนเวรก่อนเนื่องจากความกระแดะของใครสักคน มันเสร่อ ตั้งชื่อไอ้คอมโพเนนท์ที่เขียนด้วยจาวาเพื่อต่อกันได้ด้วยการลากแปะ ว่า จาวาบีน แปลตรงตัวว่า เมล็ดกาแฟ ต่อจากนี้ขอเรียกว่า นัดถั่วเหตุเกิดจากการทำ dynamic binding ของ Java (ซึ่งเสร่อมาก) ทำให้ถ้าคนไม่รู้พื้นฐานอาจจะงงได้ ถ้าคนเขียน C++ มาจะรู้ว่า ตัวคนเขียนจะต้องระบุด้วยว่าจะทำ dynamic binding ของ method ไหนบ้าง ด้วยการใช้ keyword virtual ไว้เวรจาวามันเสร่อทำให้ทุก method เรยครับ (อันนี้ไม่ว่ากัน) แต่ instance varaible จะไม่มีการใส่ virtual เข้าไปให้ (คิดว่า C++ ก็ไม่สามารถใส่ virtual เข้าไปได้นะ) ทำให้ไม่สามารถทำ dynamic binding ได้ ผลก็คือ ทำ polymorhpsm ของ instance variable ไม่ได้นั่นเองไอ้ผลข้างบน ทำให้ต้องเขียน method มาใช้ในการ อ่านค่า หรือ ตั้งค่า ของ instance variable นั่นเองแต่ถ้าเขียนมั่วๆแม่งก็จะทำให้การใช้คอมโพเนนจาวาด้วยการลากแปะมันไม่เวิร์คเพราะว่า refection ไม่สามารถแยกแยะได้ว่าอันไหนเป็นเมทอดในการอ่านค่า ตั้งค่า หรือ อื่นๆ มันก็เลยตั้งคอนเวนชั่นขึ้นมา ซึ่งหลักๆก็คือ ไอ้ setter getter นั่นเองสรุปแบบง่ายๆได้ว่า นัดถั่วคือ จาวาคอมโพเนนที่สามารถทำการลากแปะในโปรแกรมที่สร้างขึ้นมาได้ (ให้คิดถึง การเขียนวินโดว์วีบีก็ได้ นะ) ซึ่งไอ้คลาสเวนจะมี ชื่อ เมทอดที่เป้น setter ว่า set แล้วตามด้วย ชื่อ instance variable มี argument เดียว กับ getter ซึ่งขึ้นต้นด้วย get แล้วตามด้วย ชื่อ instance variable ไม่มี argumentตย.public int getCount() { return count; }public void setCount(int count) { this.count = count; }1.4 Spring Frameworkหลักๆแล้วไอ้ เวร Spring Framework คือ IoC แต่มันจะมีส่วนที่เพิ่มมาด้วยคือ AOP ซึ่งน่าสนใจนิดหน่อย เมื่อเทียบกับ IoCรู้สึกว่าไอ้การพิม Spring Framework มันยาวไปหน่อย ต่อจากนี้ขอเรียกว่า ไอ้ปิง1.4.1 Spring Framework's IoCไอ้ปิงมันมี คลาสชื่อ BeanFactory มาให้ ซึ่งไอ้คลาสนี้ มันจะไปอ่านคอนฟิกไฟล์ที่เราใส่ให้มัน แล้วทำการ สร้าง factory ให้ ข้อดีที่เห็นแวบแรกคือ เราไม่ต้องเขียน FactoryMethod เองเรยดูตัวอย่างกันก่อน
CODE
XmlBeanFactory factory = new XmlBeanFactory(new FileSystemResource("a.xml"));IA a = (IA)factory.getBean("MyA");
ส่วน a.xml หน้าตาแบบนี้
CODE

ไอ้ตัวอย่างข้างบนนี้เอาไปใช้จริงไม่ได้ เพราะจริงๆแล้วไอ้ attribute class ต้องเป็น FullClassNameอธิบายวิธีใช้กันหน่อย XmlBeanFactory() เป็นคลาสที่อ่าน configure ที่เป็น xml มันจะมี Factory อื่นๆด้วย ซึ่งเลือกใช้กันเอาเอง แต่ที่สำคัญคือ getBean() ครับ สิ่งที่ใส่เข้าไปคือ alias ของ คลาสที่เราต้องการ ในที่นี้ MyA คือ AWithoutIoC ถ้าเกิดเราต้องการเปลี่ยน คลาสก็แค่มาแก้ a.xml ก็จบ ไม่ต้องแก้ code เลยตัวอย่างข้างบนนี้มันยังไม่ได้แสดงความเจ๋งของ DI นะ เป็นแค่ DL เท่านั้นอีกอย่าง ไอ้ปิงจะคิดเอาเองว่าทุก instance ของคลาสที่เราใส่ alias ให้มัน เป็น singleton ระดับ factory แปลเป็นภาษามนุษย์ว่า ในหนึ่ง BeanFactory จะมี instance ของ MyA แค่อันเดียวเท่านั้น จะ getBean() กี่รอบก็ได้ตัวเดิม ถ้าเราอยากได้แบบไม่ singleton ก็จะมี attribute ให้ใส่เพิ่มใน คราวนี้เรามาดูความเท่ของ ไอ้ปิง กับ DI ดีกว่า กูจะเปลี่ยนแค่ a.xml นะ (ขี้เกียจเขียน เพิ่ม)
CODE

จากโค้ดด้านบน เห็นชัดๆเรยว่า ถ้าอยากได้ instance ของ class A ก็แค่ขอจาก method getBean("MyA") ของ ไอ้ปิง ส่วนค่าต่างๆ ไอ้ปิงทำให้ โดยที่ไม่มีการ hardcoding เรย ถ้าเราอยากเปลี่ยนก็เปลี่ยน ค่าใน a.xml เอา (จริงๆแล้วไอ้ปิงสามารถทำ DI แบบ ผ่าน constrcutor ได้ด้วยแต่ไอ้ตัวอย่างข้างบนเป็นแบบผ่าน setter)ประโยชน์ของ DI ที่ไอ้ปิง มีให้ สามารถนำไปใช้ต่อได้กับ lib อื่นๆ เช่น J2EE Hibernate AXIS2 AspectJ และอื่นๆ(คิดไม่ออก) โดยที่ไม่จำเป็นต้องมีการเขียน code ของ ไอ้สิ่งที่นำมาใช้เรยด้วยซ้ำ นี่แหล่ะความเท่ของมัน

Read More

AOP คืออะไร

ผมก๊อบข้อมูลมาให้ลองอ่านกันดูครับ จะเก็บไว้อ่านเองด้วยนั่นล่ะ ง่ายต่อการค้น อิอิ

AOP เอาไว้แก้ปัญหาเรื่อง Cross cutting concern นะ
แปลเป็นไทย cross cutting concern ก็คือ สิ่งที่เราต้องสนใจที่ตัดผ่านสิ่งที่เราสนใจ

ยกตัวอย่างละกัน เราจะทำระบบอะไรสักอย่าง เช่น โอนเงินระหว่างบัญชี จากธนาคารละกันนะ
ในส่วนนี้ concern หลักของ bussiness ก็แค่ ลดเงินของ บัญชีนึง แ้้ล้วไปเพิ่มใส่อีกบัญชีนึง

แต่จากระบบนี้ เราจะมี cross cutting concern ที่ตัดผ่านงานเราเยอะแยะเลย เช่น การใส่ใจเรื่อง security authentication, transection management, logging message, presistance, availability ต่างๆ

พวกนี้อาจจะเป็นทั้ง functional หรือ non-function requirement ของระบบก็ได้ค่ะ

จะเห็นว่าในระบบเรานี้ นอกจากส่วน โอนเงิน cross cutting concern เหล่านี้มันลากตัดผ่าน ระบบอื่นๆ อีกเพียบเลย

บางระบบ อาจจะมี แค่ logging แต่ไม่มี security authen
บางระบบ ก็ใช้ concern ต่างๆ พวกนี้ไม่เท่ากัน

เวลา implement ด้วยแนวทาง OOP จึงทำให้เกิดปัญหาต่างๆ คือ
- concern เหล่านี้ลากตัดผ่านกระจัดกระจาย ทั่วไปในงานเรา (scattering) บางงานใช้บ้าง ไม่ใช้บ้าง
- โค๊ดของงานเราในแต่ละ modular ยุ่งเหยิง (tangling) เพราะมัวแต่ไปจัดการเรื่อง cross cutting เหล่านี้ ทั้งที่จริงๆ แล้ว bussiness ของงานมันแค่นิดเดียวเอง

เมื่อเป็นเช่นนี้แ้ล้วก็ระบบก็จะมี low cohesive เกิด high couple ไ่ล่ code ก็ยาก แ้ล้วก็ reuse ได้ยากอีกเช่นกันนะ

แนวทางใหม่ที่นำเสนอขึ้นนั่นคือ AOP (aspect oreinted programming)ค่ะ
aop สามารถนำมาประยุกต์ให้เข้ากับ OOP ได้อย่างดี ช่วยแก้ปัญหาที่พบได้เร็วขึ้น
concern แยกออกจากกันอย่างชัดเจน สามารถ trace concern เหล่านี้ได้มากกว่าค่ะ

ลองหาเอกสาร AOP เพิ่มเติมดูละกันนะคะ
สำหรับ JAVA ถ้าอยากเขียนงานให้สามารถทำ AOP ได้ลองศึกษา AspectJ ดูละกันค่ะ

จากที่รักบอกมา เจ้าค่ะ

หนูเป็นเด็กอยากรู้อยากเห็น เจ้าค่ะ


จากคุณ deans4j แห่ง Blognone.com http://www.blognone.com/node/1426

Review
AOP หรือ aspect-oriented programming (ใน thesis ป. โท ผมเมื่อ 3-4 ปีก่อน ใช้คำว่า
"การโปรแกรมเชิงลักษณะ" ครับ) เป็น paradigm สำหรับแก้ปัญหาความซ้ำซ้อนของ code แนวขวาง
(crosscutting concern) AOP พิจารณาจุดใน program flow เช่น constructor, method
และอื่น ๆ เป็น joinpoint abstraction และยอมให้จับกลุ่มจุดเหล่านั้นด้วยคำอธิบาย
เรียกว่า pointcut สำหรับ code ที่จะให้ทำงานที่ pointcut จะเรียกว่า advise code
ซึ่งจะสามารถระบุได้ว่าจะให้ทำงานในตำแหน่งอ้างอิงใดกับจุดที่รวบไว้โดย pointcut นั้นๆ เช่น before, after,
และ around ครับ นอกจากนี้ AOP ยอมให้ประกาศ field, method และอื่น ๆ เพิ่มเข้าไปใน code เดิม
ซึ่งเรียกว่า introduction หรือ inter-type declaration และทั้งหมด
ก็รวบอยู่ในหน่วย ๆ เดียวเรียกว่า aspect

Proxy-based AOP
Spring framework ดังสุดในกลุ่มนี้ (อย่างน้อยก็จากมุมมองของผม) สำหรับ aspect ที่ spring เน้น
ก็คือ Transactional และอื่น ๆ เมื่อมองจาก AOP การจัดการ transaction ก็เป็นเพียง aspect เดียวเท่านั้นครับ
ซึ่งจริงๆ เราสามารถสร้างและใช้ aop ได้ในหลายแนวทาง การติดอยู่กับ aspect ที่มีมากับ framework หนึ่ง ๆ
จะทำให้ code บางส่วนซ้ำซ้อนในที่สุด

ผมจึงคิดว่าจุดที่ต้องส่งเสริมกันคือความเข้าใจพื้นฐานในการแยก aspect ออกจาก object-orieted code
และที่อยากให้หลายท่านลองกันก็คือ aspectj ครับ

Aspect-Oriented System
AspectJ เป็นภาษาและระบบ aspect สำหรับ Java ที่พูดได้ว่า powerful ที่สุด ใน AspectJ 1.5 ที่เพิ่ง released
เมื่อต้นปีได้สนับสนุน Java 5 อย่างเต็มตัวทั้งในเทอมของภาษาและสถาปัตยกรรม
AspectJ 1.5 สนับสนุนการประกาศ pointcut สำหรับ annotation และทำงานร่วมกับ generic ได้
Java 5 อนุญาตให้ระบุ agent สำหรับเปลี่ยนแปลง bytecode ขณะ load class ขึ้นไปประมวลผล
และ AspectJ 1.5 ก็ใช้ความสามารถนี้ได้อย่างดี

Aspect Refactoring
แนวคิดในการสร้างและใช้ aop อยู่ที่พื้นฐานความเข้าใจในการแยก aspect ออกมาจาก object-oriented code ครับ
เราจะเห็นประโยชน์ของ aop ชัดขึ้นไปอีกระดับนึงตามตัวอย่างนี้ครับ
เมื่อ code ชุดนึง maintain ด้วยทีม A และเป็น production แล้ว
ทีม B ถูก set ขึ้นเพื่อแก้ปัญหาบางอย่างที่ต้องเพิ่มความสามารถให้ code หลัก
ทีม B เข้าถึง source code ได้แต่การ patch code ที่มีการกระจายตัวสูงทำให้ต้องแก้ไข code แทบทุกไฟล์ใน project
วิธีการที่ ทีม B สามารถทำได้ด้วย AOP ก็คือ เลือก code มาบางส่วน และเริ่มต้นพัฒนาด้วย OOP ก่อน เมื่อเห็นว่า code ทำงานได้แล้ว
ก็พิจารณาจุดตัด (joinpoint) และดึง code ส่วนที่เพิ่มเข้าไปใหม่เหล่านั้นออกมาเป็น aspect
จากนั้นก็ทดสอบสร้าง pointcut เพื่อให้ aspect ที่สร้างขึ้นสามารถสาน (weave) เข้าไปใน code ทั้งหมดได้
โดยการ test ควรทำด้วย static weaving (การสาน code ที่เปลี่ยนแปลง .class ตั้งแต่เวลา compile โปรแกรม)
เมื่อ test ระบบเรียบร้อยแล้ว และคาดหวังว่าระบบจะทำได้โดยไม่มีข้อผิดพลาดแล้ว ก็ให้แยก aspect ออกมาเป็น .jar ต่างหาก
และใช้ javaagent เป็นตัวทำ load-time weaving ขณะ runtime และ deploy ลง container
ด้วยแนวคิดจากตัวอย่างที่ผมยกขึ้นมาจะเห็นได้ชัดว่ามีการแบ่งความรับผิดชอบชัดเจนมาก
ขึ้นใน team นั่นคือ
ทีม A สามารถ maintain code หลักต่อไปได้ และ ทีม B เพิ่มความสามารถให้ระบบได้โดยที่ไม่ต้องไปทะเลาะกับทีม A
เช่นเมื่อระบบรวน ทีม B ก็สามารถยกเลิก aspect ได้โดยปิด javaagent และแยกได้ชัดเจนว่า bug ที่เกิดขึ้นเนื่องจากระบบเดิมหรือตัว aspect ใหม่

คิดว่าแนวทางที่ผมเขียนมานี้คงทำให้หลาย ๆ ท่านได้ idea ในการสร้าง aspect เองเพื่อใช้ในองค์กรนะครับ

จากคุณ cblue แห่ง narisa.com http://www.narisa.com/forums/index.php?showtopic=11868

Read More