WebServices the New Era

Size: px

Start display at page:

Download "WebServices the New Era"

Rudolph Young
6 years ago
Views:

1 WebServices the New Era Introduction to WebServices Standards of WebServices Component Architecture WebServices Architecture SOAP WSDL UDDI Tools and Technologies of WebServices An example of WebServices WebServices Security Conclusion Reference Author

2 What is a WebServices? A Web service is an application service (i.e. a network accessible function) that can be accessed using standard Web protocols. Web Services are software components that are loosely coupled and distributed, encapsulate business functionality and are programmatically accessible using standard Internet protocols. Web services are loosely coupled software components delivered over standard Internet technologies. Cross-platform interoperability (integration) Web Services allow business processes or functionality residing on completely different systems and unknown to each other to communicate in a standard way. Coarse grained functions

3 Web Services are coarse grained in that they are usually mapped to business level processes as opposed to low level data or API functions. Loose coupling Applications are developed independent of who accesses them and are exposed to other applications only through pre-defined interfaces (WSDL files). This means that the underlying implementations can be changed without changing the service requesting application. Introduction to WebServices Web services are somewhere around the crest of their hype cycle and currently the darling of the prevalent media. This cresting is like that of other technologies in that it precedes full development and maturity. Web services, an undoubtedly important technology regardless of media interest, have a good deal of development ahead of them. Those who find success using Web services will be those who understand the technology fundamentally: its motivations, the reasons why some components are winning out over others, and the likely course of maturity. For this reason, I start with the history of Web services. This is no mere nostalgic sidetrip: the business and technical environment into which Web services was conceived, and the various players that have waxed and waned in prominence in their history to date are likely to have a strong effect on the future of Web services. Distributed application Distributed application development has been an important field ever since typical computing moved from encapsulated jobs on centralized mainframe computers to peernetworked minicomputers and workstations. As this developed, the IT manager was still usually master of all he or she surveyed. The strategic concerns of distributed development were confined to whatever issues allowed the IT manager to accept the necessary inputs and deliver the necessary reports to management. Keeping an wellintegrated data center was key, and supporting heterogeneous platforms and environments not so important. The areas where such things were important say the electronic data interchange (EDI) shop were usually completely separate entities within the organization. The new generation of distributed computing was based on information-systems needs and experience with network technologies to date. The prevalent needs are: Suitability both for distributed operation within an application, and the use of generic services across applications. In other words: the ability to support both software developers and systems integrators.

4 Suitability for exchanges within an organization and between organizations, requiring cross-platform support and a data-driven focus. Concordance with existing Internet infrastructure as much as possible. Ability to scale as the number of nodes, heterogeneity of nodes and the complexity of each node's need increase. Solid internationalization. Tolerance of failure. Networks where nodes are very tightly coupled together often suffer catastrophic failure when one node goes down. This is a serious problem for heterogeneous networks. Strong support in general software development and business workflow management tools from a rich choice of vendors. Suitability for the most trivial request/response exchanges as well as handling the most sophisticated orchestration, transaction and security concerns where necessary. Standards of WebServices: Major Web services standards groups are listed below: W3C (World Wide Web Consortium) The driving force behind the largest number of highly adopted standards in the Web services space including some Web building blocks such as HTML. OASIS Source of the original specification from which XML evolved, as well as the home of the current XML and Universal Description, Discovery and Integration (UDDI) specification. WS-I (Web Services Interoperability Organization) Acts as a watchdog group to ensure interoperability between implementations of Web services standards Component Architecture The adaptability of the J2EE environment lies in the fact that it marks the realization of a long-standing ideal of software architects: a server based component architecture. Unlike earlier systems, a J2EE-based application is Web application server Internet Web server browser clients built in components, which can be independently added, removed or updated with minimal disruption to the system as a whole.

