Web Technologies - Report Example

Running Head: Web Technologies WEB SERVICES Name of institution: Course title: Course code: Student Name: Date of submission: Web Services Web services is a description of how web applications can be incooperated to work together Web-based applications using xml, soap, wsdl and uddi freeware standards set over the world wide websites. In the cases provided, XML is applied in tagging given data details, SOAP comes in when transferring the given details, the description of services offered, wsdl is applied and listing of the available services is done by uddi. Web services are also used to exchange information amongst themselves and information sharing between companies without interactions. This anchors well for the businesses and the customers involved. Web services can also be described as a link between an architecture which has to do much with services. , in this situation, applications on the web are able to link with other site applications which use free standards. These freely used standards include the X-markup language which runs over the Hypertext protocol, UDDI and SOAP. The operation of these applications is silent, that is, there’s communication from one server to another server. These set standards have only been attained by Microsoft.NET and J2EE. In addition to the above, web services can also be described as a collection of set requirements that enable exchange of information electronically and independent PC platforms of communication. Conclusively, a web service is a given internet service offered in www. We have numerous APIs that are provided in the www. Web service can also be found in technical magazines to mean any information on the Web-site. Web services are an emerging/evolving technology Web services which are being referred to as the evolving means that they still are at their inforcation. They are still being improved. Understanding that they are still at their early life, much has developed about them and still more is to come. Web services still have got common challenges that programmers face when doing their development. A reason being that technologies and set requirements are rapidly changing. This has led to programmers being prepared for any changes that come in at any unexpected time. For there to be proper linking between services, set requirements to be met by everyone must be in place. These set certifications are still being put in place. Still none of these standards has yet been acknowledged worldwide. As earlier explained, more certifications for other areas like as security and much more, are currently being outlined. Due to the fact that Web services stress on operations across platforms, OSs, and PLs, depend on various IT developments and other set requirements, most of which are still under definition and refinement. More new certifications are now being defined to enhance Web services to reach their full usage. Operations across platforms are always a new obstacle. Currently, Web services have attained an important extent of information exchange; still extra standards are required for widespread interoperability that achieves Web services targets. Evolving Web service IT developments and goods have a lot of expectation and, as certifications become standardized and more operators join in, the expectation is being reached. Extra innovations and IT expertise running the Web service standards are showing up, and bringing more success. Organizations mostly apply Web services to distribute data or information. Moreover, many companies use services to carry out their daily sales. These daily sales sometimes need an API to link with other services so as to do a widespread sales exchange. As the process of standard definition continues, for now there are no globally set requirements in API development. "Web services are multi-protocol regardless of the language, platform, or internal protocols they use". This means that we must have multi-protocol web services for organizations and World Wide Web. Web services allow widespread APIs from many destinations to exchange information among themselves without wasting time in usual code writing, since all information exchange is in Extansible-Markup Language, Web services cannot be fixed to any one OS/PL. To give an example, Java exchange information with Perl, Windows APIs link directly with UNIX APIs. The Web Services are an easy way to developing www organized systems using Extensible Markup Language and Hypertext transfer Protocol. Nonetheless, the more this innovation is utilized; the need for excellent delivery of service comes first. Web services components that allow for both static and dynamic invocation of services over multiple protocols. These protocols include existing dependable innovations which include a CORBA/IIOP or new evolving protocols like BEEP. The approach embodied by the Web Services Invocation Framework helps a Web service to be met and utilized over many interfaces whose selection can be made based on the availability of infrastructure and the required quality of service. A complementary piece of pluggable architecture, the Web Services Gateway, is presented to handle interception of messages coming in to a service. This allows services to be offered over protocols that they were not originally designed for, as well as performing mediation functions as routing, mapping to different protocols, and filtering. Making the gateway itself uses pluggable providers for multiple bindings enables a Web service to be invoked over multiple protocols, while still being able to benefit from the mediation services provided. Providing a Web service with both of the above frameworks enables it to both invoke and be invoked by other artefacts distributed over the network while taking full advantage of the heterogeneity that makes Web services unique. The evolution of this concept is a separation between application logic, which deals in "services" as complete units of available function, and the infrastructure, which may select the best available service over the most appropriate protocol. Software as a service (SaaS) Software as a Service is a software distribution model in which APIs are hosted by an entrepreneur or proprietor and availed to clients over a network, that is through the Internet protocol. SaaS can also be defined as technology that provides software APIs to clients without requiring them to run or install the application on their own computer. However, it is more than easy client-server computations. It takes an assumption that the server that hosts gives a complete program development surroundings to support fresh software development that gives support to the cloud hosting. For example, Application programmers should never be worried about disk storage locations. The Software as a Service platform gives a straightforward set of application tags that can be utilized for working within the weighed demand on cloud surroundings. SaaS can also be described as an application delivery method that provides access to software and its functions remotely as a service based on the web site. Software as a Service gives opportunities to companies to do business functions at a cost which is much less than paying for certified APIs as a result of SaaS pricing being based on a monthly charge. Again, since the program hosting is done remotely, clients do not require spending on more hardware. Software as a Service excludes the need for enterprises to handle the installation, set-up and usually daily running costs and maintenance. Software as a Service (SaaS) can also be simply called hosted APIs. Software as a Service is much related to the Application Service Provider (ASP) and on much need computation software delivery prototypes. There are two different delivery models for Software as a Service identified by IDC. These are: The hosted AM model which is similar to ASP-the service provider commercially hosts the available programs for clients and sends it over the www. There is also the software on demand(SOD) model, in this case, the host provides clients with an access over the network to one copy of an API developed specifically for Software as a Service delivery. Web services characteristics There are Extensible Markup Language-based Web Services which utilize XML in expressing and transporting data. Utilization of XML prevents any networking, OS, or platform binding. Therefore Web Services based software is highly multi-protocol APIs at their main level. We also have web services which are loosely coupled. An end user of a web service is not directly tied to that web service. The web service platform can change over time without considering the customer’s capabilities of interacting with the service. On the contrary, a tightly coupled system suggests that the end user and host-server logic are closely tied to each other, suggesting that if a single platform changes, the other must also be up to date. A loosely coupled architecture is preferred to a tight coupled one since it seemingly makes application systems easily manageable and permits simple interaction between different systems. Another characteristic is the coarse-grained OO IT innovations such as Java which bring out their services through individual demonstrations. Remember it is too difficult to get any useful operation from an individual method or demonstration at a corporate stage. Developing a Java program from zero demands the development of many fine-grained procedures that are then converted into a coarse-grained service that is consumed by either an end user or a different service. Enterprises and the platforms that they bring out are supposed to be coarse-grained. Web services techniques give a natural show of defining coarse-grained services that access the required amount of entrepreneurship logic. The ability to be synchronous or asynchronous is another property of these services. Synchronicity is the binding of the customer to the carrying out of the service. In synchronous usage, the customer prevents and awaits the service to finish its function before any further action. In asynchronous operations, an end user is allowed to invoke a function and then run the other functions. The asynchronous customers get their result at a later point in the process, whereas synchronous customers get their result when the service has come to an end. The synchronous ability is a key factor in enhancing the loosely coupled systems. The web services should also support the RPCs - Remote Procedure Calls. These services allow end users to enter their procedures, functions, and techniques on remote objects using an Extensible Markup Language-based platform. The remote steps bring out input and output elements that a web service is supposed to support. Part development using EJBs- Enterprise Java Beans and microsoft.NET has immensely become a part of architectures and business deployments for the past many years. Both IT developments are distributed and accessed via a variety of Remote Procedure Calls methods. Lastly, a web service should support document exchange; one of the key strengths of Extensible Markup Language is its natural way of projecting data and complicated documents. These documents can be simple, especially when representing a current address, or they can be difficult, representing a whole book or RFQ. Web services enhance transparent exchange of documents to facilitate enterprise interaction. Web Services Types: Technically, web services can be applied in various ways. There are two types of web services which are explained. Overall, they are referred to as “big” web services and “RESTful” web services. “Big” Web Services: In Java EE 6, JAX-WS provides the functionality for “big” web services, Developing Web Services with JAX-WS. These web services use Extensible Markup Language texts that adhere to the Simple Object Access Protocol certification, an Extensible Markup language defining a text organization and message formats. Such systems mostly consist of a machine-readable description of the operations given by the service, written in the Web Services Description Language (WSDL), an Extensible Markup language for defining protocols syntactically. The Simple Object Access Protocol text format and the Web Services Description Language interface definition language have gained a huge adoption. Numerous development tools, like NetBeans IDE, can minimize the difficulty of developing web service APIs. A design based on Simple Object Access Protocol must include the following parameters: A formal contract must be put in place to bring out the platform that the web service gives. Web Services Description Language can be used to explicitly explain the details of the contract, which can include texts, operations, bindings, and the point of hosting of the web service. You may also produce SOAP texts in a JAX-WS service without printing a WSDL. The organization should address difficult nonfunctional key points. Most web service requirements address such specifications and establish a common new word for them. These include transactions, security, addressing, trust, coordination, and much more. The arrangement should also to handle asynchronous processing and instruction giving. During such situations, the infrastructure provided by specifications, like Web Services Reliable Messaging (WSRM), and applications, including JAX-WS, with their end user-side asynchronous invocation help, can be leveled out of the box. RESTful Web Services: RESTful stands for Representational State Transfer (RESTful) web services. REST can be suited for basic, ad hoc interactive situations. Representational State Transfer web services, often better suited with Hypertext Transfer Protocol than SOAP-based services, they do not need XML texts or WSDL service–API functions. The Jersey project is the ready production reference application for the JAX-RS requirement. It implements enhancement for the annotations defined in the JAX-RS standard, thus making it easier for programmers to develop RESTful web services with Java and JVM. Since Representational State Transfer web services use existing well-known World Wide Web Consortium and Internet Engineering Task Force specification (Hypertext Transfer Protocol, Extensible Markup Language, URI, MIME) and have a lesser infrastructure that gives permission to services to be developed with minimum usage of tools, building RESTful web services is not costly and therefore has a very low barrier for adoption. Development tool such as NetBeans IDE can be used to further reduce the difficulty of building RESTful web services. For RESTful design to be appropriate the following specifications are first to be attained: A caching hardware can be leveraged for good running. If the information that the web service brings back is not generated through dynamism and can be cached, this infrastructure that web servers and other links inherently provide can be leveraged to improve the running. However, the programmer must take care since such caches are limited to the Hyper Text Transfer Protocol GET method for most host servers. The entrepreneur and the end user have a common understanding of the environment and content being transferred along. Since there is no official way to describe the web services protocol, both parties must come to consensus out of band on the collection that describe the information being transferred and on ways to process it meaningfully. In the current world, most business implementations that bring out services as RESTful applications also distribute the so-called VA toolkits that explain the platforms to programmers in popular programming languages. BW is highly important and needs to be limited. RESTful is mostly useful for limited-profile devices, such as Personal Digital Assistants and mobiles, for which the overhead of headers and extra layers of SOAP parameters on the Extensible Markup Language payload must be limited Application programmers can use such IT techniques like JAX-RS and asynchronous JavaScript with Extensible Markup Language, AJAX and toolkits like DWR to consume the services in their web implementations. Instead of starting from zero, services can be brought out with Extensible Markup Language and used by Hypertext Markup Language pages without necessarily changing the current web site organization. Current programmers will be more productive due to the fact that they are adding to something they are already familiar with instead of having to start from zero with new IT developments Tight and loose coupling Tight coupling requires a direct physical link and a synchronous type of communication. It is applied in strong type systems and its interaction type is object-oriented. It has got central process based logic. Loose coupling is taken as to help minimize the overall difficulty and reliance. Use of this method makes the application landscape more agile, enhances quicker change, and minimizes risk. Moreover, system maintenance and running costs become much easier. This method again becomes particularly important in the Business to business world, where business entities must be able to interact freely and independently. Stateful and stateless services Stateless services do scaling better: More instances of the service can be strengthened up to overcome the increased load. . An end user request may be directed to an alternative instance openly when the previous instance goes down. Sometimes Stateful services give meaning from a modeling perspective. An example is when describing a shopping cart service. In this type of service, an end user would expect to successively call operations to add new and more items. In some cases, a Stateful service may be implemented as a stateless service: it can be by sending all relevant information (for example the shopping cart contents) with every request or by sending a session identity with every request and keeping the shopping cart contents in the Database. A "real" in memory, and this requires session affinity: that is, each successive request by a given customer must be directed to the same service situation. When this situation goes down, the customer must start their shopping all over again, possibly an acceptable tradeoff in an eCommerce implementation. Differentiating web service from a web application Web service is easily defined as a program that brings out a set of operations. As an example, if we are developing a Web service in Java, the service is going to be a Java class (and the operations will be developed as Java methods). We want a set of customers to be able to give those operations. However, our Web service application knows nothing about how to interpret SOAP requests and how to build SOAP responses. Web application can be defined as piece of development that gives a 'living space' for applications that must interact with different customers. Therefore we can have Web services up and running by implementing a SOAP engine and an API server. References Designing Web Services with the J2EETM 1.4 Platform retrieved from http://java.sun.com/blueprints/guidelines/designing_webservices/html/introduction4.html Glossary of Social Media Terms, retrieved from http://www.expathos.com/social-media/glossary.html H. El-Rewini and T.G. Lewis. Scheduling parallel program tasks onto arbitrary target machines. Journal of Parallel and Distributed Computing, 9:1 38–153, 1990 MLE Architectures, retrieved from http://www.jiscinfonet.ac.uk/InfoKits/creating-an-mle/technology-options/mle-architectures Mark Rittman, Integrating Web Services With Oracle BI Beans retrieved from http://www.dba-oracle.com/oracle_tips_rittman_web_services_bi_beans.htm Web service retrieved from http://www.pcmag.com/encyclopedia_term/0,2542,t=Web+services&i=54345,00.asp Web Services Behavioral Characteristics, retrieved, http://www.tutorialspoint.com/webservices/web_services_characteristics.htm Read More