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 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)
เครื่องมือที่ใช้ในการพัฒนา Web Services 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
โครงสร้างของ Web services Service Registry Service Requesto r Service Provider Public Binding Find
UDDI UDDI ย่อมาจาก Universal Description, Discovery and Integration นำเสนอโดยหลายบริษัทเช่น Ariba, Microsoft, IBM, etc. บอกให้ทราบว่าบริษัทมีผลิตภัณฑ์และบริการอะไรบ้าง สามารถติดต่อขอดำเนินธุรกิจการค้ากับบริษัทได้โดย อัตโนมัติโดยผ่านทาง Web Services มาตรฐานนี้ยังไม่สมบูรณ์ เวอร์ชั่นปัจจุบันคือ 3.0
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.
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
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
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
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.
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.
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.
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.
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.
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.
UDDI Resources UDDI.org –http://www.uddi.org/ UDDI Specification V3 –http://www.uddi.org/specification.html UDDI Use Case Scenarios –http://www.uddi.org/ The Stencil Group, “Why UDDI Will Succeed, Quietly” –http://www.stencilgroup.com/ideas_scope_20 0104uddi.html
WSDL WSDL ย่อมาจาก Web Services Description Language WSDL คือคู่มือให้กับระบบ เพื่อเรียนรู้วิธีการ เรียกใช้งาน Web Services ที่ต้องการ WSDL เขียนขึ้นตามแบบมาตรฐาน XML อธิบายรูปแบบและลักษณะของข้อมูลที่รับส่งกัน ระหว่างผู้ให้บริการและผู้ร้องขอ
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.
–portType 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.
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.
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.
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.
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.
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-
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.
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.
การให้บริการของ SOAP SOAP – an XML-based protocol ที่ทำให้ เรียกโปรแกรมผ่านทาง HTTP/Web Server ได้ Remote Procedure Call ผ่านทาง Web ทำให้เกิดเรียกใช้โปรแกรม (Software Components) ข้ามระบบได้ Web Consortium (W3C) Support
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.
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.
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.
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.
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 element can contain two elements as its immediate children: the optional element, and the element. Any other immediate children elements have to come after the element.
SOAP Header The element is an optional element, but when present, it has to be the first immediate child of the element and it has to come before the 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.
–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.
SOAP Body The 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 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 element
SOAP Fault The Purpose of the 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 element has four sub-elements defined by the SOAP specification; more can be added by qualifying them with a user-defined namespace, if needed.
The element is intended to provide information to the software about the error type. This element must be present in a 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.
The element provides human readable information about the error. This element must be present when a element is being sent. The 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.
The element is for carrying application- specific error information related to the element. It must be present if the content of the message in the body cannot be processed successfully (in other words, 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 element – useful for troubleshooting. All immediate elements to the detail element are called detail entries.
Set CLASSPATH set AXIS_HOME=( โฟลเดอร์ที่ทำการขยาย axis) set AXIS_LIB=%AXIS_HOME%\lib set AXISCLASSPATH=%AXIS_LIB%\wsdl4j- 1.5.1.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- 1.0.4.jar; %AXIS_LIB%\jaxrpc.jar;%AXIS_LIB%\log4j- 1.2.8.jar set CLASSPATH=.;%JAVA_HOME%\lib\tools.jar ; %AXISCLASSPATH%
Test modules Start tomcat http://localhost:8080/axis/happyaxis.jsp
Test Web Services http://localhost:8080/axis/services/Version ?method=getVersion
Test WSDL http://localhost:8080/axis/services/Version?W SDL