5 Specialization of Functionality A result of the component-based architecture is the ability to develop "chunks" of code dedicated to specific functions, which implemented properly could run on the same application server and efficiently interact with other "chunks" of code dedicated to other functions. Standards-based Communications Unlike first-generation client-server applications, second-generation Internet-based applications had to communicate through a "cloud," called the Internet. This was only possible through standards at every level including networking (TCP/IP, HTTP), presentation (HTML), security (HTTPS, digital certificates), application logic (Java, JavaScript, CGI), etc. Distributed Execution Internet standards enabled applications to run "on both sides of the cloud." The "pieces" of the application could run where it made the most sense for them to run. For example, while business logic ran on the server side, the server might download some presentation logic to the client in the form of JavaScript, style sheets, cookies and Java Server Pages (JSPs). The rapid adoption of the J2EE-based design for Web application servers was due not just to these features, but rather to the benefits they promised. Among the benefits of the J2EE environments are: Reliability The Java Virtual Machine (JVM) model provided a unique "sandbox" for each application, so the failure or corruption of an application wouldn t interrupt the system as a whole. Portability Another advantage of the JVM was that developers wrote programs for the virtual machine itself an application rather than custom-developing applications for specific hardware and operating system platforms. Developer Efficiency Java components, called "beans," promised developers a faster development process, including the re-use of components across multiple applications. Scalability Because a Java program runs in a virtual machine, it becomes a "program within a program" placing a greater burden on the computer. The J2EE environment was designed to maximize the scalability of the environment in which the Java program executed. Internationalization Unlike earlier programming languages such as C and C++, Java supported the Unicode code set, assuring support for any natural language, including multi-byte languages such as Japanese. Database Connectivity The API for Java Database Connectivity (JDBC) enabled Java applications to execute SQL statements, facilitating seamless integration with new or existing database structures.

6 Web Services Architecture In most Internet middle ware configurations, the three core functional components (transport, description, and discovery) in the Web Services Architecture (WSA) are implemented using SOAP, WSDL, and UDDI, respectively. A UDDI registry plays the role of service broker. The register and find operations are implemented using the UDDI Inquiry and UDDI Publish APIs. A WSDL document describes the service contract, and is used to bind the client to the service. The Web service protocol stack is a set of protocols used to define, discover, and implement Web services. The core protocol stack consists of four layers: Service Transport: This layer is responsible for transporting messages between applications. Currently, this includes HTTP, SMTP, FTP, and newer protocols, such as Blocks Extensible Exchange Protocol (BEEP). XML Messaging: This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this includes XML-RPC and SOAP. Service Description: This layer is responsible for describing the public interface to a specific Web service. Currently, service description is handled via the WSDL. Service Discovery: This layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality. Currently, service discovery is handled via the UDDI. Simple Object Access Protocol Simple Object Access Protocol (SOAP) is a lightweight, XML-based protocol for exchanging information in a decentralized, distributed environment. SOAP is just a communications protocol. It became clear pretty early on that there would be significant value in a standardized form for Web services meta data, that is, the information that informs the processing of Web services SOAP consists of four parts: SOAP Envelope. SOAP Body SOAP Transport Binding Framework. --SMTP, JMS and others. SOAP Serialization Framework

7 An envelope that defines a framework for describing what is in a message and how to process it. A set of encoding rules for expressing instances of application-defined data types, a convention for representing remote procedure calls and responses, binding convention for exchanging messages using an underlying protocol. Potentially, SOAP can be used in combination with a variety of other protocols, such as HTTP, SMTP. Sample SOAP Request Envelope: <SOAP-ENV: Envelope xmlns: SOAP-ENV = " SOAP-ENV: encodingstyle=" <SOAP-ENV: Body> <m: GetLastTradePrice xmlns:m="some-uri"> <symbol>dis</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV: Envelope> Sample SOAP Response Envelope: <SOAP-ENV: Envelope xmlns: SOAP-ENV = " SOAP-ENV: encodingstyle=" <SOAP-ENV: Body> <m: GetLastTradePriceResponse xmlns:m="some-uri"> <Price>34.5</Price> </m: GetLastTradePriceResponse> </SOAP-ENV: Body> </SOAP-ENV: Envelope> Sample SOAP body: <SOAP-ENV: Body> <m: GetLastTradePriceDetailed xmlns:m="some-uri"> <Symbol>DEF</Symbol> <Company>DEF Corp</Company> <Price>34.1</Price> </m: GetLastTradePriceDetailed>

8 </SOAP-ENV: Body> Web Services Description Language Web Services Description Language (WSDL) is an XML-based specification schema for describing a Web Service s interface along with endpoint access information, such as the network protocol for access, the accepted message formats, and how to reach the service. Conceptually, a WSDL document is composed of two parts. One part provides the service interface definition and the second part defines the service implementation definition. WSDL defines XML grammar for describing contracts between a set of endpoints exchanging messages. A typical WSDL document contains the following elements: Types: XML types corresponding to the various arguments and return types Message: Abstract typed definition of the data being exchanged Operation: Abstract description of a operation supported by a service Port Type: Collection of operations supported by one or more endpoints Binding: Concrete protocol and data format specification for a particular port type Port: Single endpoint defined as a combination of a binding and network address Service: Collection of related endpoints Universal Discovery Description and Integration Universal Discovery Description and Integration (UDDI) is a specification for a distributed, Web-based information registry of Web Services. These registries are publicly accessible and currently support service type registration for software companies, individual developers, standards bodies, and business registration types for describing company-supported services. UDDI includes the shared operation of a business registry on the Web. For the most part, programs and programmers use the UDDI Business Registry to locate information about services and, in the case of programmers, to prepare systems that are compatible with advertised Web Services or to describe their own Web Services for others to call. The UDDI Business Registry can be used at a business level to check whether a given partner has a particular Web Services interface. In addition, it can be used to find companies in a given industry with a given type of service, and locate information about how a partner or intended partner has exposed a Web Service. From this information, developers gain the technical details required to interact with a specific service.

