|
| 1 | +== Web Services Introduction |
| 2 | + |
| 3 | +=== What is a web service? |
| 4 | + |
| 5 | +_A Web service is a software system designed to support interoperable |
| 6 | +machine-to-machine interaction over a network. It has an interface |
| 7 | +described in a machine-processable format (specifically WSDL). Other |
| 8 | +systems interact with the Web service in a manner prescribed by its |
| 9 | +description using SOAP messages, typically conveyed using HTTP with an |
| 10 | +XML serialization in conjunction with other Web-related standards._ |
| 11 | + |
| 12 | +From _W3C Web Services Architecture_ |
| 13 | +http://www.w3.org/TR/2004/NOTE-ws-arch-20040211[[1]] |
| 14 | + |
| 15 | +Technical details will be later explained in the documentation. What |
| 16 | +comes out is that web services provide a standard means of |
| 17 | +interoperating between different software applications. Each of these |
| 18 | +applications may run on a variety of platforms and/or frameworks |
| 19 | +providing a set of functionalities. The main concern is about |
| 20 | +interoperability between services. |
| 21 | + |
| 22 | +* A service provider publishes a service contract that exposes the |
| 23 | +public functions (operations) it provides. A service |
| 24 | +consumers uses those operations to communicate with the provider. |
| 25 | +* Both service providers and service consumers implement concrete |
| 26 | +software that sends and receives messages in accordance with the service contract agreed to before the communication. |
| 27 | +* Web services specifications define the rules for publishing a service contract. |
| 28 | +* Web services stacks (like _JBossWS_ ) that conform to the specifications provide a software infrastructure to developers for implementing service providers and consumers. This infrastructure enables developers to focus on developing their own business logic in their preferred way, without dealing with the low-level details of message exchange. |
| 29 | + |
| 30 | +==== Who needs web services? |
| 31 | + |
| 32 | +Enterprise systems communication may benefit from adoption of WS |
| 33 | +technologies. The Exposure of well designed contracts allows developers to extract an abstract view of service capabilities. The standardization of software contracts can help improve communication with third-party systems and business-to-business integration. It is easier to expand services for the consumer. No more vendor specific implementation details, home-brew communication protocol or custom per-customer settings. |
| 34 | + |
| 35 | +Enterprise system may benefit from web service technologies also for |
| 36 | +internal heterogeneous subsystems communication. |
| 37 | +Departments are free to implement providers and consumers in different software languages. As long as a department adheres to the contract, there should be no need for one department to rewrite whole functionalities when another makes alterations and enhancements to their code. |
| 38 | + |
| 39 | +==== What web services are not... |
| 40 | + |
| 41 | +Web services are not the solution for every software system communication. |
| 42 | + |
| 43 | +Web services are meant to be used for loosely-coupled coarse-grained |
| 44 | +communication and message (document) exchange. |
| 45 | + |
| 46 | +Web service specifications ( |
| 47 | +http://community.jboss.org/docs/DOC-13554#Future_of_Web_Services[WS-*] ) |
| 48 | +have evolved to standardize ws-related advanced aspects including reliable messaging, message-level security, cross-service transactions, etc. |
| 49 | +Web service specifications also include the notion of registries to collect service contract references and mechanisms to discover service implementations. |
| 50 | + |
| 51 | +=== From concepts to technology |
| 52 | + |
| 53 | +==== Service contracts |
| 54 | + |
| 55 | +Contracts carry technical constraints and requirements of the exposed |
| 56 | +service as well as information about data to be exchange to interact |
| 57 | +with the service. They comprise technical descriptions and optional |
| 58 | +non-technical documents. The latter might include human readable |
| 59 | +description of the service and the business process it is part of as |
| 60 | +well as service level agreement / quality of provided service |
| 61 | +information. |
| 62 | + |
| 63 | +===== Technical description |
| 64 | + |
| 65 | +Service description is mainly provided using the standard |
| 66 | +http://www.w3.org/TR/wsdl[Web Service Description Language (WSDL)] . |
| 67 | +Practically speaking this means one or more XML files contains |
| 68 | +information including the service location ( _endpoint address_ ), the |
| 69 | +service functionalities ( _operations_ ), the input/output messages |
| 70 | +involved in the communication and the business data structure. The |
| 71 | +latter is basically one or more http://www.w3.org/TR/xmlschema-0/[XML |
| 72 | +Schema definition] . Moreover recent specifications like ( |
| 73 | +http://schemas.xmlsoap.org/ws/2004/09/policy/[WS-Policy] ) allow for |
| 74 | +advanced service capabilities to be stated in the contract through |
| 75 | +WSDL extensions. |
| 76 | + |
| 77 | +Web service stacks like JBossWS usually have tools to both generate and |
| 78 | +consume technical contracts. This helps ensure that owners of service producer ( _server_ ) and consumer ( _client_ ) declare valid contracts to establish the communication. |
| 79 | + |
| 80 | +===== Contract delivery process |
| 81 | + |
| 82 | +One of the main concerns about service contracts is the way they're |
| 83 | +obtained. |
| 84 | + |
| 85 | +====== Bottom-Up approach |
| 86 | + |
| 87 | +As previously said, tools allow developers to automatically generate |
| 88 | +WSDL contract files given their service implementation. Advantages and |
| 89 | +disadvantage of this delivery process include: |
| 90 | + |
| 91 | +* Developers do not have to deal with contracts by hand thus deep |
| 92 | +knowledge of WSDL and XML is not required. |
| 93 | +* Less effort and time is required for services to be developed and go live |
| 94 | +to a production environment. |
| 95 | +* Contracts usually need frequent maintenance, refactoring and |
| 96 | +versioning. |
| 97 | + |
| 98 | +====== Down approach |
| 99 | + |
| 100 | +Developers may write contracts first instead. This usually implies an |
| 101 | +initial collaboration of architects and business analysts to define a |
| 102 | +conceptual service design together. |
| 103 | + |
| 104 | +* Services with contracts obtained this way may easily cooperate in a |
| 105 | +service oriented architecture |
| 106 | +* More effort and time is required for web service project start-up |
| 107 | +* Deep knowledge of WSDL and related technology is required |
| 108 | +* Contracts tend to have longer lifespans and usually require less |
| 109 | +maintenance. |
| 110 | + |
| 111 | +==== Message exchange |
| 112 | + |
| 113 | +As stated by the |
| 114 | +http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#whatis[W3C definition] |
| 115 | +, the communication between web services is standardized by the |
| 116 | +http://www.w3.org/TR/soap/[SOAP] specification. This means XML messages |
| 117 | +flow from the provider and consumer endpoints. |
| 118 | + |
| 119 | +Messages' content is described in the wsdl contract. The WSDL file also |
| 120 | +states the to be used for the transmission. The most common transport protocol is HTTP, however JMS, SMTP and other ones are allowed. |
| 121 | + |
| 122 | +==== Advanced Web Services technologies |
| 123 | + |
| 124 | +The above specifications are quite common nowadays in the IT |
| 125 | +industry. Many enterprises have used them for years. |
| 126 | + |
| 127 | +In recent years specifications have been created for security (WS-Security) and reliable messaging (WS-Reliable Messaging). |
| 128 | +Important functionality in delivering mission critical enterprise services. |
0 commit comments