ดาวน์โหลดงานนำเสนอ
งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ
1
Web Services
2
Introduction to Web Service
Web Service is XML and HTTP HTTP can go anywhere with Internet XML, standard language, easily to modify Example: PC read and send Serial Port for evaluation on UNIX พื้นฐานของ Web Service ก็คือ XML กับ HTTP ซึ่งจะพบว่า HTTP ก็เป็นที่รู้จักกันดี และไปได้ทั่วทุกแห่งที่มี internet ส่วน XML คือภาษาสากลที่คุณสามารถปรับแต่งได้ตามใจชอบ เพื่อให้เกิดกิจกรรมระว่าง client และบริการ หรือระหว่างส่วนประกอบต่างๆ เบื้องหลัง Web server ก็คือ ข้อความ XML จะถูกแปลงให้การขอบริการจาก Middle ware และผลที่ได้ก็จะแปลงกลับมาในรูป XML ยกตัวอย่างให้เห็นง่ายๆ คุณต้องการให้เครื่อง PC อ่านค่าจาก serial port แล้วส่งไปประมวลผลบนเครื่อง UNIX แล้วส่งผลกลับมาแสดงบนจอ PC ถ้าเป็นเมื่อก่อน คุณก็คงต้องแปลงข้อมูลที่ได้ให้อยู่ในรูปของ ASCII แล้วส่งไปยัง UNIX พร้อมคำสั่งว่าให้ทำอะไร ในฝั่ง UNIX คุณก็ต้องมาแยกว่าอันไหนคือคำสั่ง อันไหนคือข้อมูล เมื่อประมวลผลแล้ว จะส่งกลับมาในรูปแบบไหน แล้วถ้าหากจะส่งไปหาเครื่องที่เป็น MAC ท่านจะต้องเขียนโปรแกรมเพิ่มในส่วนไหนบ้าง จะพบว่าเราต้องพัฒนากันเป็นคู่ๆ ไป และต้องนิยามในแต่ละฝั่งให้ชัดเจน แต่หากเป็น Web Service คุณจะพบว่า เราแปลงข้อมูลให้อยู่ในรูป XML แต่ละคุณก็ต้องการรู้แค่ มาตรฐาน XML ก็พอ แล้วต่างคนต่างก็เขียน Service ของตัวเอง ไม่ต้องกังวลเรื่องของการเชื่อมโยงอีกต่อไป และ Protocol ที่ส่งก็คือ HTTP นั่นเอง ถ้าท่านเชื่อมโยงกับ HTTP (หรือเว็บ) ได้ ท่านก็ใช้บริการทุกอย่างได แต่เดี๋ยวก่อนการเข้าถึงและการสั่งงานนั้นยังเป็นเพียงโครงสร้างพื้นฐาน แต่ในความเป็นจริงยังมีอะไรมากกว่านั้น เช่น การค้นหา การทำธุรกรรม ความปลอดภัย การพิสูจน์ตัวตน และอื่นๆ อันเป็นบริการที่ทำให้เป็นบริการพื้นฐานจริงๆ ระบบเพิ่มเติมที่ต้องมีและต้องรักษาความสะดวกและใช้งานง่ายไว้ด้วย พื้นฐานของ Web Service เต็มรูปแบบคือ XML + HTTP + SOAP + WSDL + UDDI หรือในระดับสูงกว่านั้น แต่ไม่ได้ถือเป็นสิ่งจำเป็นเสมอไปคือต้องเพิ่มเทคโนโลยี XAML, XLANG, XKMS, XFS เป็นต้น ต่อไปนี้คือรายละเอียดคร่าวๆ ของแต่ละส่วน แต่ควรตระหนักว่าแต่ละส่วนอาจจะยังเป็นเทคโนโลยี ที่กำลังอยู่ระหว่างพัฒนา ดังนั้นในแต่ละปัญหาอาจจะแก้ได้หลายวิธีด้วยกัน SOAP (Remote Invocation) สั่งงานจากระยะไกล UDDI บริการ Directory WSDL ระบุคุณสมบัติของแต่ละบริการ XLANG/XAML กรณีของการเชื่อมโยงที่ซับซ้อน หลายๆ เว็บ XKMS (XML Key Management Specification) ระหว่างการพัฒนา (Microsoft + Verisign) รายละเอียด
3
ความปลอดภัยในการใช้งาน Web Services
เนื่องจากทำงานอยู่บน Internet ซึ่งปัจจุบันมีเทคโนโลยีในการรักษาความปลอดภัยมากมายรองรับอยู่แล้ว Web Services สามารถวิ่งผ่าน Firewall ได้เนื่องจาก SOAP ถูกส่งโดยผ่านโปรโตคอล HTTP ระบบรักษาความปลอดภัยตามมาตรฐานของ Authentication PKI (Public Key Infrastructure) เช่น MD5 (Message Digest), Authorization Username/Password Confidentiality HTTPS/SSL (Secure Socket Layer) PGP (Pretty Good Privacy)
4
เครื่องมือที่ใช้ในการพัฒนา Web Services
Microsoft: Microsoft .NET Framework Sun Microsystem: Sun ONE (Sun Open Net Environment) IBM: Web Services Toolkit Apache: AXIS เครื่องมืออื่นๆที่สนับสนุน SOAP, XML ทั้งที่เป็น Commercial Product และ Open Source
5
โครงสร้างของ Web services
Registry Find Public Service Requestor Service Provider Binding
6
UDDI UDDI ย่อมาจาก Universal Description, Discovery and Integration
นำเสนอโดยหลายบริษัทเช่น Ariba, Microsoft, IBM, etc. บอกให้ทราบว่าบริษัทมีผลิตภัณฑ์และบริการอะไรบ้าง สามารถติดต่อขอดำเนินธุรกิจการค้ากับบริษัทได้โดยอัตโนมัติโดยผ่านทาง Web Services มาตรฐานนี้ยังไม่สมบูรณ์ เวอร์ชั่นปัจจุบันคือ 3.0 Universal Description, Discovery and Integration Web Services search engine เป็นมาตรฐานในการค้นหาบริการ Web Services โดย UDDI เปรียบเสมือนฐานข้อมูลขนาดใหญ่ซึ่งมีข้อมูลของ Web Services ที่ผู้ให้บริการมาลงทะเบียนไว้ มาตรฐานนี้ยังไม่สมบูรณ์
7
UDDI Requirements The UDDI specification requires that the SOAP message be UTF-8 encoded. The elements within the body of the UDDI document must be scoped within the UDDI API namespace. The UDDI API namespace is identified by the urn:uddi-org:api URI. The request must contain a SOAPAction HTTP header whose value is an empty string. Any other value will be considered an error. The version of the targeted API must be stated within the body of the message using the generic attribute.
8
Publishing Services The Publication API defined in the specification allows a user (or system) to publish information to a UDDI compatible registry and, in the process, generate and assign a key. Several important new facets of the publication process reflect new registry interaction concepts. These include: Generation and assignment of registry keys Rules and namespaces for managing unique and non-unique record keys Defining the roles of root and affiliate registries Updating or deleting an existing entity
9
Subscribing to Services
The Subscription API defined in the specification allows a user (or system) to monitor the creation, deletion, and changes made to services in a registry. Several new features defined in this version of the specification help support the “peering” or sharing of records among registries. These include: Notification of newly registered businesses or services Changes to existing businesses or services Obtaining registry data for use in a private UDDI registry Obtaining registry data for use by a registrar
10
Representing Information within UDDI
businessEntity representing Businesses and Providers businessService representing Services bindingTemplate representing Web services Technical Models (tModels) Taxonomic Classification of the UDDI entities
11
businessEntity As the top-level entity, businessEntity can be used to model any "parent" service provider, such as a department, an application or even a server. Depending on the context of the data in the entire registry, the appropriate modeling decisions to represent different service providers can vary.
12
businessService Each businessService is the logical child of a single businessEntity. Each businessService contains descriptive information – again, names, descriptions and classification information -- outlining the purpose of the individual Web services found within it.
13
bindingTemplate Each bindingTemplate structure represents an individual Web service. In contrast with the businessService and businessEntity structures, which are oriented toward auxiliary information about providers and services, a bindingTemplate provides the technical information needed by applications to bind and interact with the Web service being described. It must contain either the access point for a given service or an indirection mechanism that will lead one to the access point.
14
Technical Models Technical Models, or tModels for short, are used in UDDI to represent unique concepts or constructs. They provide a structure that allows re-use and, thus, standardization within a software framework. The UDDI information model is based on this notion of shared specifications and uses tModels to engender this behavior. For this reason, tModels exist outside the parent-child containment relationships between the businessEntity, businessService and bindingTemplate structures.
15
Taxonomic Classification of the UDDI entities
It allows users to define multiple taxonomies that can be used in UDDI. In such a way, multiple classification schemes can be overlaid on a single UDDI entity. This capability allows organizations to extend the set of such systems UDDI registries support. UDDI allows such classification systems to be used on every entity within the information model. It defines a consistent way for a publisher to add any number of classifications to their registrations. It is important that taxonomies are used when publishing data into a UDDI registry. Whether standard codes are used (such as the United Nations Standard Products and Services Code System (UNSPSC)) or a new taxonomy is created and distributed, it is imperative that UDDI data -- businessEntity, businessService, bindingTemplate and tModel elements alike – are attributed with metadata.
16
The UDDI Inquiry API set provides the ability to issue precise searches based on the different classification schemes. A range of queries that perform different joins across the UDDI entities can be generated, such that data can be discovered and accessed. Also, registering information such as industry codes, product codes, geography codes and business identification codes allows other search services to use this classification information as a starting point to provide added-value indexing and classification.
17
UDDI Resources UDDI.org http://www.uddi.org/ UDDI Specification V3
UDDI Use Case Scenarios The Stencil Group, “Why UDDI Will Succeed, Quietly”
18
WSDL WSDL ย่อมาจาก Web Services Description Language
WSDL เขียนขึ้นตามแบบมาตรฐาน XML อธิบายรูปแบบและลักษณะของข้อมูลที่รับส่งกันระหว่างผู้ให้บริการและผู้ร้องขอ Web Services Description Language ภาษาที่ใช้ในการอธิบาย Web services เป็น XML ที่ใช้สำหรับอธิบายบริการที่ให้บริการ(Services) และกลุ่มปฎิบัติการ(Operations)ภายในบริการแต่ละตัว อธิบายรูปแบบและลักษณะของข้อมูลที่รับส่งกันระหว่างผู้ให้บริการและผู้ร้องขอ Operation ใน WSDL สามารถอยู่ในรูปเอกสาร (document oriented) หรือ RPC (remote procedure call oriented)
19
Anatomy of WSDL The root of a WSDL document is the definitions element. Within this element are five types of child elements: types Contains the schema definitions of the messages that can be sent and received by the service. The most common way of representing the schema is using XML Schema. message Serves as a cross-reference that associates the message with its definition within the schema.
20
portType binding service
Defines a set of interfaces that the Web service can expose. An interface is associated with one or more messages. binding Associates the portType definition with a particular protocol. service Defines a collection of related endpoints (ports) exposed by the Web service.
21
definitions Element The root element in a WSDL document, the definitions element, serves much the same role as the schema element in an XML Schema document. It contains child elements that define a particular service Much like an XML Schema document, a WSDL document can define its own namespace by adding a targetNamespace attribute to the definitions element. The only restriction is that the value of the targetNamespace attribute cannot contain a relative URI.
22
types Element The types element contains schema information referenced within the WSDL document. The default type system supported by WSDL is XML Schema. If XML Schema is used to define the types contained within the types element, the schema element will appear as an immediate child element. You can use other type systems by extension. If you use another type system, an extensibility element can appear under the types element. The name of the element should identify the type system used.
23
message Element The message element provides a common abstraction for messages passed between theclient and the server. Because you can use multiple schema- definition formats within a WSDL document, it is necessary to have a common way of identifying the messages. The message element provides this common level of abstraction that will be referenced in other parts of the WSDL document. Multiple message elements can and often do appear in a WSDL document, one for each message being communicated between the client and the server. Each message contains one or more part elements that describe pieces of content within the message. An example of a part is the body of a SOAP message or a parameter contained within the query string, a parameter encoded in the body of a SOAP message, or the entire body of a SOAP message.
24
portType Element The portType element contains a set of abstract operations representing the types of correspondences that can occur between the client and the server. For RPC-style Web services, a portType can be thought of as an interface definition in which each method can be defined as an operation. A port type is composed of a set of operation elements that define a particular action. The operation elements are composed of the messages defined within the WSDL document.
25
WSDL defines four types of operations, known as operation types:
Request-response RPC-style communication in which the client makes a request and the server issues a corresponding response. One-way Document-style communication in which the client sends a message but does not receive a response from the server indicating the result of the processed message. Solicit-response The opposite of the request-response operation. The server sends a request, and the client sends back a response. Notification The opposite of the one-
26
binding Element The binding element contains binding definitions for binding a protocol such as SOAP to a particular bindingType. The binding definitions specify message formatting and protocol details. For example, the binding information specifies whether you can access an instance of a portType in an RPC-like manner. The binding definitions also indicate the number of network communications required to perform a particular action. For example, a SOAP RPC call over HTTP might involve one HTTP communication exchange, but that same call over SMTP would involve two discrete SMTP communication exchanges.
27
service Element A service is a group of related ports and is defined by the service element. A port is a particular endpoint for the Web service that is referenced by a single address. Ports defined within a particular service are orthogonal. For example, the output of one port cannot serve as the input of another.
28
Name Parameter Mehod Listener
29
Simple Object Access Protocol
30
การกำเนิดของ SOAP Simple Object Access Protocol
เป็นมาตรฐานของเทคโนโลยี Distributed Objects แบบหนึ่ง ส่งข้อมูลผ่าน Internet/Web ในรูปแบบของ XML ง่ายในการใช้งานด้วย Request/Response HTTP Protocol เป็น XML-based protocol สำหรับการแลกเปลี่ยนข้อมูล decentralized, distributed environment กำหนดเมเสจจิ้งโปรโตคอล ระหว่างผู้ขอบริการ (requester) กับผู้ให้บริการ (provider) สามารถทำงานได้ทุกแพลตฟอร์ม ถูกกำหนดเป็น Services-Oriented Architecture Protocol
31
การให้บริการของ SOAP SOAP – an XML-based protocol ที่ทำให้เรียกโปรแกรมผ่านทาง HTTP/Web Server ได้ Remote Procedure Call ผ่านทาง Web ทำให้เกิดเรียกใช้โปรแกรม (Software Components) ข้ามระบบได้ Web Consortium (W3C) Support
32
SOAP Advantage It is not tightly coupled to one language. Developers involved with new projects can choose to develop in today’s latest and greatest programming language. But developers who are responsible for maintaining legacy applications might not have a choice about the programming language they use. SOAP does not specify an API, so the implementation of the API is left up to the programming language and the platform. It is not tightly coupled to a particular transport protocol. The SOAP specification does describe how SOAP messages should be bound to HTTP. But a SOAP message is nothing more than an XML document, so it can be transported over any protocol that is capable of transmitting text.
33
It is not tied to any one distributed object infrastructure
It is not tied to any one distributed object infrastructure. Most distributed object systems can be extended (and some of them are) to support SOAP. It leverages existing industry standards. The primary contributors to the SOAP specification intentionally avoided reinventing anything. They opted to extend existing standards to meet their needs. It enables interoperability across multiple environments. SOAP was built on top of existing industry standards, so applications running on platforms that support these standards can effectively communicate via SOAP messages with applications running on other platforms.
34
Anatomy of SOAP An envelope that defines what is in the message, what should work with it, and whether it is optional or mandatory. The header as an optional and generic mechanism for adding features to SOAP messages. The body is the container for the mandatory information, that is, the data payload that is being transferred. Within the body, only the Fault element is defined by SOAP.
35
Encoding rules based on a simple system – generalization of the common features found in type systems in most programming languages, databases, and semi–structured data. RPC representation, that is nothing more than a convention used to represent remote procedure calls and responses.
36
SOAP Envelope The envelope is a mandatory top-level element in a SOAP message. Attributes within the envelope, as well as elements, when present, have to be identified by a namespace. The <SOAP-ENV:Envelope> element can contain two elements as its immediate children: the optional <SOAP-ENV:Header> element, and the <SOAP-ENV:Body> element. Any other immediate children elements have to come after the <SOAP-ENV:Body> element.
37
SOAP Header The <SOAP-ENV:Header> element is an optional element, but when present, it has to be the first immediate child of the <SOAP-ENV:Envelope> element and it has to come before the <SOAPENV:Body> element. This element may contain attributes and elements within, and they have to be namespace identified. The SOAP specification defines two attributes : SOAPENV: mustUnderstand This attribute can have a value of "1" or "0" (default). A value of "1" indicates that the recipient of the message must understand all of the attributes provided in the header and if not, it is required to return an error message and not process the message.
38
SOAP-ENV:actor This attribute specifies a SOAP intermediary in situations where the SOAP message may travel from the original sender to the ultimate destination via a set of SOAP intermediaries. A SOAP intermediary is an application that could process SOAP messages and then be able to route them further, analogous but not the same as routers on the Internet that forward TCP/IP packets. When this attribute is omitted, the SOAP message's ultimate recipient is the first recipient.
39
SOAP Body The <SOAP-ENV:Body> element contains the payload of the SOAP message. Depending on the type of communication that is occurring, the Body element can contain the RPC call or response, error message, or other one–way SOAP messages. The example below shows a SOAP message that carries a payload of a RPC call to a web service. The immediate child elements of the <SOAP-ENV:Body> element are called body entries. These elements can be namespace qualified. Only one of these body entries is an element that is defined by the SOAP specification and that is the <SOAP-ENV:Fault> element
41
SOAP Fault The Purpose of the <SOAP-ENV:Fault> element is to carry error or status information within a SOAP message. This element, when present, must appear only once and must be within the Body element. The <SOAP-ENV:Fault> element has four sub-elements defined by the SOAP specification; more can be added by qualifying them with a user-defined namespace, if needed.
42
The <faultcode> element is intended to provide information to the software about the error type. This element must be present in a <SOAP-ENV:Fault> element. SOAP defines only four fault code values: SOAP-ENV:VersionMismatch (invalid namespace likely) SOAP-ENV:MustUnderstand (the SOAP-ENV:mustUnderstand element within the SOAP header could not be satisfied) Client (error in the message sent by the client, should be resubmitted only once corrected) SOAP-ENV:Server (error at the server in the processing of a message) This list is extensible with a "." notation, for example: Client.Authentication.
43
The <faultstring> element provides human readable information about the error. This element must be present when a <SOAP-ENV:Fault> element is being sent. The <faultactor> element is an optional element that provides information about the system that caused the error. It is particularly useful when SOAP intermediary systems are present.
44
The <detail> element is for carrying application-specific error information related to the <SOAP-ENV:Body> element. It must be present if the content of the message in the body cannot be processed successfully (in other words, <faultcode> is of the type SOAPENV: Server). Header detail information, however, must be carried within the header entries. The absence of the detail element indicates that the fault is not related to processing of the <SOAP-ENV:Body> element – useful for troubleshooting. All immediate elements to the detail element are called detail entries.
45
สถาปัตยกรรมของ SOAP
46
JDK Apache Jakarta Tomcat 5.5.9 Apache AXIS
การติดตั้งโปรแกรม JDK Apache Jakarta Tomcat 5.5.9 Apache AXIS
47
JDK
58
Apache Jakarta Tomcat 5.5.9
59
1. ทำการติดตั้ง JDK 1.5 ลงในเครื่องของคุณ ในที่นี้สมมติว่าได้ทำการติดตั้ง JDK 1.5 ที่ C:\Program Files\Java\jdk1.5.0 2. ทำการติดตั้ง Tomcat ซึ่งมีขั้นตอนดังต่อไปนี้ 2.1 download โปรแกรม jakarta-tomcat zip จาก class Web site หรือจาก 2.2 แตกไฟล์ zip ที่ download มาไปไว้ในโฟลเดอร์ที่ต้องการ ในที่นี้สมมติว่าเป็น C:\jakarta-tomcat-5.5.9
60
2.3 กำหนดค่า “Environment Variables” ที่ชื่อ JAVA_HOME ตามขั้นตอนดังต่อไปนี้
2.3.1 Click ขวา ที่ “My Computer” แล้วเลือก “Properties” หรือ เปิด “Control Panel” แล้วเลือก “System” ซึ่งจะได้ผลลัพธ์ดังรูปนี้
62
2.3.2 Click ปุ่ม “Environment Variables” ที่ tab “Advanced” ซึ่งจะได้ผลลัพธ์ดังรูปต่อไปนี้
63
2.3.3 ทำการเพิ่ม Variable ที่ชื่อ JAVA_HOME (ถ้ายังไม่มี) เข้าไป โดย Click ที่ “New” ซึ่งจะได้ dialog box ดังรูปข้างล่าง แล้วใส่ JAVA_HOME ที่ช่อง “Variable name” ส่วนในช่อง “Variable value” ให้ใส่ตำแหน่งทที่คุณได้ติดตั้ง JDK ลงไป ซึ่งในที่นี้ก็คือ C:\Program Files\Java\jdk1.5.0
64
2. 4 ทำการแก้ไขไฟล์ server. xml ในโฟลเดอร์ C:\jakarta-tomcat-5. 5
2.4 ทำการแก้ไขไฟล์ server.xml ในโฟลเดอร์ C:\jakarta-tomcat-5.5.9\conf\ โดยการเปลี่ยน port ที่เป็น attribute ของ Connector จาก 8080 เป็น 80
65
2. 5 ทำการแก้ไขไฟล์ context. xml ในโฟลเดอร์ C:\jakarta-tomcat-5. 5
2.5 ทำการแก้ไขไฟล์ context.xml ในโฟลเดอร์ C:\jakarta-tomcat-5.5.9\conf\ โดยการเปลี่ยน <Context> เป็น <Context reloadable="true">
66
2. 6 ทำการแก้ไขไฟล์ web. xml ในโฟลเดอร์ C:\jakarta-tomcat-5. 5
2.6 ทำการแก้ไขไฟล์ web.xml ในโฟลเดอร์ C:\jakarta-tomcat-5.5.9\conf\ โดยการลบคอมเมนต์จำนวน 2 แห่งที่ invoker servlet ออก
67
3 สร้าง Shortcut เพื่ออำนวยความสะดวกในการใช้ Tomcat
3.1 ใช้ Windows Explorer เปิดโฟลเดอร์ C:\jakarta-tomcat-5.5.9\bin ของ Tomcat ขึ้นมา
69
3. 2 Click ขวา ที่ไฟล์ startup
3.2 Click ขวา ที่ไฟล์ startup.bat เลือก Copy หลังจากนั้นย้าย Mouse ไปวางบนบนหน้าจอ Desktop แล้ว Click ขวา และเลือก Paste Shortcut ก็จะได้ Shortcut สำหรับเรียกใช้งาน Tomcat. 3.3 สร้าง Shortcut สำหรับหยุดการทำงานของ Tomcat โดยทำในทำนองเดียวกันกับข้อ 3.2 แต่กระทำกับไฟล์ shutdown.bat แทน
70
4 ทดสอบการติดตั้ง Tomcat โดย Double Click ที่ Shortcut ของไฟล์ startup
4 ทดสอบการติดตั้ง Tomcat โดย Double Click ที่ Shortcut ของไฟล์ startup.bat ที่สร้างไว้ตามข้อ 3 ก็จะเกิดหน้าต่าง Command Prompt ขึ้นมา แต่อย่าปิดหน้าต่างนี้ (หน้าต่างนี้จะหายไปเองเมื่อคุณหยุดการทำงานของ Tomcat โดยการ Double Click ที่ Shortcut ของไฟล์ shutdown.bat ที่สร้างไว้ตามข้อ 3) หลังจากนั้นให้เปิดโปรแกรม Browser ขึ้นมา แล้วพิมพ์ หรือ ลงในช่อง address แล้วกดปุ่ม enter หากติดตั้งสำเร็จ หน้าต้อนรับของ Tomcat ก็จะปรากฏขึ้นมาดังรูปข้างล่างนี้
72
Apache AXIS
73
Installation (Required)
Axis 1.4 ที่ ขยายไฟล์ออกแล้ววางไว้ที่ C:\ เข้าไปในโฟลเดอร์ Webapps คัดลอกโฟลเดอร์ axis ไปวางไว้ที่ %CATALINA_HOME%\webapps\ Activation.jar ที่ จะได้ไฟล์ jaf-1_1-fr.zip ขยายไฟล์ออกแล้วใช้ไฟล์ activation.jar Mail.jar ที่ จะได้ไฟล์ javamail-1_4.zip ขยายไฟล์ออกใช้ไฟล์ mail.jar Xmlsec.jar ที่ จะได้ไฟล์ xml-security-bin-1_4_0.zip ขยายไฟล์ออกใช้ไฟล์ xmlsec jar
74
Installation (Optional)
xml-apis.jar, xercesImpl.jar ที่ จะได้ไฟล์ Xerces-J-bin zip จากนั้นให้ขยายไฟล์ออกมาแล้วใช้ไลบรารี่ xml-apis.jar, xercesImpl.jar
75
Set CLASSPATH set AXIS_HOME=(โฟลเดอร์ที่ทำการขยาย axis)
set AXIS_LIB=%AXIS_HOME%\lib set AXISCLASSPATH=%AXIS_LIB%\wsdl4j jar;%AXIS_LIB%\saaj.jar; %AXIS_LIB%\axis.jar;%AXIS_LIB%\axis-ant.jar; %AXIS_LIB%\commons-discovery-0.2.jar; %AXIS_LIB%\commons-logging jar; %AXIS_LIB%\jaxrpc.jar;%AXIS_LIB%\log4j jar set CLASSPATH=.;%JAVA_HOME%\lib\tools.jar; %AXISCLASSPATH%
76
Test modules Start tomcat
77
Test Web Services
78
Test WSDL
งานนำเสนอที่คล้ายกัน