9 From a J2EE developer s perspective, a UDDI registry is simply a repository containing specific and associated Web Services information, like Java Naming and Directory Interface (JNDI) (usually from a WSDL file), but not the actual Web Service itself. J2EE developers primarily use a UDDI registry to locate services information, prepare systems for Web Services compatibility, and to describe their own Web Services. Tools and Technologies of WebServices The tools and technologies used to develop WebServices are Technology J2EE Microsoft Programming Language Java C# Transport SOAP, ebxml, others SOAP,DCOM Just-in-time compiler Java Virtual Machine Common Language Application Server IBM Websphere, BEA Weblogic, iplanet and many more Microsoft Windows/IIS/COM+ Database Access API JDBC,EJB Entity Beans ADO.NET JAVA technologies for WebServices development: JAX-RPC: JAX-RPC is for Web services interoperability across heterogeneous platforms and languages. This makes JAX-RPC a key technology for Web services integration. The standard JAX-RPC programming model is used to develop Web service clients and endpoints based on SOAP. A Web service endpoint is described using a Web Services Description Language (WSDL) document. JAX-RPC enables JAX-RPC clients to invoke Web services developed across heterogeneous platforms. JAX-RPC provides an easy to develop programming model for development of SOAP based Web services. You can use the RPC programming model to develop Web service clients and endpoints. JAX-RPC provides support for WSDL-to-Java and Java-to-WSDL mapping as part of the development of Web service clients and endpoints. In a typical development environment, tools provide these mapping functionality. This further simplifies the application development. Java API for XML Binding (JAXB)

10 The Java Architecture for XML Binding (JAXB) provides a fast and convenient way to bind XML schemas to Java representations, making it easy for Java developers to incorporate XML data and processing functions in Java applications. As part of this process, JAXB provides methods for unmarshalling XML instance documents into Java content trees, and then marshalling Java content trees back into XML instance documents. Java WSDP Registry Server A registry offers a mechanism for humans or software applications to advertise and discover Web services. The Java Web Services Developer Pack (Java WSDP) Registry Server implements Version 2 of the Universal Description, Discovery and Integration (UDDI) project to provide a UDDI registry for Web services in a private environment. You can use it with the Java WSDP APIs as a test registry for Web services application development. Java XML Digital Signature API The Java XML Digital Signature API is a standard Java API for generating and validating XML Signatures Java API for XML Registries (JAXR) The Java API for XML Registries (JAXR) provides a uniform and standard Java API for accessing different kinds of XML Registries. An XML registry is an enabling infrastructure for building, deploying, and discovering Web services. JAXR enables Java software programmers to use a single, easy-to-use abstraction API to access a variety of XML registries. JAXR describes content and metadata within XML registries. JAXR provides rich metadata capabilities for classification and association, as well as rich query capabilities. The current version of the JAXR specification includes detailed bindings between the JAXR information model and both the ebxml Registry and the UDDI Registry v2.0 specifications. Web Services Security Model Most of the XML -based security standards are still evolving. Initial Web Services implementations used by clients within an organization and rely on the security model supported with HTTP. The passwords can be encoded using Base64 encoding for some level of protection. HTTP Security (HTTPS) can also be used when the Service Providers require more privacy. Digital signatures are used in implementing security in WebServices. An example of WebServices Stock Quote Request XML:

11 <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Body> <m:getlasttradeprice xmlns:m="some-uri"> <symbol>ctsh</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Stock Quote Response XML: <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Body> <m:getlasttradepriceresponse xmlns:m="some-uri"> <Price>34.5</Price> </m:getlasttradepriceresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Conclusion This paper provided you the details about the WebServices and component architecture, benefits of WebServices and how WebServices works. Reference Author

12 Baba Shaik IT consultant

(9A05803) WEB SERVICES (ELECTIVE - III)

1 UNIT III (9A05803) WEB SERVICES (ELECTIVE - III) Web services Architecture: web services architecture and its characteristics, core building blocks of web services, standards and technologies available