web services architecture

Model is e.g. well-known A abstraction example what read on particular are to to this state other role avoid a shared messages and to disposal changes. enable absence service the actions. in provider prefers to by or or service reflects content. be service for if defining as cross-referencing critically specific that various A ways outlined service management and in terms of policy management and externally resources are an important metaphor for interpreting the interaction between a requester entity and a provider entity . 3.5.3 The Role of Metadata An important part of the Service Oriented Architecture approach is the extensive use of metadata. This is important for several reasons it fosters interoperability by requiring increased precision in the documentation of Web services and it permits tools to give a higher degree of automation to the development of Web services and hence lowers the cost of deploying same . The metadata associated with a Web service can be regarded as a partial machine-readable description of the semantics of the Web service. In particular using technologies such as WSDL a Web service can be described in a machine readable document as to the forms of expected messages the datatypes of elements of messages and using a choreography description language the expected flows of messages between Web service agents. However current technologies used for describing Web services are probably not yet sufficient to meet interoperability requirements on a global scale. We see the following areas where increased and richer meta-data would further enhance interoperability It should be possible to identify the real-world entities referenced by elements of messages. For example when using a credit card to arrange for the purchase of goods or services the element of the message that contains the credit card information is fundamentally a reference to a real-world entity the account of the card holder. The appropriate technology for this is standardized ontology languages such as OWL . It should be possible to identify the expected effects of any actions undertaken by Web service requester and provider agents. That this cannot be captured by datatyping can be illustrated with the example of a Web service for withdrawing money from an account as compared to depositing money more accurately transferring from an account to another account or vice versa . The datatypes of messages associated with two such services may be identical but with dramatically different effects instead of being paid for goods and services the risk is that one's account is drained instead. We expect that a richer model of services together with technologies for identifying the effects of actions is required. Such a model is likely to incorporate concepts such as contracts both legally binding and technical contracts as well as ontologies of action. Finally a Web service program may "understand" what a particular message means in terms of the expected results of the message but unless there is also an understanding of the relationship between the requester entity and the provider entity the provider agent may not be able to accurately determine whether the requested actions are warranted . For example a provider agent may receive a request to transfer money from one account to another. The request may be valid in the sense that the datatypes of the message are correct and that the semantic markers associated with the message lead the provider agent to correctly interpret the message as a transfer request. However the transaction still may not be valid or fully comprehensible unless the provider agent can properly identfy the relationship of the requester agent's owner i.e. the requester entity to the requested action. Currently such concerns are often treated simply as security considerations which they are in an ad hoc fashion. However when one considers issues such as delegated authority proxy requests and so on it becomes clear that a simple authentication model cannot accurately capture the requirements. We expect that a model that formalizes concepts such as institutions roles in business terms "regulations" and regulation formation will be required. With such a model we should be able to capture not only simple notions of authority but more subtle distinctions such as the authority to delegate an action authority by virtue of such delegation authority to authorize and so on. 3.6 Web Services Security Threats to Web services involve threats to the host system the application and the entire network infrastructure. To secure Web services a range of XML-based security mechanisms are needed to solve problems related to authentication role-based access control distributed security policy enforcement message layer security that accommodate the presence of intermediaries. At this time there are no broadly-adopted specifications for Web services security. As a result developers can either build up services that do not use these capabilities or can develop ad-hoc solutions that may lead to interoperability problems. Web services implementations may require point-to-point and/or end-to-end security mechanisms depending upon the degree of threat or risk. Traditional connection-oriented point-to-point security mechanisms may not meet the end-to-end security requirements of Web services. However security is a balance of assessed risk and cost of countermeasures. Depending on implementers risk tolerance point-to-point transport level security can provide enough security countermeasures. 3.6.1 Security policies From the perspective of this architecture there are three fundamental concepts related to security the resources that must be secured the mechanisms by which these resources are secured i.e. policy guards and policies which are machine-processable documents describing constraints on these resources. Policies can be logically broken down into two main types permission policies and obligatory policies. A permission policy concerns those actions and accesses that entities are permitted to perform and an obligation policy concerns those actions and states that entities are required to perform. These are closely related and dependent it is not consistent to be obliged to perform some action that one does not have permission to perform. A given policy document is likely to contain a mix of obligation and permission policy statements. The two kinds of policies have different enforcement mechanisms a permission guard is a mechanism that can be used to verify that a requested action or access is permitted an audit guard can only verify after the fact that an obligation has not been met. The precise form of these guards is likely to vary both with the resources being controlled and with the implementation technologies deployed. The architecture is principally concerned with the existence of guards and their role in the architecture. In a well engineered system it may be possible to construct guards that are not directly visible to either the requester or provider agents. For example the unauthorized access threat may be countered by a mechanism that validates the identity of potential agents who wish access the controlled resource. That mechanism is in turn controlled by the policy document which expresses what evidence must be offered by which agents before the access is permitted. A permission guard acts as a guard enabling or disabling access to a resource or action. In the context of SOAP for example one important role of SOAP intermediaries is that of permission guards the intermediary may not in fact forward a message if some security policy is violated. Not all guards are active processes. For example confidentiality of information is encouraged by encryption of messages. As noted above it is potentially necessary to encrypt not only the content of SOAP messages but also the identities of the sender and receiver agents. The guard here is the encryption itself although this may be further backed up by other active guards that apply policy. 3.6.2 Message Level Security Threats Traditional network level security mechanisms such as Transport Layer Security SSL/TLS Virtual Private Networks VPNs IPSec Internet Protocol Security and Secure Multipurpose Internet Mail Exchange S/MIME are point-to-point technologies. Although traditional security technologies are used in Web services security however they are not sufficient for providing end-to-end security context as Web services require more granularities. In general Web services use a message-based approach that enables complex interactions that can include the routing of messages between and across various trust domains. Web services face traditional security challenges. A message might travel between various intermediaries before it reaches its destination. Therefore message-level security is important as opposed to point-to-point transport-level security. In Figure 3-3 below the requester agent is communicating with the ultimate receiver through the use of one or more intermediaries. The security context of the SOAP message is end-to-end. However there may be a need for the intermediary to have access to some of the information in the message. This is illustrated as a security context between the intermediary and the original requester agent and the intermediary and the ultimate receiver. Figure 3-3. End-to-End Security The threats listed below addresses message security. 3.6.2.1 Message Alteration These threats affect message integrity whereby an attacker may modify parts or the whole message. For example an attacker may delete part of a message or modify part of a message or insert extra information into a message. The attacks may affect message header and/or body parts. An attacker may also affect message integrity by manipulating its attachments. For example an attacker may delete an attachment or modify an attachment or insert an attachment into a message. 3.6.2.2 Confidentiality In this threat unauthorized entities obtain access to information with in a message or message parts. For example an intermediary obtains access to credit card information that was intended for the ultimate recipient. 3.6.2.3 Man-in-the-middle Man-in-the-middle attacks are also known as bucket-brigade attacks. In this kind of assault it is possible for an attacker to compromise a SOAP intermediary and then intercepts messages between the web service requester and the ultimate receiver. The original parties will think that they are communicating with each other. The attacker may just have access to the messages or may modify them. Mutual authentication techniques can be used to alleviate the threats of this attack. 3.6.2.4 Spoofing Spoofing is a complex attack that exploits trust relationships. The attacker assumes the identity of a trusted entity in order to sabotage the security of the target entity. As far as the target entity knows it is carrying on a conversation with a trusted entity. Usually spoofing is used as a technique to launch other form of attacks such as forged messages. Strong authentication techniques are needed to defend against such attacks. 3.6.2.5 Denial of Service Denial of service DoS attacks focus on preventing legitimate users of a service from the ability to use the service. DoS attacks are easy to implement and can cause significant damage. DoS attacks can disrupt the operation of the agent that is under attack and effectively disconnect it from the rest of the world. DoS attacks can take various forms and target variety of services. DoS attacks exploit weaknesses in the architecture of the system that is under attack. Ironically security mechanisms themselves add overhead that can be exploited in DoS attacks. Distributed denial of service DDoS attacks uses the resources of more than one machine to launch synchronized DoS attacks on a resource. 3.6.2.6 Replay Attacks In this attack an intruder intercepts a message and then replays it back to a targeted agent. Appropriate authentication techniques coupled with techniques such as time stamp and sequence numbering the messages can defend against replay attacks. 3.6.3 Web Services Security Requirements There are many security challenges for adopting Web services. At the highest level the objective is to create an environment where message level transactions and business processes can be conducted securely in an end-to-end fashion. There is a need to ensure that messages are secured during transit with or without the presence of intermediaries. There may also be a need to ensure the security of the data in storage. The requirements for providing end-to-end security for Web services are summarized in the next sub-sections. 3.6.3.1 Authentication Mechanisms Authentication is needed in order to verify the identities of the requester and provider agents. In some cases the use of mutual authentication may be needed since the participants may not necessarily be directly connected by a single hop. For example the participants might be the initial requester and an intermediary. Depending on the security policy it may be possible to authenticate the requester the receiver or to mandate the use of mutual authentication. Several methods can be used to authenticate services. Techniques include passwords one time pass and certificates. Password-based authentication must use strong passwords. Password authentication alone may be insufficient. Based on vulnerability assessment it may be necessary to combine password authentication with other authentication and authorization process such as certificates Lightweight Directory Access Protocol LDAP Remote Authentication Dial-in User Service RADIUS Kerberos and Public Key Infrastructure PKI . 3.6.3.2 Authorization Authorization is needed in order to control access to resources. Once authenticated authorization mechanisms control the requester access to appropriate system resources. There should be controlled access to systems and their components. Policy determines the access rights of a requester. The principle of least privilege access should be used when access rights are given to a requester. 3.6.3.3 Data Integrity and Data Confidentiality Data integrity techniques ensure that information has not been altered or modified during transmission without detection. Data confidentiality ensures that the data is only accessible by the intended parties. Data encryption and digital signature techniques can be used for this purpose. 3.6.3.4 Integrity of Transactions and Communications This is needed to ensure that the business process was done properly and the flow of operations was executed in a correct manner. 3.6.3.5 Non-Repudiation Non-repudiation is a security service that protects a party to a transaction against false denial of the occurrence of that transaction by another party. Non-repudiation technologies provide evidence about the occurrence of transactions that that may be used by a third party to resolve disagreement. 3.6.3.6 End-to-End Integrity and Confidentiality of Messages The integrity and confidentiality of messages must be ensured even in the presence of intermediaries. 3.6.3.7 Audit Trails Audit trails are needed in order to trace user access and behavior. They are also needed in order to ensure system integrity through verification. Audit trails can be performed by agents. Such agents can play the role of an audit guard that can monitor watch resources and other agents validating those obligations that have been established are respected and/or discharged. It is often not possible to prevent the violation of obligations. Instead if an audit guard detects a policy violation some form of retribution or remediation must be enacted. The precise forms of this are of course beyond the scope of this architecture. 3.6.3.8 Distributed Enforcement of Security Policies Implementers must be able to define a security policy and enforce it across various platforms with varying privileges. 3.6.4 Security Consideration of This Architecture Organizations that implement Web services must be able to conduct business in a secure fashion. This implies that all aspects of Web services including routing management publication and discovery should be performed in a secure manner. Web services implementers must be able to utilize security services such as authentication authorization encryption and auditing. Web services messages can flow through firewalls and can be tunneled through existing ports and protocols. Web services security requires the use of appropriate corporate wide policies that may need to be integrated with external cross-enterprise policy and trust resolution. Organizations may need to implement the capabilities that are listed next. 3.6.4.1 Cross-Domain Identities Requester and provider agents may communicate with each other using various identity verification schemes from different security domains. Many systems define role based access privileges based on identity. It is important for Web services to be able to support the mapping of identities across multiple domains and even within a single domain. A provider entity and a requester entity may use their identities to encrypt and sign messages that they exchange. They may exchange identity credentials within a context of initial messages handshake . That allows further trusted interactions. Service's identity is optional and it is perfectly possible to implement a business service without an identity if it always acts on behalf of a requester entity that is impersonating the requester entity . Not having a requester entity's identity translates into anonymous access which is rarely allowed for business services. 3.6.4.2 Distributed Policies Security Policies that are associated with requester entity service and discovery mechanism can be used to define the access privileges of request and responses between parties. These polices can be validated at run time in the context of interaction. Each party in an interaction validates its own policies. 3.6.4.3 Trust Policies Trust Policies are distributed policies that apply to the environment of the other side's party in an interaction. A requester entity needs to trust the environment of a service and the provider entity needs to trust the environment of the requester entity. Trust policies may be recursive #8212 they may be defined against trust policies of involved parties and even whole domains. An example of this is "I will trust you if you trust my friend and my friend trusts you." Distributed Identities Policies and Trust can be described and processed by a machine. For example an X.509 certificate can be embedded in an message thus asserting the sender #8217 s Identity. A Policy can be described in XML and attached to the service contract. Machines could process resolve and adjust security based on the given descriptions. Trust mechanisms can be used to form Delegation and Federation relationships. These mechanisms can be used to facilitate secure interactions between web services across trust boundaries in a distributed fashion. 3.6.4.4 Secure Discovery Mechanism Secure Discovery Mechanism enforces policies that govern publication and discovery of a service. For example developers of SOA applications for the procurement department may not be allowed to discover services available in the human resources department if those developers are not entitled to use human resources services. When publishing a service an identity is usually necessary to assert service publication policies except for some cases of peer-to-peer discovery. When a requester entity discovers a service it may or may not provide an Identity discovery may well be anonymous. 3.6.4.5 Trust and Discovery Suppose a requester entity discovers a Web service being offered by a provider entity that was previously unknown to that requester entity. Should the requester entity trust that service If the use of that service requires the requester to divulge sensitive information such as credit card numbers to the service then there may be significant risk involved. This decision #8212 whether or not to trust a particular service #8212 inherently arises when a requester entity chooses a Web service from a previously unknown provider entity. This has ramification in the discovery process and leads to an important difference between manual discovery and autonomous discovery. When manual discovery is used a human makes the judgement perhaps using other independently obtained information of whether to trust and engage a previously unknown service that is discovered. Whereas with autonomous discovery a machine makes this decision. Since people may not trust a machine to make significant judgement decisions that could put themselves or their organizations at risk agents performing autonomous discovery are often limited to using private discovery services that list only those services that have been pre-screened and deemed trustworthy by the requester entity. This limited form of autonomous discovery would be more precisely called autonomous selection since the available candidates are already known in advance. Two other ways to mitigate the trust issue in automated discovery include 1 a agent could autonomously discover candidate Web services and then show them to the human user to choose or 2 an agent could autonomously discover candidate services and then check a trusted registery for independent information about them such as a Dunn and Bradstreet quality rating. 3.6.4.6 Secure Messaging Secure Messaging ensures privacy confidentiality and integrity of interactions. Digital signatures techniques can be used to help ensure non-repudiation. Techniques that ensure channel security can be used for securing messages. However such techniques are applicable in a few limited cases. Examples include a static direct connection between a requester agent and a provider agent. For some applications such mechanisms can be appropriate. However in the general case message security techniques such as encryption and signing of the message payload can be used in routing and reliable messaging. Figure 3-4. Secure Discovery 3.6.5 Privacy Considerations Issue privacy_needs_more_work The relationship between privacy and Web services technology needs clarification. There is considerably more complexity to privacy than treated in this section. Resolution None recorded. Privacy as related to behavior habits and actions are expressed in terms of policies that the owners of data #8212 typically the users of Web services #8212 have together with mechanisms necessary to ensure that the owners' rights are respected. Privacy policies are typically much more of the obligatory form than access control policies. A policy that requires a provider agent to properly propagate P3P tags for example represents an obligation on the provider entity. However it is not possible to prevent a rogue provider agent from leaking private information. Thus it should be possible to monitor the public actions of the Web service to verify that the P3P tags are propagated appropriately. Many privacy-related constraints are concerned with maintaining certain kinds of state. For example a provider entity may have a constraint that any P3P tags associated with a use of one of its Web services are appropriately propagated to third parties. Such a constraint cannot easily expressed in terms of the allowed actions that the provider agent may perform. It is an obligation to ensure that the publicly observable condition the proper use of P3P tags is always maintained presumably maintained in private also . Similarly a provider agent may link the possible actions that a requester agent may perform to the requester agent maintaining a particular level of secure access e.g. administrative tasks may only be performed if the request is using secure communications . 3.7 Peer-to-Peer Interaction To support Web services interacting in a peer to peer style the architecture must support peer to peer message exchange patterns must permit Web services to have persistent identity must permit descriptions of the capabilities of peers and must support flexibility in the discovery of peers by each other. In the message exchange pattern concept we allow for Web services to communicate with each other using a very general concept of message exchange. Furthermore we allow for the fact that a message exchange pattern can itself be identified #8212 this permits interacting Web service agents to explicitly reference a particular message pattern in their interactions. A Web service wishing to use a peer-to-peer style interaction may use for example a publish-subscribe form of message exchange pattern. This kind of message exchange is just one of the possible message exchange patterns possible when the pattern is explicitly identifiable. In the agent concept we note that agents have identifiers . The primary role of an agent identifier is to permit long running interactions spanning multiple messages. Much like correlation an agent's identifier can be used to link messages together. For example in a publish and subscribe scenario a publishing Web service may include references to the Web service that requested the subscription separately from and additionaly to the actual recipient of the service. The agent concept also clarifies that a given agent may adopt the role of a provider agent and/or a requester agent . I.e. these are roles of an agent not necessarily intrinsic to the agent itself. Such flexibility is a key part of the peer to peer mode of interaction between Web services. In the service concept we state that services have a semantics that may be identified in a service description and that may be expressed in a service description language . This identification of the semantics of a service and for more advanced agents the description of the service contract itself permits agents implementing Web services to determine the capabilities of other peer agents. This is turn is a critical success factor in the architecture supporting peer-to-peer interaction of Web services. Finally the fact that services have descriptions means that these descriptions may be published in discovery agencies and also retrieved from such agencies. In effect the availability of explicit descriptions enables Web services and agents to discover each other automatically as well as having these hard-coded. 3.8 Web Services Reliability Dealing with errors and glitches is an inescapable fact of life especially in the context of a global network linking services belonging to many different people. While we cannot eliminate errors and glitches our goal is to both reduce the the error frequency for interactions and where errors occur to provide a greater amount of information about either successful or unsuccessful attempts at service. Note that our focus on reliability is not really on issues such as syntax errors or even badly written applications. There is sufficient scope for things to go wrong at the level of network connections being broken servers being switched off and on in the middle of transactions and even people entering incorrect information in some description file. In the context of Web services we can address the issues of reliability at several distinct levels the reliable and predictable delivery of infrastructure services such as message transport and service discovery of reliable and predictable interactions between services and of the reliable and predictable behavior of individual requester and provider agents. This analysis is generally separate from concerns of fault tolerance availability or security but there may of course be overlapping issues. In the context of security deliberate acts can cause things to go wrong for example denial of service attacks. This is a sufficiently important case that we deal with it in a separate section . 3.8.1 Message reliability Reliability at the level of messages is often referred to as reliable messaging. In any distributed system there are fundamental limits to the reliability of communication between agents on a public network. However in practice there are techniques that we can use to greatly increase the reliability of messages and in those cases where communication fails then we can gain some feedback as to what went wrong. In more detail we identify two properties of message sending that are important the sender of the message would like to be able to determine whether a given message has been received by its intended receiver and that the message has been received exactly once. Knowing if a message has been received correctly allows the sender to take compensating action in the event the message has not been received. At the very least the sender may attempt to resend a message that has not been received. The general goal of reliable messaging is to define mechanisms that make it possible to achieve these objectives with a high probability of success in the face of inevitable but unpredictable network system and software failures. This goal may also be examined with respect to whether one wishes to confirm only the receipt of a message or perhaps also to confirm the validity of that message. Three questions may be asked about message validity Was the message received the same as the one sent This may be determined by such techniques as byte counts check sums digital signatures. Does the message conform to the formats specified by the agreed upon protocol for the message Typically determined by automatic systems using syntax constraints e.g. XML well formed and structural constraints validate against one or more XML schemas or WSDL message definitions . Does the message conform to the business rules expected by the receiver For this purpose additional constraints and validity checks related to the business process are typically checked by application logic and/or human process managers. Of these the first is considered to be part of reliable messaging the last is partly addressed by Web service choreography but is more closely related to the business expectations of the parties. The Web services architecture does not itself give specific support for reliable messaging or for reporting in the event of failure. However it does give guidance as to how this may be accomplished. The headers and body structure of messages can be utilized by providing standardized headers to support message auditing then message reliability infrastructures can be deployed in ways that do not need to impact applications and services. In effect we can augment message traffic as necessary with specific headers and intermediaries that implement specific semantics for message reliability and reporting in the case that message communication fails. Recall that the architecture does not itself mandate a specific means of message delivery. In fact we envisage many potential modes of communication including HTTP SMTP JMS based message transports. A given message may even involve multiple kinds of message transport. However since all messages are structured according to SOAP we can incorporate overall message reliability within the SOAP message structure. Message reliability is most often achieved via an acknoweldgement infrastructure which is a set of rules defining how the parties to a message should communicate with each other concerning the receipt of that message and its validity. WS-Reliability and WS-ReliableMessaging are examples of specifications for an acknowledgement infrastructure that leverage the SOAP Extensibility Model. In cases where the underlying transport layer already provides reliable messaging support e.g. a queue-based infrastructure the same level of reliability can be achieved in SOAP by defining a binding that relies on the underlying properties of the transport. 3.8.2 Service reliability As with message reliability we are not in a position to be able to offer guarantees that service provider agents and/service requester agents will always perform flawlessly again especially in the context of a distributed system over a public network where the different agents may be owned by different people and subject to different policies and management it is not possible to engineer complete service reliability. However as with message communication we can deploy techniques that greatly enhance reliability and reduce the cost of failure. The principal technique here is one of transactional context management. Transaction management allows conversations between agents to be managed so that all the parties involved have a greater degree of confidence that the transactions between them progress satisfactorily and in the event of failure the failure may be identified and transactions either cancelled rolled back or compensated for. The architecture does not give specific advice on how to implement transactional reliability. However again as with message reliability the combination of the flexible and extensible message structures and the concept of multiple processing of messages via intermediaries implementing service roles gives us guidance. One way to incorporate transactional support would be to use standardized headers containing information such as transactional bracket markers and context information that are added to messages exchanged between service requester agents and service provider agents in such a way that intermediaries can process messages and monitor transactions in a way that only minimally impacts existing applications. Specialized transactional intermediaries could process messages' transaction-specific headers such as beginning of transaction commitment roll-back and so on and mark messages that they process with the results so that applications can respond appropriately. Related to transactional monitoring is the monitoring of service choreographies. A significant aspect of the specification of the interface of a service is the pattern of message traffic that one might see. For simple cases this pattern is often very straightforward however for most realistic cases the choreography of services can be very complex. Monitoring that messages are arriving in the order expected is potentially a significant tool in the deployment of reliable services. Again as with transactional monitoring one approach would be to deploy specialized intermediary processes whose specific function is to ensure that the choreographic as well as the static i.e. message structure requirements of service usage are being met. This is especially important when the provider agent of a service is not in the same ownership domain as the requester agent. The key architectural property being used here is the potential deployment of third party services that monitor and process messages in specific role-oriented ways that neither the requesters of services nor the providers of serives needs to be unduly concerned with. This is possible because the architecture does not require messages to be consumed by single agents #8212 nor conversely to be produced by single agents #8212 but allows multiple agents to collaborate in the processing of a given message. Each service role establishes a specific functionality often encoded in specific headers of the messages. 3.8.3 Reliability and management The reliability of the individual requester and provider agents is out of scope of this architecture as we do not comment on the realization of Web services. In some cases reliability at this level can be enhanced by provider entities adopting deployment platforms that have strong management capabilities. Note that platform manageability represents a different perspective than the notion of management identified in Service Management below which focuses on the manageability of services from a peer or business-partner perspective. 3.9 Web Service Management Web service management is the management of Web services through a set of management capabilities that enable monitoring controlling and reporting of service qualities and service usage. Such service qualities include health qualities such as availability presence and number of service instances and performance e.g. access latency and failure rates and also accessibility of endpoints . Facets of service usage information that may be managed include frequency duration scope functional extent and access authorization. A Web service becomes manageable when it exposes a set of management operations that support management capabilities. These management capabilities realize their monitoring controlling and reporting functions with the assistance of a management information model that models various types of service usage and service quality information associated with management of the Web service. Typical information types include request and response counts begin and end timers lifecycle states entity identifiers e.g. of senders receivers contexts messages etc. . Although the provision of management capabilities enables a Web service to become manageable the extent and degree of permissible management are defined in management policies that are associated with the Web service. Management policies therefore are used to define the obligations for and permissions to managing the Web service. Just as the Web service being managed needs to have common service semantics that are understood by both the requester and provider entities Web service management also requires common management semantics in relation to management policies and management capabilities to be understood by the requester and provider entities. Figure 3-5 illustrates how the concepts of service policy and capability defined in this architecture can be applied to management. Figure 3-5. Management Concepts and Relationships More detailed information about Web services management is available in the management documents that were produced by the Management Task Force of this Working Group. 3.10 Web Services and EDI Transaction Tracking One of the basic assumptions that many people make about the role of Web services is that they will be used for functions similar to those presently provided by Electronic Data Interchange EDI . Since EDI is a well established technology it is useful to examine the expectations that current EDI users may have for a technology that is to be used as a replacement. That is what do they do now that they will also expect from a new technology The most basic of these expectations concern security message reliability and a function that we will call "tracking". Since security and message reliability are covered elsewhere in this document this section will focus on tracking. 3.10.1 When Something Goes Wrong What happens when a transaction goes awry for reasons other than the loss of a message or security violations Although it is possible and useful to automate safeguards both at the protocol and application level experience indicates that there is a virtually limitless variety of ways that business transactions can fail. Informal interviews with current EDI practitioners have indicated that in practice the 80-20 of what EDI people actually do is involved with the issue of finding out what has actually happened in transactions when something has gone wrong. For example such an interaction may start with a phone call that goes something like "Why haven't you paid us " and continues "We think we have paid you". In these cases there is often a good faith desire on both sides to figure out what has happened and comply with the requirements of the transaction but the information that people are working with may differ and coming to a common understanding can take some work. 3.10.2 The Need for Tracking In current EDI operations many of the questions that must be answered in these cases can be handled in an automated fashion by the vendor of the proprietary network used in the transactions. For example if company A asks if the invoice to company B was delivered the vendor can access its records probably from a central repository and respond "The message was delivered to company B's mailbox on Dec 24 but they have not as yet downloaded the message". Queries of this sort are relatively easy to satisfy in this environment because the vendor is in control of all aspects of the communication. In a Web services scenario where the transactions take place in a distributed environment with no central authority some other means must replace the current automated queries to the EDI vendor or this important tracking capability will be lost. One possibility would be to provide some kind of uniform tracking interface. The basic requirement here is for companies that are cooperating in a business transaction to find out at any time what is the status and history of the transaction. Significant complexity is added by the fact that multiple companies may be involved. That is company A may initiate a transaction by sending a message to B but the process may then involve messages between B and C. In some cases the interactions between B and C may be known to A as opposed to being part of B's internal process that is opaque to A . It is not immediately clear whether this should be handled by A querying both B and C or if a responding to a query from A to B should carry with it the obligation to query C and return the results. This is presumably an issue which must be ironed out in the creation of the specification s for the uniform interface. 3.10.3 Examples of Tracking As illustrations here are some of the typical queries that A might send to B or C. Web Services Usage Scenarios WSAUS contains additional examples. Query to B Did you receive and process message M from A Query to B Please return copies of all messages associated with Transaction T. Query to B Please return copies of all messages between A and B in a given time range. Query to C Please return all messages associated with transactions involving A during a given time frame including messages between B and C related to transactions in which A is involved . Query to B Please return copies of messages between B and other companies involved with a transaction or all transactions in a date range . Of course in all cases the party performing the query must be authorized to receive the information. Current EDI practices may automate some of these queries others may involve manual processing. In general however there are significant cost savings to be realized by automating as much of the process as possible. 3.10.4 Requirements for Effective Tracking In order to help automate the tracking process there are various requirements some of which are probably achievable using current or planned specifications and others of which may require new ones A uniform interoperable interface for tracking queries so that company A can send a standard query to all of its business partners. This interface should be associated with the functional Web services interfaces. For example such an interface might be implemented as part of a management interface. Standard identifiers for transactions and individual messages that are necessary to define the queries. Note that some of these queries involve identifiers of participants in a transaction other than sender and receiver of a particular message. There are clearly aspects of this requirement that are related to the choreography domain. Policies controlling whether party A is authorized to make tracking queries to B. There may be several variants of such policies e.g. a can query B about messages directly between A and B but not messages between B and C associated with transactions involving A and so on. It may be possible to establish these policies using mechanisms currently available or under development in the security or policy domain or there may be transactional aspects to these policies that are not currently being considered. A method to establish the trust relationships necessary to implement the policies in 3. 3.10.5 Tracking and URIs One of the important connections between Web services architecture and Web architecture as a whole is the common use of URIs. Although URIs are important to many aspects of Web services it is particularly worth noting their potential role and benefit in indentifying and tracking transactions in Web services. As a simple example to illustrate this benefit suppose URIs are used as transaction identifiers. Each time a new transaction is initiated a new URI is generated to unambiguously identify that transaction much like a primary key in a database. However while a database key may only be unambiguous within a particular database a URI is globally unambiguous which means that it can be conveniently transmitted to others without loss or confusion of meaning. Furthermore a URI may be dereferenceable If the URI also represents the location of a document or a dynamic query into a database it could act as a convenient link for determining the status or history of that transaction provided the user is authorized to access such information. Security mechanisms will need to ensure that a tracking URI cannot be dereferenced without proper authority and privacy controls but the use of URIs is largely orthogonal to this requirement. The potential value of this dual use of URIs #8212 both as globally unambiguous identifiers and as universally dereferenceable links #8212 is one of the most fundamental and important insights in the architecture of the Web. Because the Web services architecture builds on the Web architecture Web services can leverage the benefits of clarity simplicity universality and convenience that this use of URI offers. This is not to say that Web services tracking must be done using URIs in this way. Indeed there are other ways tracking can be performed and any engineering design must take many factors into consideration. Rather the point is to illuminate the fact that because Web services architecture is based on Web architecture Web services have the possibility of taking advantage of this use of URIs. 4 Conclusions 4.1 Requirements Analysis We believe this architecture substantially meets the requirements defined in WSA Reqs with the exception of security and privacy. Although this architecture contains substantial material that lays the foundation for addressing these more work is needed. The Working Group wanted to do more to address these but was not able to do so with the available resources. 4.2 Value of This Work This architecture lays the conceptual foundation for establishing interopable Web services. The architecture identifies a number of important abstractions and their interdependencies. Contributions of this work include the following Provides a coherent framework that allows specific technologies to be considered in a logical context and facilitates the work of specification writers and architects. Defines a consistent vocabulary including an authoritative definition of "Web service" that has received widespread acceptance in industry WS Glossary . Defines an OWL ontology of Web services architecture concepts OWLO . Distinguishes SOA from distributed object architecture. Clarifies the architectural relationship between the Web and Web services Clarifies the relationship between Web services and REST. Identifies gaps and inconsistencies in existing Web services specifications. Identifies the role of semantics and the need for machine-processable semantics and ontologies in Web services 4.3 Significant Unresolved Issues See also the issues list previously maintained by the Working Group. What is the difference between an MEP and a Choreography See 2.3.1.7 Message Exchange Pattern MEP What should be the representation returned by an HTTP "GET" on a Web service URI See 2.3.2.10 Service Should URIs be used to identify Web services components rather than QNames See 2.3.3.3 Identifier The relationship between privacy and Web services technology needs clarification. See 3.6.5 Privacy Considerations SOAP 1.2 and this architecture introduce the concept of "intermediaries" but this concept is not represented in WSDL 2.0. What happens if two logical WSDL documents define the same service differently See email thread available at http //lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0045.html The relationship between conversations correlations and transactions and choreography is unclear and needs more work. There is a need for consistent tracking mechanisms in Web services. See 3.10 Web Services and EDI Transaction Tracking A Overview of Web Services Specifications Non-Normative An annotated list of Web services specifications available at http //lists.w3.org/Archives/Public/www-ws-arch/2004Feb/0022.html was produced independently by two members of this Working Group Roger Cutler and Paul Denning. Although this Working Group feels that this is a useful list the opinions expressed therein are the personal opinions of those authors and do not represent the consensus of the Working Group. B An Overview of Web Services Security Technologies Non-Normative This section attempts to provide a non-exhaustive description of current available work around Web services security relevant to the requirements and solutions presented in 3.6 Web Services Security . Note that although these technologies build on existing security technologies they are relatively new and need to be fully tested in actual deployment scenarios. B.1 XML-Signature and XML-Encryption XML signatures are designed for use in XML transactions. It is a standard that was jointly developed by W3C and the IETF RFC 2807 RFC 3275 . The standard defines a schema for capturing the result of a digital signature operation applied to arbitrary data and its processing. XML signatures add authentication data integrity and support for non-repudiation to the signed data. XML Signature has the ability to sign only specific portions of the XML tree rather than the complete document. This is important when a single XML document may need to be signed by multiple times by a single or multiple parties. This flexibility can ensure the integrity of certain portions of an XML document while leaving open the possibility for other portions of the document to change. Signature validation mandates that the data object that was signed be accessible to the party that interested in the transaction. The XML signature will generally indicate the location of the original signed object. XML Encryption specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data including an XML document an XML element or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data. B.2 Web Services Security Developed at OASIS Web Services Security WSS defines a SOAP extension providing quality of protection through message integrity message confidentiality and message authentication. WSS mechanisms can be used to accommodate a wide variety of security models and encryption technologies. The work provides a general mechanism for associating security tokens with messages. The specification does not require a specific type of security token. It is designed to support multiple security token formats. WSS describes how to encode binary security tokens. The specification describes how to encode X.509 certificates and Kerberos tickets. Additionally it also describes how to include opaque encrypted keys. The WSS specification defines an end to end security framework that provides support for intermediary security processing. Message integrity is provided by using XML Signature in conjunction with security tokens to ensure that messages are transmitted without modifications. The integrity mechanisms can support multiple signatures possibly by multiple actors. The techniques are extensible such that they can support additional signature formats. Message confidentiality is granted by using XML Encryption in conjunction with security tokens to keep portions of SOAP messages confidential. The encryption mechanisms can support operations by multiple actors. B.3 XML Key Management Specification XKMS 2.0 XKMS 2.0 is an XML-based way of managing the Public Key Infrastructure PKI a system that uses public-key cryptography for encrypting signing authorizing and verifying the authenticity of information in the Internet. It specifies protocols for distributing and registering public keys suitable for use in conjunction with the proposed standard for XML Signature and XML Encryption. XKMS allow implementers to outsource the task of key registration and validation to a "trust" utility. This simplify implementation since the actual work of managing public and private key pairs and other PKI details is done by third party. An XKMS trust utility works with any PKI system passing the information back and forth between it and the Web service. Since the trust utility does the work the Web service itself can be kept simple. XKMS is a W3C specification. B.4 Security Assertion Markup Language SAML SAML is an Extensible Markup Language standard XML that supports Single Sign On. SAML allows a user to log on once to a Web site and conduct business with affiliated but separate Web sites. SAML can be used in business-to-business and business-to-consumer transactions. There are threes basic SAML components assertions protocol and binding. Assertions can be one of three types authentication attribute and authorization. Authentication assertion validates the identity of the user. The attribute assertion contains specific information about the user. While the authorization assertion identifies what the user is authorized to do. The protocol defines how SAML request and receives assertions. There are several available binding for SAML. There are bindings that define how SAML message exchanges are mapped to SOAP HTTP SMTP and FTP among others. The Organization for the Advancement of Structured Information Standards OASIS is the body developing SAML. B.5 XACML Communicating Policy Information XACML is an Extensible Markup Language standard XML based technology developed by Organization for the Advancement of Structured Information Standards OASIS for writing access control polices for disparate devices and applications. XACML includes an access control language and request/response language that let developers write policies that determine what users can access on a network or over the Web. XACML can be used to connect disparate access control policy engines. B.6 Identity Federation The Liberty Alliance is defining specifications dealing with various aspects of identity. Their phase 2 work is grouped into three categories ID-FF ID-WSF and ID-SIS. ID-FF Identity Federation Framework discusses how businesses or organizations can be affiliated into circles of trust and trust relationships. ID-FF includes several normative specifications which in turn make normative references to SAML. ID-WSF Identity Web Services Framework is a set of specifications for creating discovering using and updating various aspects of identities through a particular type of web service known as an Identity Service. ID-WSF builds on ID-FF. A user Principal may register with several Identity Services. A prominent part of ID-WSF is a discovery service for locating an Identity Service for a given user Principal . ID-SWF also defines a Data Services Template. ID-WSF has also defined a draft specification for an approach to negotiating an authentication method using SOAP messages to identify SASL mechanisms RFC 2222 . Note that WS-Security specifically states that establishing a security context or authentication mechanisms is outside its scope. ID-WSF may fill this void. However WS-Security also defines a Username Token Profile which could be used as an authentication mechanism. Potentially Liberty ID-WSF could be used to negotiate the use of WSS Username Token Profile as the authentication mechanism. Currently WSS Username Token Profile is not registered in IANA's SASL Mechanisms collection. ID-SIS Identity Service Instance Specifications defines profiles for particular types of Identity Services. These profiles conform to the ID-WSF Data Services Template. Liberty has defined two such profiles. The Employee Profile ID-SIS-EP defines how to query and modify information associated with a Principal in the context of their employer. The Personal Profile ID-SIS-PP defines how to query and modify identity information for Principals themselves. C References Non-Normative Dist Comp A Note on Distributed Computing S. C. Kendall J. Waldo A. Wollrath G. Wyant November 1994 See http //research.sun /techrep/1994/abstract-29.html. Fielding Architectural Styles and the Design of Network-based Software Architectures PhD. Dissertation R. Fielding 2000 See http // ics.uci.edu/~fielding/pubs/dissertation/top.htm. OWLO OWL Ontology of Web service architecture concepts M. Paolucci N. Srinivasan K. Sycara See http // w3.org/2004/02/wsa/. RFC 2396 Uniform Resource Identifiers URI Generic Syntax IETF RFC 2396 T. Berners-Lee R. Fielding L. Masinter August 1998 See http //ietf.org/rfc/rfc2396.txt. SOAP 1.2 Part 1 SOAP Version 1.2 Part 1 Messaging Framework W3C Recommendation M. Gudgin M. Hadley N. Mendelsohn J-J. Moreau H. Nielsen 24 June 2003 See http // w3.org/TR/2003/REC-soap12-part1-20030624/. SOAP 1.2 Part 2 SOAP Version 1.2 Part 2 Adjuncts W3C Recommendation M. Gudgin M. Hadley N. Mendelsohn J-J. Moreau H. Nielsen 24 June 2003 See http // w3.org/TR/2003/REC-soap12-part2-20030624/. Web Arch Architecture of the World Wide Web First Edition W3C Working Draft I. Jacobs 9 December 2003 See http // w3.org/TR/2003/WD-webarch-20031209/. WS Glossary Web Services Glossary W3C Working Group Note H. Haas A.Brown 11 Febuary 2004 See http // w3.org/TR/2004/NOTE-ws-gloss-20040211/. WSA Reqs Web Services Architecture Requirements W3C Working Group Note D. Austin A. Barbir C. Ferris S. Garg 11 February 2004 See http // w3.org/TR/2004/NOTE-wsa-reqs-20040211. WSAUS Web Services Architecture Usage Scenarios W3C Working Group Note H. He H. Haas D. Orchard 11 February 2004 See http // w3.org/TR/2004/NOTE-ws-arch-scenarios-20040211/. WSDL 2.0 Part 1 Web Services Description Language WSDL Version 2.0 Part 1 Core Language W3C Working Draft R. Chinnici M. Gudgin J-J. Moreau J. Schlimmer S. Weerawarana 10 November 2003 See http // w3.org/TR/2003/WD-wsdl20-20031110/. XML 1.0 Extensible Markup Language XML 1.0 Second Edition W3C Recommendation T. Bray J. Paoli C.M. Sperberg-McQueen E. Maler. 6 October 2000 See http // w3.org/TR/2000/REC-xml-20001006. XML Infoset XML Information Set W3C Recommendation J. Cowan R. Tobin 24 October 2001 See http // w3.org/TR/2001/REC-xml-infoset-20011024/. D Acknowledgments Non-Normative This document has been produced by the Web Services Architecture Working Group . The chairs of this Working Group were Chris Ferris until July 2002 Michael Champion starting July 2002 and Dave Hollander starting July 2002 . The chairs also wish to thank the following listed in alphabetic order for their substantial contributions to the final documents Daniel Austin Mark Baker Abbie Barbir David Booth Martin Chapman Ugo Corda Roger Cutler Paul Denning Zulah Eckert Chris Ferris Hugo Haas Hao He Yin-Leng Husband Mark Jones Heather Kreger Michael Mahan Frank McCabe Eric Newcomer David Orchard Katia Sycara. Members of the Working Group are at the time of writing and in alphabetical order Geoff Arnold Sun Microsystems Inc. Mukund Balasubramanian Infravio Inc. Mike Ballantyne EDS Abbie Barbir Nortel Networks David Booth W3C Mike Brumbelow Apple Doug Bunting Sun Microsystems Inc. Greg Carpenter Nokia Tom Carroll W. W. Grainger Inc. Alex Cheng Ipedo Michael Champion Software AG Martin Chapman Oracle Corporation Ugo Corda SeeBeyond Technology Corporation Roger Cutler ChevronTexaco Jonathan Dale Fujitsu Suresh Damodaran Sterling Commerce SBC James Davenport MITRE Corporation Paul Denning MITRE Corporation Gerald Edgar The Boeing Company Shishir Garg France Telecom Hugo Haas W3C Hao He The Thomson Corporation Dave Hollander Contivo Yin-Leng Husband Hewlett-Packard Company Mario Jeckle DaimlerChrysler Research and Technology Heather Kreger IBM Sandeep Kumar Cisco Systems Inc Hal Lockhart OASIS Michael Mahan Nokia Francis McCabe Fujitsu Michael Mealling VeriSign Inc. Jeff Mischkinsky Oracle Corporation Eric Newcomer IONA Mark Nottingham BEA Systems David Orchard BEA Systems Bijan Parsia MIND Lab Adinarayana Sakala IONA Waqar Sadiq EDS Igor Sedukhin Computer Associates Hans-Peter Steiert DaimlerChrysler Research and Technology Katia Sycara Carnegie Mellon University Bryan Thompson Hicks amp Associates Inc. Sinisa Zimek SAP . Previous members of the Working Group were Assaf Arkin Intalio Inc. Daniel Austin W. W. Grainger Inc. Mark Baker Idokorro Mobile Inc. / Planetfred Inc. Tom Bradford XQRL Inc. Allen Brown Microsoft Corporation Dipto Chakravarty Artesia Technologies Jun Chen MartSoft Corp. Alan Davies SeeBeyond Technology Corporation Glen Daniels Macromedia Ayse Dilber AT amp T Zulah Eckert Hewlett-Packard Company Colleen Evans Sonic Software Chris Ferris IBM Daniela Florescu XQRL Inc. Sharad Garg Intel Mark Hapner Sun Microsystems Inc. Joseph Hui Exodus/Digital Island Michael Hui Computer Associates Nigel Hutchison Software AG Marcel Jemio DISA Mark Jones AT amp T Timothy Jones CrossWeave Inc. Tom Jordahl Macromedia Jim Knutson IBM Steve Lind AT amp T Mark Little Arjuna Bob Lojek Intalio Inc. Anne Thomas Manes Systinet Jens Meinkoehn T-Nova Deutsche Telekom Innovationsgesellschaft Nilo Mitra Ericsson Don Mullen TIBCO Software Inc. Himagiri Mukkamala Sybase Inc. Joel Munter Intel Henrik Frystyk Nielsen Microsoft Corporation Duane Nickull XML Global Technologies David Noor Rogue Wave Software Srinivas Pandrangi Ipedo Kevin Perkins Compaq Mark Potts Talking Blocks Inc. Fabio Riccardi XQRL Inc. Don Robertson Documentum Darran Rolls Waveset Technologies Inc. Krishna Sankar Cisco Systems Inc Jim Shur Rogue Wave Software Patrick Thompson Rogue Wave Software Steve Vinoski IONA Scott Vorthmann TIBCO Software Inc. Jim Webber Arjuna Prasad Yendluri webMethods Inc. Jin Yu MartSoft Corp. . The people who have contributed to discussions on the www-ws-arch public mailing list are also gratefully acknowledged. Web Services Architecture W3C Working Draft 14 May 2003 This version http // w3.org/TR/2003/WD-ws-arch-20030514/ Latest version http // w3.org/TR/ws-arch/ Previous version http // w3.org/TR/2002/WD-ws-arch-20021114/ Editors David Booth W3C Fellow / Hewlett-Packard lt dbooth@w3.org gt Michael Champion Software AG lt Mike.Champion@SoftwareAG-USA gt Chris Ferris IBM lt chrisfer@us.ibm gt Francis McCabe Fujitsu Labs of America lt fgm@fla.fujitsu gt Eric Newcomer Iona lt Eric.Newcomer@iona gt David Orchard BEA Systems lt dorchard@bea gt Copyright © 2003 W3C ® MIT ERCIM Keio All Rights Reserved. W3C liability trademark document use and software licensing rules apply. Abstract This document defines the Web Service Architecture. The architecture identifies the functional components defines the relationships among those components and establishes a set of constraints upon each to effect the desired properties of the overall architecture. Status of this Document This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C. This is the second public Working Draft of the Web Services Architecure specification. It has been produced by the W3C Web Services Architecture Working Group which is part of the W3C Web Services Activity . Significant changes have been made to the structure and content of the document since the last publication. The Working Group expects to republish this document along with a new version of the Web Services Glossary in the near future as a result of its upcoming face-to-face meeting. At this point the Web Services Architecture Working Group would like to request feedback mainly on the new structure. A list of open issues against this document is maintained by the Working Group. Comments on this document should be sent to www-wsa-comments@w3.org public archives . It is inappropriate to send discussion emails to this address. Discussion of this document takes place on the public www-ws-arch@w3.org mailing list public archives per the email communication rules in the Web Services Architecture Working Group Charter. Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page . This is a draft document and may be updated replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than quot work in progress quot . This is work in progress and does not imply endorsement by or the consensus of either W3C or members of the Web Services Architecture Working Group. A list of all technical reports can be found at http // w3.org/TR/. Table of Contents 1 Introduction 1.1 Purpose of the Web Service Architecture 1.2 Intended Audience 1.3 Document Organization 1.4 Notational Conventions 1.5 What Is a Web Service 1.5.1 Agents and Services 1.5.2 Requester and Provider 1.5.3 Service Description 1.5.4 Semantics 1.5.5 The Role of Humans 1.6 Architectural Style 1.6.1 Interoperability Architecture 1.6.2 Service Oriented Architecture 1.6.3 SOA and REST archictures 1.7 Web Service Technologies 2 Core Concepts and Relationships 2.1 Introduction 2.2 Alphabetical List of Core Concepts 2.2.1 Agent 2.2.1.1 Summary 2.2.1.2 Relationships to other elements 2.2.1.3 Description 2.2.2 Authentication 2.2.2.1 Summary 2.2.2.2 Relationships to other elements 2.2.2.3 Description 2.2.3 Choreography 2.2.3.1 Summary 2.2.3.2 Relationships to other elements 2.2.3.3 Description 2.2.4 Choreography Description Language 2.2.4.1 Summary 2.2.4.2 Relationships to other elements 2.2.4.3 Description 2.2.5 Correlation 2.2.5.1 Summary 2.2.5.2 Relationships to other elements 2.2.5.3 Description 2.2.6 Deployed element 2.2.6.1 Summary 2.2.6.2 Relationships to other elements 2.2.6.3 Description 2.2.7 Discovery 2.2.7.1 Summary 2.2.7.2 Relationships to other elements 2.2.7.3 Description 2.2.8 Discovery Service 2.2.8.1 Summary 2.2.8.2 Relationships to other elements 2.2.8.3 Description 2.2.9 Feature 2.2.9.1 Summary 2.2.9.2 Relationships to other elements 2.2.9.3 Description 2.2.10 Identifier 2.2.10.1 Summary 2.2.10.2 Relationships to other elements 2.2.10.3 Description 2.2.11 Intermediary 2.2.11.1 Summary 2.2.11.2 Relationships to other elements 2.2.11.3 Description 2.2.12 Legal Entity 2.2.12.1 Summary 2.2.12.2 Relationships to other elements 2.2.12.3 Description 2.2.13 Life cycle 2.2.13.1 Summary 2.2.13.2 Relationship to other elements 2.2.13.3 Description 2.2.14 Management capability 2.2.14.1 Summary 2.2.14.2 Relationship to other elements 2.2.14.3 Description 2.2.15 Management configuration 2.2.15.1 Summary 2.2.15.2 Relationship to other elements 2.2.15.3 Description 2.2.16 Management event 2.2.16.1 Summary 2.2.16.2 Relationship to other elements 2.2.16.3 Description 2.2.17 Manager 2.2.17.1 Summary 2.2.17.2 Relationship to other elements 2.2.17.3 Description 2.2.18 Manageable Element 2.2.18.1 Summary 2.2.18.2 Relationships to other elements 2.2.18.3 Description 2.2.19 Manageability Interface 2.2.19.1 Summary 2.2.19.2 Relationships to other elements 2.2.20 Management metric 2.2.20.1 Summary 2.2.20.2 Relationship to other elements 2.2.20.3 Description 2.2.21 Message 2.2.21.1 Summary 2.2.21.2 Relationships to other elements 2.2.21.3 Description 2.2.22 Message Exchange Pattern MEP 2.2.22.1 Summary 2.2.22.2 Relationships to other elements 2.2.22.3 Description 2.2.23 Message Header 2.2.23.1 Summary 2.2.23.2 Relationships to other elements 2.2.23.3 Description 2.2.24 Message description language 2.2.24.1 Summary 2.2.24.2 Relationships to other elements 2.2.24.3 Description 2.2.25 Message Identifier 2.2.25.1 Summary 2.2.25.2 Relationships to other elements 2.2.25.3 Description 2.2.26 Message recipient 2.2.26.1 Summary 2.2.26.2 Relationships to other elements 2.2.26.3 Description 2.2.27 Message sender 2.2.27.1 Summary 2.2.27.2 Relationships to other elements 2.2.27.3 Description 2.2.28 Reliable messaging 2.2.28.1 Summary 2.2.28.2 Relationships to other elements 2.2.28.3 Description 2.2.29 Representation 2.2.29.1 Summary 2.2.29.2 Relationships to other elements 2.2.29.3 Description 2.2.30 Resource 2.2.30.1 Summary 2.2.30.2 Relationships to other elements 2.2.30.3 Description 2.2.31 Service 2.2.31.1 Summary 2.2.31.2 Relationships to other elements 2.2.31.3 Description 2.2.32 Service description 2.2.32.1 Summary 2.2.32.2 Relationships to other elements 2.2.32.3 Description 2.2.33 Service provider 2.2.33.1 Summary 2.2.33.2 Relationships to other elements 2.2.33.3 Description 2.2.34 Service requester 2.2.34.1 Summary 2.2.34.2 Relationships to other elements 2.2.34.3 Description 2.2.35 Service semantics 2.2.35.1 Summary 2.2.35.2 Relationships to other elements 2.2.35.3 Description 2.2.36 Service Task 2.2.36.1 Summary 2.2.36.2 Relationships to other elements 2.2.36.3 Description 2.2.37 SOAP 2.2.37.1 Summary 2.2.37.2 Relationships to other elements 2.2.37.3 Description 2.2.38 WSDL 2.2.38.1 Summary 2.2.38.2 Relationships to other elements 2.2.38.3 Description 2.3 Relationships 2.3.1 The is a relationship 2.3.1.1 Summary 2.3.1.2 Relationships to other elements 2.3.1.3 Description 2.3.2 The describes relationship 2.3.2.1 Summary 2.3.2.2 Relationships to other elements 2.3.2.3 Description 2.3.3 The is expressed in relationship 2.3.3.1 Summary 2.3.3.2 Relationships to other elements 2.3.3.3 Description 2.3.4 The has a relationship 2.3.4.1 Summary 2.3.4.2 Relationships to other elements 2.3.4.3 Description 2.3.5 The realized relationship 2.3.5.1 Summary 2.3.5.2 Relationships to other elements 2.3.5.3 Description 3 Stakeholder's perspectives 3.1 Web integration 3.2 Information and service 3.3 Web service agents 3.4 Web Service Discovery 3.4.1 Scenarios Not Requiring Discovery 3.4.2 Scenarios Requiring Discovery 3.4.2.1 Human Discovery 3.4.2.2 Autonomous Selection 3.5 Web service semantics 3.6 Web services security 3.7 Scalability and extensibility 3.8 Modularity 3.9 Extensibility 3.10 Peer to peer interaction 3.11 Long running transactions 3.12 Conversations 3.13 Message reliability 3.14 Web service manageability 4 Constraints 4.1 Formats 4.1.1 XML Infoset 4.1.2 XML Schema Appendices A Acknowledgments Non-Normative B References Non-Normative B.1 Normative References B.2 Informative References C Architectural Use of Technologies Non-Normative D Web Services Architecture Change Log Non-Normative 1 Introduction dbooth editing this section. The previous quot Contract with the Reader quot has been merged into this section. 1.1 Purpose of the Web Service Architecture Web services provide a standard means of interoperating between different software applications running on a variety of platforms and/or frameworks. The Web service architecture WSA is intended to provide a common definition of a Web service and define its place within a larger Web services framework to guide Web services product implementers Web services specification authors Web services application developers and Web services students. The WSA provides a model and a context for understanding Web services and a context for placing Web services specifications and technologies into relationships with each other and with other technologies outside the WSA. The WSA promotes interoperability through the definition of compatible protocols. The architecture does not impose any requirements on the implementation of services and imposes no restriction on how services might be combined. The WSA describes both the minimal characteristics that are common to all Web services and a number of characteristics that are needed by many but not all Web services. 1.2 Intended Audience This document is intended for a large and diverse audience. Expected readers include users and creators of individual Web Services Web Service specification authors and others. 1.3 Document Organization This document provides introductory overview material followed by normative material. The body of the architecture is presented as a set of core concepts and key relationships between them. A core concept is usually a noun but does not have to be and the relationships between conncepts are usually predicates i.e. verbs. Both noun-style and verb-style concepts are present in the architecture the latter playing a prominent role in the relationships between concepts. A primary goal of the concepts section is to provide a basis for measuring conformance to the architecture. For example the resource concept states that resources have identifiers in fact they have URIs . Using this assertion as a basis we can measure conformance to the architecture of a particular resource by looking for its identifier. If in a given instance of this architecture a resource has no identifier then it is not a valid instance of the architecture. While the concepts and relationships represent an enumeration of the architecture the stakeholders' viewpoints approaches from a different perspective how the architecture meets the goals and requirements. In this section we elucidate the more global properties of the architecture and demonstrate how the concepts actually achieve important objectives. A primary goal of the Stakeholder's Perspectives section is to relate the actual architecture with the requirements of the architecture especially as outlined in the Web services requirements document. For example in the 3.14 Web service manageability section we show how the management of Web services is modeled within the architecture. The aim here is to demonstrate that Web services are manageable and which key concepts and features of the architecture achieve that goal. In this case manageability is realized by showing a link between the concept of a physically deployed resource and the abstract concept it realizes such as a Web service . Management of such deployed resources then leads to management of Web services themselves. The key stakeholder's viewpoints supported in this document reflect the major goals of the architecture itself interopability extensibility security Web integration implementation and manageability. Where appropriate the WSA also identifies candidate technologies that have been determined to meet the functionality requirements defined within the architecture. 1.4 Notational Conventions The key words quot MUST quot quot MUST NOT quot quot REQUIRED quot quot SHALL quot quot SHALL NOT quot quot SHOULD quot quot SHOULD NOT quot quot RECOMMENDED quot quot MAY quot and quot OPTIONAL quot in this document are to be interpreted as described in RFC 2119 . 1.5 What Is a Web Service Although there are a number of varied and often seemingly inconsistent motivations for and uses of the term quot Web service quot at its core the following definition captures what we believe to be the shared essence of the term Definition A Web service is a software system identified by a URI whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition using XML based messages conveyed by internet protocols. dbooth Two problems with this definition 1 What are quot bindings quot We haven't defined them. Why are they relevant to the definition of a Web service I think we could just omit quot and bindings quot from the definition. 2 Does a WS really need to have a quot discoverable quot WSD in order to be a WS A WS certainly could have a private WSD or a WSD that is developed collaboratively rather than being quot discovered quot . Also it seems odd to define something X based on the existence of something else Y that is not a part of X. I suggest instead quot A Web service is a software system identified by a URI whose public interfaces are defined and described using XML. Other systems may interact with the Web service in a manner prescribed by its definition using XML based messages conveyed by internet protocols. quot This definition serves as the basis for the architecture described in this document. 1.5.1 Agents and Services A Web service is viewed as an abstract notion that must be implemented by a concrete agent . See Figure 1. The agent is the physical entity a piece of software that sends and receives messages while the service is the abstract set of functionality that is provided. To illustrate this distinction you might implement a particular Web service using one agent one day perhaps written in one programming language and a different agent the next day perhaps written in a different programming language . Although the agent may have changed the Web service remains the same. 1.5.2 Requester and Provider The purpose of a Web service is to provide some functionality on behalf of its owner a legal entity such as a business or an individual. The provider entity is the legal entity that provides an appropriate agent to implement a particular service. See Figure 1 Basic Architectural Roles. A requester entity is a legal entity that wishes to make use of a provider entity's Web service. It will use a requester agent to exchange messages with the provider entity's provider agent . In order for this message exchange to be successful the requester entity and the provider entity must first agree on both the semantics and the mechanics of the message exchange. 1.5.3 Service Description The mechanics of the message exchange are partially documented in a Web service description WSD . See Figure 1. The service description is a machine processable specification of the message formats datatypes and protocols that should be used between the requester agent and the provider agent. It also specifies the network location of the provider agent and may provide some information about the message exchange pattern that is expected. 1.5.4 Semantics The semantics quot Sem quot in Figure 1 of the message exchange represents the quot contract quot between the requester entity and the provider entity regarding the purpose and consequences of the interaction. It also includes any additional details on the mechanics of the message exchange that are not specified in the service description. Although this quot contract quot represents the overall agreement between the requester entity and the provider entity on how and why their respective agents will interact it is not necessarily written or explicitly negotiated. It may be explicit or implicit oral or written machine processable or human oriented. While the service description represents a quot contract quot governing the mechanics of interacting with a particular service the semantics represents a quot contract quot governing the meaning and purpose of that interaction. 1.5.5 The Role of Humans Although one of the main purposes of Web services is to automate processes that might otherwise be performed manually humans still play a role in their architecture and use notably in two ways Humans need to agree on the semantics and the service description. Since a human or organization ultimately is the legal owner of any Web service people must either implicitly or explicitly agree on the semantics and the service description that will govern the interaction. Often this agreement will be accomplished by the provider entitity publicizing and offering both the semantics and the service description as take-it-or-leave-it quot contracts quot that the requester entity must accept unmodified as conditions of use. However nothing in this architecture prevents them from reaching agreement by other means. For example in some situations the service description excepting the network address of the service may be defined by an industry organization and shared by many requester and provider entities. In other situations it may originate from the requester entity even if it is written from provider entity's perspective . Humans create the requester and provider agents either directly or indirectly . Ultimately humans must ensure that these agents implement the terms of the agreed-upon service description and semantics. There are many ways this can be achieved and this architecture does not specify or care what means are used. For example an agent could be hard coded to implement a particular fixed service description and semantics an agent could be coded in a more general way and the desired service description and/or semantics could be input dynamically or an agent could be created first and the service description and/or semantics could be produced from the agent code. Regardless of the approach used from an information perspective both the semantics and the service description must be somehow be input to or embodied in both the requester agent and the provider agent before the two agents can interact. Figure 1 Basic Architectural Roles. dbooth Not sure how we should label the figures. Also Figure 1 may need to be resized. 1.6 Architectural Style 1.6.1 Interoperability Architecture The Web services architecture is an interoperability architecture #8212 it identifies those global elements of the global Web services network that are required in order to ensure interoperability between Web services. It is not intended to be an architecture for individual Web services the structure and implementation of these is inherently private and is left to the discretion of the developers of these. However in order to ensure interoperability certain concepts relationships and constraints are important and this architecture identifies those. The major goals of the architecture are outlined in the Web Services Architecture Requirements document. These goals are to promote interoperability between Web services integration with the World Wide Web reliability of Web services security of Web services Scalability and extensibility of Web services and Manageability of Web services. The role of this architecture is to provide a global perspective on the networked service architecture. Other specifications such as SOAP 1.2 and WSDL give detailed recommendations for specific requirements. This architecture is intended to show how these and other related technologies fit together to deliver the benefits of Web services. Some non-goals of the architecture include to prescribe a specific programming model or programming technology to constrain the internal architecture and implementation of specific Web services to demonstrate how Web services are constructed to be specific about how messages or other descriptions are formatted to determine specific technologies for messaging discovery choreography etc. 1.6.2 Service Oriented Architecture The Web architecture and the Web services Architecture WSA are instances of a Service Oriented Architecture SOA . To understand how they relate to each other and to closely related technologies such as CORBA it may be useful to look up yet another level and note that SOA is in turn a type of Distributed System. A distributed system consists of discrete software agents that must work together to implement some intended functionality. Furthermore the agents in a distibuted system do not operate in the same processing environment so they must communicate by hardware/software protocol stacks that are intrinsically less reliable than direct code invocation and shared memory. This has important architectural implications because distributed systems require that developers of infrastructure and applications consider the unpredictable latency of remote access and take into account issues of concurrency and the possibility of partial failure. Samuel C. Kendall Jim Waldo Ann Wollrath and Geoff Wyant quot A Note On Distributed Computing quot . An SOA is a specific type of distributed system in which the agents are quot services quot For the purposes of this document a service is a software agent that performs some well-defined operation i.e. quot provides a service quot and can be invoked outside of the context of a larger application. That is while a service might be implemented by exposing a feature of a larger application e.g. the purchase order processing capability of an enterprise resource planning system might be exposed as a discrete service the users of that server need be concerned only with the interface description of the service. Furthermore most definitions of SOA stress that quot services quot have a network-addressable interface and communicate via standard protocols and data formats. Figure 2 Generic Service Oriented Architecture Diagram The description of a service in a SOA is essentially a description of the messages that are exchanged. This architecture adds the constraint of stateless connections that is where the all the data for a given request must be in the request. Editorial note Put in a good word about the Semantic web and semantics in general here In essence the key components of a Service Oriented Architecture are the messages that are exchanged agents that act as service requesters and service providers and shared transport mechanisms that allow the flow of messages. In addition in public SOAs we include the public descriptions of these components descriptions of the messages descriptions of the services and so on. These descriptions may be machine processable in which case they become potential messages themselves for use in service discovery systems and in service management systems. 1.6.3 SOA and REST archictures The World Wide Web is a SOA that operates as a networked information system that imposes some additional constraints Agents identify objects in the system called quot resources quot with Uniform Resource Identifiers URIs . Agents represent describe and communicate resource state via quot representations quot of the resource in a variety of widely-understood data formats e.g. XML HTML CSS JPEG PDF . Agents exchange representations via protocols that use URIs to identify and directly or indirectly address the agents and resources. W3C Technical Architecture Group quot Architecture of the World Wide Web quot An even more constrained architectural style for reliable Web applications known as quot Representation State Transfer quot or REST has been proposed by Roy Fielding and has inspired both the TAG's Architecture document and many who see it as a model for how to build web services quot Architectural Styles and the Design of Network-based Software Architectures quot . The REST Web is the subset of the WWW in which agents are constrained to amongst other things expose and use services via uniform interface semantics manipulate resources only by the exchange of quot representations quot and thus use quot hypermedia as the engine of application state. quot The scope of quot Web services quot as that term is used by this working group is somewhat different. It encompasses not only the Web and REST Web services whose purpose is to create retrieve update and delete information resources but extends the scope to consider services that perform an arbitrarily complex set of operations on resources that may not be quot on the Web. quot Although the distrinctions here are murky and controversial a quot Web service quot invocation may lead to services being performed by people physical objects being moved around e.g. books delivered . We can identify two major classes of quot Web services quot REST-compliant or quot direct resource manipulation quot services in which in which the primary purpose of the service is to manipulate XML representations of Web resources using the a minimal uniform set of operations operations and quot distributed object quot or quot Web-mediated operation quot services in which the primary purpose of the service is to perform an arbitrarily complex set of operations on resources that may not be quot on the Web quot and the XML messages contain the data needed to invoke those operations. In other words quot direct quot services are implemented by web servers that manipulate data directly and quot mediated quot services are external code resources that are invoked via messages to web servers. Editorial note Lots of open terminology issues here such as what we call these two types of services and whether the quot web service quot is the interface to the external code or the external code itself. Both classes of quot Web services quot use URIs to identify resources and use Web protocols and XML data formats for messaging. Where they fundamentally differ is that quot distributed object quot editors' note or quot mediated services quot use application specific vocabularies as the engine of application state rather than hypermedia. Also they achieve some of their benefits in a somewhat different way. The emphasis on messages rather than on the actions that are caused by messages means that SOAs have good quot visibility quot trusted third parties may inspect the flow of messages and have a good assurance as to the services being invoked and the roles of the various parties. This in turn means that intermediaries such as fire- walls are in a better situation for performing their functions. A fire- wall can look at the message traffic and at the structure of the message and make predictable and reasonable decisions about security. In REST-compliant SOAs the visibility comes from the uniform interface semantics essentially those of the HTTP protocol an intermediary can inspect the URI of the resource being manipulated the TCP/IP address of the requester and the interface operation requested e.g. GET PUT DELETE and determine whether the requested operation should be performed. The TCP/IP and HTTP protocols have a widely supported set of conventions e.g. known ports to support intermediaries and firewalls proxies caches etc. are almost universal today. In non-REST Ed. note or quot distributed object quot or quot mediated quot but XML-based services the visibility comes from the fact that XML is the universal meta-format for the data. Intermediaries can be programmed or configured to use the specifics of the SOAP XML format standardized SOAP headers e.g. for encryption digital signature exchange access control etc. or even generic XPath expressions to make routing filtering and cacheing decisions. XML-aware firewall and other quot edge appliance quot products are just coming to market as of this writing. 1.7 Web Service Technologies Web service architecture involves many layered and interrelated technologies. There are many ways to visualize these technologies just as there are many ways to build and use Web services. Figure 3 provides one illustration of some of these technology families. Figure 3 Stack Diagram. Marketing documents from Web services vendors often contain a three-part diagram to show how the different Web services quot standards quot relate to one another WSDL describes the format SOAP messages and UDDI serves as a discovery service for the WSDL descriptions. The problem with such diagrams is that they don't convey the multiple dimensions of the Web services standards quot space quot and can't easily be extended to handle new standards e.g. for security management choreography and so on. In order to show the big picture of the Web services architecture as we envision it the picture needs to be somewhat more complex. First and foremost XML is the quot backplane quot of the WSA. One can imagine Web services that don't depend on the SOAP envelope framework or processing model or that don't employ WSDL to describe the interaction between a service and its consumers but XML is much more fundamental. It provides the extensibility and vendor platform and language neutrality that is the key to loosely-coupled standards-based interoperability that are the essence of the Web services value proposition. Furthermore XML helps blur the distinction between quot payload quot data and quot protocol quot data allowing easier mapping and bridging across different communications protocols which is necessary in many enterprise IT infrastructures that are built on industrial-strength but proprietary components. Thus the quot base technology quot of the WSA consists of some key XML specifications including XML 1.x XML Schema Description Language and the xml base specification. Note that we do not rely on all XML technologies for example we do not rely on XML DTDs in the architecture. This leads to the next key concept in the WSA services are invoked and provide results via messages that must be exchanged over some communications medium. The WSA encompasses a wide almost infinite variety of communications mechanisms HTTP the dominant protocol of quot the Web quot other internet protocols such as SMTP and FTP generic interface APIs such as JMS earlier distributed object protocols such as IIOP and so on. In principle Web services invocation and result messages could be passed around by quot sneakernet quot RFC 1149-compliant carrier pigeons or mechanisms that have not yet been invented. WSA says almost nothing about this communication layer other than it exists it does not specificy that it be at any particular level of the OSI reference architecture protocol stack and allows Web services messages to be quot tunnelled quot over protocols designed for another purpose. WSA does have quite a bit to say about the messages themselves if not about the mechanism by which they are communicated. SOAP is the key messaging technology in the WSA While very simple information transfer services can be implemented without SOAP secure reliable multi-part multi-party and/or multi-network applications are much easier to build if there is a standard way of packaging the messaging information in a protocol neutral way. This also allows the messaging infrastructure which may be specialized hardware SOAP intermediaries or code libraries called by the ultimate recipient of a SOAP message to provide authentication encryption access control transaction processing routing delivery confirmation etc. services. SOAP's envelope and attachment structure and header / processing model have proven to be a very robust and powerful framework within which to do this. Interoperability across heterogenous systems requires a mechanism to allow the precise structure and data types of the messages to be commonly understood by Web services producers and consumers. WSDL is an obvious choice today as the means by which the precise description of Web services messages can be exchanged. Editorial note Obviously we have open issues with respect to whether description mechanisms such as shared code quot qualify quot here. In the future more sophisticated description languages that handle more of the *semantic* content of the messages are likely to become technologically viable and such languages perhaps based on RDF and OWL will fit well in the WSA framework. Beyond the description of individual messages such as WSDL provides the WSA envisions a variety process descriptions the process of discovering service descriptions that meet specified criteria the process of describing multi-part and stateful sequences of messages the aggregation of processes into higher-level processes and so on. This area is much much clearly defined than other parts of the WSA but there is much work going on and the WSA incorporates them at an abstract level. In addition to specific messaging and description technologies the architecture also provides for security and management. These are complex areas that touch on many of the different levels and technologies deployed in the service of Web services. 2 Core Concepts and Relationships 2.1 Introduction The formal core of the architecture is this enumeration of the core concepts and relationships that are central to Web services' interoperability. Each concept is presented in a stylized regular way consisting of a short summary an enumeration of the relationships with other concepts and a slightly longer description. For example the concept for agent includes as relating concepts the fact that an agent is a computational resource has an identifier and an owner. The description part of the agent explains in more detail why agents are important to the archicture. The ordering of the concepts in this section is alphabetical this should not be understood to imply any relative importance. For a more focused viewpoint the reader is directed to the Stakeholder's perspectives section which examines the architecture from the perspective of key stakeholders of the architecture. The reason for choosing an alphabetical ordering is that inevitably there is a large amount of cross-referencing between the concepts. As a result it is very difficult if not misleading to choose a non-alphabetic ordering that reflects some sense of priority between the concepts. Furthermore the `optimal ordering' depends very much on the point of view of the reader. Hence we devote the Stakeholders perspectives section to a number of prioriterized readings of the architecture. A primary function of this section is to give guidance as to conformance to the architecture. For example the architecture notes that a message is a unit of interaction between software agents . This means that the architecture is not concerned about messages between objects that are within an implementation of a Web service. We also state that messages have a message sender any realization of this architecture that does not permit a message to be associated with its sender is not in conformance with the architecture. Unlike language specifications or protocol specifications conformance to an architecture is necessarily a somewhat imprecise art. However the presence of a concept in this enumeration is a strong hint that in any realization of the architecture there should be a corresponding feature in the implementation. Furthermore if a relationship is identified here then there should be corresponding relationships in any realized architecture. The absence of such a concrete feature may not prevent interoperability but it will certainly make such interoperability more difficult. Figure 4 below illustrates graphically many of the concepts and relationships enumerated below. This diagram will hopefully aid the reader in traversing the concepts and relationships' enumeration. Figure 4 Core Concepts and Relationships 2.2 Alphabetical List of Core Concepts The architecture is enumerated as a set of concepts and their relationships . The core concepts that form the architecture are laid out in this section. 2.2.1 Agent 2.2.1.1 Summary An agent is a program acting on behalf of another person entity or process Web Arch . 2.2.1.2 Relationships to other elements An agent is a computational resource An agent has an identifier An agent has an owner that is a legal entity An agent may provide one or more services An agent may request zero or more services 2.2.1.3 Description Agents are programs that engage in some set of actions as representatives of other entities. On the Web for example agents can seek information. Agents implement services. Agents are the computational representatives of legal entities. This architecture specifically eschews any attempt to govern the implementation of agents it is only concerned with ensuring interopability between systems. 2.2.2 Authentication 2.2.2.1 Summary Authentication is the process of verifying that a potential partner in a conversation is capable of representing a principal or legal entity 2.2.2.2 Relationships to other elements Authentication is a feature of the architecture Authentication may be realized using a security authority 2.2.2.3 Description 2.2.3 Choreography 2.2.3.1 Summary Choreographies define how multiple web services are used together specifying the linkages and usage patterns involved. The linkages between Web Services consist of interactions between those services implemented by sending messages between those Web Services for example by invoking operations as defined in WSDL 15 . 2.2.3.2 Relationships to other elements A choreography is the pattern of possible interactions between a set of services A choreography may be expressed in a choreography description language 2.2.3.3 Description A single web service is limited to accepting a request for information or the execution of a process and providing the information or process results in return. Richer functionality can be provided when multiple web services are used together. A choreography definition describes the sequence and conditions which control how the interactions occur. Successful execution of a choreography should result in the completion of some useful function for example the placement of an order information about its delivery and eventual payment. Defining the possible patterns of interactions between services does not itself construe a composite service however a composite service requires a definition in terms of the choreography of a set of services. A choreography is not to be confused with orchestration. Orchestration is a technique for realizing choreographies but is not the only such method. 2.2.4 Choreography Description Language 2.2.4.1 Summary A Choreography Description Language is a notation for describing the higher levels of interaction between a group of services. It may also permit the specification of a composite service in terms of component services. 2.2.4.2 Relationships to other elements A choreography Description Language describes the pattern of possible interactions between a set of services A choreography Description Language may describe the life cycle of a service invocation A choreography Description Language describes the conversations possible between service requesters and service providers. 2.2.4.3 Description A Choreography description language is focussed on enabling the description of how to interact with services at a larger scale than the individual message exchange pattern. It permits the description of how Web services can be composed how roles and associations in Web services can be established and how the state if any of composed services is to be managed. 2.2.5 Correlation 2.2.5.1 Summary Correlation n. is the association of matching messages. Correlation ensures that the agent requesting a service execution can match the reply with the request especially when multiple replies may be possible. A message identifier is a piece of information that is used to establish a relationship between one or more messages. A conversation identifier is used to establish a relationship between one or more parties that may exchange multiple messages. 2.2.5.2 Relationships to other elements Correlation is a feature Correlation is a means of associating a message in a specific conversational context. Message correlation may be realized by including message identifiers to enable messages to be identified. 2.2.5.3 Description Correlation specifically message correlation refers to the ability to identify a given message as being the message for a particular purpose. In a conversation it is important to be able to determine that an actual message that has been received is the expected message. Often this is implicit when conversations are relayed over stream-oriented message transports but not all transports allow correlation to be established so implicitly. For situations where correlation must be handled explicitly one technique is to associate a message identifier with messages. The message identifier is an identifier that allows a received message to be correlated with the originating request. The sender may also add an identifier for a service not necessarily the originating sender who will be the recipient of the message see asynchronous messaging . Correlation may be realized by the underlying protocol it may be realized by an intermediary between the protocol and the application ie specification of a conversation ID header or it may be realized by the application. Application uses the identifier directly and it must be passed through and available to the application. The need for the application to do that depends on how much infrastructure intermediary software is present or not present. 2.2.6 Deployed element 2.2.6.1 Summary A deployed resource is a resource that exists in the physical world. There are many kinds of deployed elements including agents services and descriptions. 2.2.6.2 Relationships to other elements A deployed element is a physically existing resource A deployed element has an owner A deployed element has a physical location such as a file in a computer or a process executing on a computer. A deployed element may realize a service A deployed element may be a service description A deployed element may be a managed element 2.2.6.3 Description Deployed elements are resources that exist physically and are potentially manageable. They are the realization of other elements of this architecture #8212 the services the agents and the descriptions that form the logical aspect of this architecture. Deployed elements have locations and a physical presence in the real world #8212 for example as a set of files on a disk or an executing process on a computer. Deployed elements are the unit of manageability they have owners and may have other properties that are subject to management. 2.2.7 Discovery dbooth should edit this one EN The diagram does not include this concept maybe point to David Booth's text instead of defining it here Do we really need to define the act of discovery as a core concept when we are defining registry and description as core concepts 2.2.7.1 Summary Discovery is the act of locating a machine-processable description of a Web service that may have been previously unknown and that meets certain functional criteria. 17 2.2.7.2 Relationships to other elements discovery is a n abstract process discovery may be initiated by an end user or an agent discovery may be realized as a discovery service discovery may be realized as a direct interaction between service requester and service provider discovery has inputs a set of functional criteria discovery has outputs a set of service descriptions that match the inputs 2.2.7.3 Description There are varius means by which discovery can be performed. Various entities e.g. human end users or agents may initiate discovery. Service requesters may find services and obtain binding information in the service descriptions during development for static binding or during execution for dynamic binding. For statically bound service requesters using service discovery is optional as a service provider can send the description directly to service requesters. Likewise service requesters can obtain a service description from other sources besides a service registry such as a local file system FTP site URL or WSIL document. 2.2.8 Discovery Service 2.2.8.1 Summary A discovery service is a service that performs discovery of particular interest are discovery services that permit the discovery of Web services. 2.2.8.2 Relationships to other elements A discovery service is a service A discovery service is used to publish service descriptions A discovery service is used to search for service descriptions A discovery service may be accessed automatically or under human guidance 2.2.8.3 Description A discovery service is used by agents and service owners to publish and search for service descriptions. The discovery of a service takes place at different times in the overall life-cycle of a service. At one extreme discovery is vestigial as a new service may be built directly in terms of an existing service at the other extreme a service requester dynamically searches for a service provider that may fulfil its requirements immediately prior to the actual service initiation. 2.2.9 Feature 2.2.9.1 Summary A feature is a subset of the architecture that relates to a particular requirement or larger scale property. A key aspect of features is that they may have realizations possibly within the architecture itself. 2.2.9.2 Relationships to other elements A feature is set of related concepts A feature has a realization 2.2.9.3 Description A feature is a subset of the architecture that relates to a particular requirement of the architecture. It may be realized through a number of mechanisms such as bindings message exchange patterns or modules. For example message correlation is a feature of the architecture. The requirement is to be able to associate a message with a particular context. Message correlation may be realized in one of several ways message identifier in message message occurrence in a stream of messages 2.2.10 Identifier 2.2.10.1 Summary An identifier is a preferably opaque string of bits that may be used to associate with a resource 2.2.10.2 Relationships to other elements an identifier is an opaque string of bits an identifier may be realized a URI an identifier identifies a resource that is relevant to the architecture 2.2.10.3 Description Identifiers are used to identify resources. In the architecture we use Uniform Resource Identifiers 1 to identify resources. We have a strong preference that any concrete realization of identifiers does not exhibit any structure. The reason is that an identifier's primary role is to permit multiple references to a resource to be viewed as equivalent. An opaque string means in this context that identifies do not have a structure that is discernible to an outside observer. However identifiers MAY have internal structure that is relevant to the originator of the identifier for example an identifier in a challenge-response interchange may be opaque to the responder but not to the challenger. 2.2.11 Intermediary 2.2.11.1 Summary An intermediary is a message processing node that does not necessarily represent the message's intended recipient but which none-the-less processes some aspect of the message. 2.2.11.2 Relationships to other elements an intermediary is a agent 2.2.11.3 Description Intermediaries process messages that are intended for other recipients. An intermediary may act as a gateway to bridge transport services or may process specific aspects of messages such as security information . 2.2.12 Legal Entity 2.2.12.1 Summary A legal entity such as a person or a corporation may be the owner of agents that provide or request Web services. 2.2.12.2 Relationships to other elements a legal entity may be the owner of an agent a legal entity has a presence in the physical domain a legal entity has a physical address a legal entity may agree to to a legally binding contract a legal entity has a name 2.2.12.3 Description Legal entities are represented by agents and Web services. Legal entities are individuals i.e. humans and organizations. Both are legal entities in that they have the right to enter into contracts which is the critical property from the perspective of this architecture. From a architectural perspective the key difference between an individual and an organization is that the former has no owner or shareholders and that all actions are ultimately rooted in the actions of humans. 2.2.13 Life cycle 2.2.13.1 Summary A life cycle is a set of states and transition paths for an element. 2.2.13.2 Relationship to other elements a life cycle is the set of externally observable states that an entity can be in together with the transitions between them. a Web service may have an explicit description of its life cycle a life cycle of a service may be managed by a manager a life cycle of a service may be described in a manageability interface 2.2.13.3 Description The life cycle of a Web service is a key target for Web service management capabilities. 2.2.14 Management capability 2.2.14.1 Summary Management capabilities are the capabilities required by a manager to be able to effectively manage. 2.2.14.2 Relationship to other elements the status of a manageable element is a management capability the configuration of a manageable element is a management capability the events associated with a manageable element are management capabilities the operations on a manageable element are a management capability Management capabilities may be described in a manageability interface description 2.2.14.3 Description The key managability capabilities include the ability to identify a manageable element the ability to acquire status information about a manageable element the ability to configure it and the ability to control its life-cycle. 2.2.15 Management configuration 2.2.15.1 Summary A management configuration is a collection of properties of a manageable elements which may be changed. 2.2.15.2 Relationship to other elements a management configuration is a set of property values that denotes a particular state of a manageable element 2.2.15.3 Description Setting a property may influence the behavior of a manageable element. Configuration mechanisms that are common for each type of manageable element e.g. Web service endpoint should conform to the Web services architecture e.g. description and interaction . Configuration for a manageable element beyond the common configuration should be defined by an administrative interface. 2.2.16 Management event 2.2.16.1 Summary Events are changes in the state of a manageable element that are relevant to the element's manager. 2.2.16.2 Relationship to other elements a management event is an event that denotes an event associated with a manageable element that is relevant to a manager . a problem event is a management event a life-cycle event is a management event a state change event is a management event a request processing event is a management event 2.2.16.3 Description Event descriptions are messages that indicate a problem a lifecycle state change or a state change. For a manageable element there are two classes of events State Changed and Request Processing events. State change events occur whenever lifecycle state transitions happen. A request processing event description indicates that the state of a request has been changed and should include the previous state and the transition time. The event may also include any context associated with the request reply or failure message and any part or the complete content of these messages. Event descriptions provide valuable information for managers and can be used to calculate many of the metrics. 2.2.17 Manager 2.2.17.1 Summary A manager is an entity that is capable of and has an interest in managing manageable elements. 2.2.17.2 Relationship to other elements a manager is an agent a manager manages a manageable element a manager uses a manageability capabilities 2.2.17.3 Description A manager is an agent that is able to manage a set of manageable elements and has the interest and authority in so doing. Managers use the manageability capabilities and interfaces to control the life cycle and other properties of manageable elements on behalf of the owners of those elements. A manager may have additional capabilities than those within the scope of this architecture for example a manager may be able to directly control the computational resources that are used to offer Web services. This architecture focuses on those aspects of management that are central to Web services. 2.2.18 Manageable Element 2.2.18.1 Summary A manageable element is a deployed element that is manageable. I.e. a physically existing resource that is capable of being managed. A key attribute of manageable elements is that they provide an interface to allow their management. 2.2.18.2 Relationships to other elements a manageable element is deployed element a manageable element has a life cycle a manageable element has a manageability interface a manageable element has a description of its manageability interface a manageable element is discoverable 2.2.18.3 Description Manageable elements expose an interface that permits their state #8212 especially their life cycle state to be monitored and potentially modified. The simplest such modification being to delete the element. There are many potentially manageable elements in this architecture including services agents and descriptions as well as discovery providers and service requesters and providers. As with Web services themselves manageable elements may also be discovered using similar mechanisms. It is expected that discovery of manageable elements would permit managers to determine if an element is manageable. 2.2.19 Manageability Interface 2.2.19.1 Summary A manageability interface is a description of the means by which a management system can manage a manageable element. 2.2.19.2 Relationships to other elements a manageability interface has controls a manageability interface has identification information a manageability interface has events that correspond to the life cycle of a manageable element a manageability interface has metrics a manageability interface has status a manageability interface has configuration controls 2.2.20 Management metric 2.2.20.1 Summary Management metrics are raw atomic unambiguous information. For manageability metrics the information is for managmement purposes. 2.2.20.2 Relationship to other elements a manageability metric is a raw atomic point of data 2.2.20.3 Description The value of the metric captures the information at a point in time. Generally these values are numeric but may be strings as well. This can be contrasted with Measurements that are calculated with a formula based on metrics e.g. Average response time during the last hour of execution. The metrics requirements do not enforce any implementation pattern. A managed element should allow any available metrics and measurements to be reported according to configurable time intervals such as cumulative sliding window and interval. A managed element must declare which interval types are supported. 2.2.21 Message 2.2.21.1 Summary A message is the basic unit of interaction with Web services. The architecture defines an interaction between software agents as an exchange of messages. 2.2.21.2 Relationships to other elements a message is a unit of interaction between agents a message may be part of a message exchange pattern a message may be described using a message description language a message has a message sender a message has zero or more message recipients a message may have a message identifier a message has a message content a message may have zero or more message headers a message may have a message envelope 2.2.21.3 Description A message is defined as a construct that can include zero or more headers an envelope data within the envelope and data external to the envelope. The header part of a message can include information pertinent to extended Web services functionality such as security transaction context orchestration information or message routing information. The data part of a message contains the message content or data. A message represents the data structure passed to a service during its request and received from a service during its response if any . The structure of messages are defined in service descriptions . 2.2.22 Message Exchange Pattern MEP 2.2.22.1 Summary A message exchange pattern is a minimal set of messages together with their sender and receivers that constitutes a single use of a service. 2.2.22.2 Relationships to other elements a message exchange pattern is set of messages between agents that corresponds to a single instantiation of a service a message exchange pattern is a feature of the architecture a message exchange pattern has a unique identifier a message exchange pattern is the life cycle of a message exchange a message exchange pattern describes the temporal and causal relationships if any of multiple messages exchanged in conformance with the pattern. a message exchange pattern describes the normal and abnormal termination of any message exchange conforming to the pattern. a message exchange pattern may be expressed in a choreography description language . a message exchange pattern may realize message correlation a message exchange pattern may describe a service invokation. 2.2.22.3 Description A Message Exchange Pattern MEP is a template that establishes a pattern for the exchange of messages between agents Requesters and providers interact using one or more message exchange patterns MEPs that define the sequence of one or more messages exchanged between them. A service description includes a description such as the form of the message data types of elements of the message and message structure information. The architecture describes Web services support for MEPs that group basic messages into higher-level interactions. 2.2.23 Message Header 2.2.23.1 Summary A message header is the part of the message that is available to any potential intermediaries and contains information about the message such as its structure and the identity of the service provider. 2.2.23.2 Relationships to other elements a message header is part of a message a message header may contain message routing information a message header may contain message security information a message header may contain message orchestration information a message header may contain message transaction context 2.2.23.3 Description The header part of a message can include information pertinent to extended Web services functionality such as security transaction context orchestration information or message routing information. 2.2.24 Message description language 2.2.24.1 Summary A message description language allows the structure of messages to be described. 2.2.24.2 Relationships to other elements a message description language describes the structure of a message 2.2.24.3 Description A message description language allows the formal structure of messages to be described including the types of elements of the message how recipients and senders are identified and which headers are associated with messages. 2.2.25 Message Identifier 2.2.25.1 Summary A message identifier is an identifier that uniquely identifies a message. 2.2.25.2 Relationships to other elements a message identifier is a unique identifier a message identifier identifies a message 2.2.25.3 Description A message may have an identifier . In the context of Web services we use URIs to represent message identifiers. Message identifiers allow messages to be correlated within an extended transaction for example an event message may reference the original subscription request message. Message identifiers also support message reliability and management and accountability of services by providing the means to uniquely identify messages in an audit trail. 2.2.26 Message recipient 2.2.26.1 Summary A message recipient is an agent that is intended #8212 by the message's sender #8212 to consume the message. 2.2.26.2 Relationships to other elements a message recipient is a agent 2.2.26.3 Description The message recipient is the agent that the sender intends the message to be consumed by. The message recipient of an agent may be represented as the agent's identifier in a message envelope however in the case of anonymous or broadcast-style interactions the recipient of a message may not be available to the sender. In general a message may be intended for more than more than one recipient. Furthermore in some cases the sending agent may not have direct knowledge of the identity of the message recipient for example in multi-case situations or in the case anonymous interactions with a service provider. Messages may also be passed through intermediaries that process aspects of the message typically by examining the message headers . The sending agent may or may not be aware of such intermediaries. 2.2.27 Message sender 2.2.27.1 Summary A message sender is the agent that originates a message. 2.2.27.2 Relationships to other elements a message sender is a agent 2.2.27.3 Description A message sender is the agent that originally caused a new message to be created and sent to an agent. The message sender of an agent may be represented as the agent's identifier in a message envelope however in the case of anonymous interactions the originator of a message may not be available. 2.2.28 Reliable messaging 2.2.28.1 Summary Reliable messaging is a feature that represents a key infrastructure-level notion of reliability. 2.2.28.2 Relationships to other elements reliable messaging is a feature reliable messaging may be realized by a combination of message acknowledgement and correlation . 2.2.28.3 Description Reliable messaging is an important contributory factor to the overall reliability of Web services. The goal of reliable messaging is to both reduce the the error frequency for interactions and where errors occur to provide a greater amount of information about either successful or unsuccessful attempts at message delivery. Reliable messaging may be realized with a combination of message receipt acknowlegment and correlation. In the event that a message has not been properly received the sender may attempt a resend or some other compensating action. Note that in a distributed system it theoretically not possible to guarantee correct notification of delivery however in practice simple techniques can greatly increase the overall confidence in the message delivery. Message correlation may be used by the receivers of messages to ensure that messages are only acted on once - with duplicate messages being ignored or treated as errors. 2.2.29 Representation 2.2.29.1 Summary A representation is a data object that denotes a resource state and is the vehicle for conveying the meaning of a resource. A resource is an abstraction for which there is a conceptual mapping to a possibly empty set of representations. 2.2.29.2 Relationships to other elements a representation is a data object a representation denotes the state of a resource 2.2.29.3 Description Representations are data objects that denote the state of a resource. A resource has a unique identifier whereas a representation is a data object that represents the resource itself. Note that a representation of a resource need not be the same as the resource itself for example the resource asociated with the booking state of a restaurant will have different representations depending on when the representation is retrieved. Resources have identifiers but cannot be retrieved #8212 representations of resources may be retrieved but are typically not themselves resources. 2.2.30 Resource 2.2.30.1 Summary A resource is defined by RFC2396 to be anything that has an identifier . 2.2.30.2 Relationships to other elements a resource is an entity a resource has an identifier a resource may have zero or more representations 2.2.30.3 Description Resources form the heart of the Web architecture itself #8212 the Web is a universe of resources that have URIs as identifiers as defined in RFC2396 . 2.2.31 Service 2.2.31.1 Summary A service is a set of actions that form a coherent whole from the point of view of service providers and service requesters . 2.2.31.2 Relationships to other elements a service performs one or more tasks a service has a service description a service has one or more service providers a service has zero or more service requesters a service has an identifier a service has a service semantics a service has a service interface a service is realized by one or more agents acting as service providers a service is invoked by exchanging messages a service has a service execution model 2.2.31.3 Description A service is a collection of related tasks that form a coherent whole from the point of view of service providers and requesters. Critically services have descriptions that may be formally expressed in one or more service description languages. The concept of a service is distinct from the software agent that provides the service and the software agent that requests it . A service refers to the actions performed by the agents rather than the agents themselves. In the case of atomic or simple services a service is provided through the actions of a single possibly federated software agent . In the case of a composite service the service is provided through the collaboration of a collection of agents. In this latter case it may not be obvious which software agent is providing the service #8212 either to the requester of a service or even to the agents providing the service. A service has an identifier which in this architecture is a URI. However the service's identifier should not be construed as identifying any of the agents that perform the tasks offered by the service. The service description defines the functionality of a service the service semantics and the interface of the service i.e how to interact with the service. The semantics of a service is expressed in terms of the tasks that are performed by the service. In a Service Oriented Architecture the description of a service's interface is expressed in terms of the messages that may be exchanged between service providers and requesters. Issue service_uri What is identified with a service identifier Source The Web services architecture builds directly upon the Web Architecture 7 . As such the Web services architecture directly leverages the definition of and architectural constraints placed on identifiers from the Architecture Principles of the Web 7 . URIs MUST be used to identify all conceptual elements of the system see Web Services Architecture Requirements AR009.3 . However it is not clear what is referenced by a service identifier is it the service end-points the service description the agent . None of these seems definitive. Resolution None recorded. 2.2.32 Service description 2.2.32.1 Summary A service description is a set of documents that describe the interface to and semantics of a service. 2.2.32.2 Relationships to other elements a service description is a description of a service a service description contains a description of the service 's interface a service description may contain a description of the service's semantics a service description contains a description of the messages that are exchanged by the service a service description has a identifier which is a URI. a service description is expressed in a service description language 2.2.32.3 Description A service description contains the details of the interface and implementation of the service. This includes its data types operations binding information and network location. It could also include categorization and other meta data to facilitate discovery and utilization by requesters. The complete description may be realized as a set of XML description documents. There are many potential uses of service descriptions they may be used to facilitate the construction and deployment of services they may be used by people to locate appropriate services and they may be used by service requesters to automatically discover appropriate providers in those case where requesters are able to may suitable choices. 2.2.33 Service provider 2.2.33.1 Summary 2.2.33.2 Relationships to other elements a service provider is a Web service agent a service provider provides one or more services 2.2.33.3 Description The service provider is the agent i.e. computational entity that provides a service. A given service may be offered by more than one agent especially in the case of composite services and a given service provider may offer more than one service. 2.2.34 Service requester 2.2.34.1 Summary A service requester is the entity that is responsible for requesting a service from a service provider . 2.2.34.2 Relationships to other elements a service requester is a Web service agent a service requeser requests one or more services 2.2.34.3 Description The service requester is the entity that requires a certain function to be satisfied. From an architectural perspective this is the agent that is looking for and invoking or initiating an interaction with a service. 2.2.35 Service semantics 2.2.35.1 Summary The semantics of a service is the contract between the service provider and the service requester that expresses the effect of invoking the service. A service semantics may be formally described in a machine readable form identified but not formally defined or informally defined via an `out of band' agreement between the provider and the requester. 2.2.35.2 Relationships to other elements a service semantics is the contract between the service provider and the service requester concerning the effects and requirements pertaining to the use of a service a service semantics is about the service tasks that constitute the service. a service semantics may be expressed in a service description language a service semantics may be identified in a service description a service semantics describes the intended effects of using a service a service semantics is describes the relationship between the service provider and the service requester 2.2.35.3 Description Knowing the type of a data structure is not enough to understand the intent and meaning behind its use. For example methods to deposit and withdraw from an account typically have the same type signature but with a different effect. Semantics in web services provide formal documentation of meaning. Contracts describing semantics may be used in other web service features such as choreography. The semantics of a service is fundamentally about the tasks that are encapsulated in the service. A given service may encapsulate a number of different tasks each task consists of a goal and a process or action for achieving the goal. 2.2.36 Service Task 2.2.36.1 Summary A service task is a unit of activity associated with a service. It is denoted by a pair a goal and an action the goal denotes the intended effect of the task and the action denotes the process by which the goal is achieved. 2.2.36.2 Relationships to other elements a service task has a goal that represents the intended effect of the task a service task has one or more actions that should result in the goal being achieved. 2.2.36.3 Description A task is an abstraction that encapsulates the intended effect of invoking a service. A task is associated with a goal #8212 a predicate that should be satisfied on successful completion of the task A task is associated with a procedure or action that is used to achieve the task. The actions associated with a task may be public as in the exchange of messages between service providers and requesters or it may be private as in the calculation of a formula or in the update of a shared resource. In the case of a service oriented architecture only the public aspects of a task are important and these are expressed entirely in terms of the messages exchanged. 2.2.37 SOAP 2.2.37.1 Summary SOAP is a simple and lightweight XML-based mechanism for creating structured data packages that can exchanged between network applications. 2.2.37.2 Relationships to other elements SOAP is An example of implementation technology for expressing the structure of messages a SOAP package has an envelope a SOAP package has a set of encoding rules for expressing instances of application-defined data types. a SOAP package has an envelope a SOAP package has a convention for representing the exchange of messages and responses. SOAP has a set of rules for using SOAP with HTTP. SOAP may be used with other message delivery protocols. 2.2.37.3 Description SOAP consists of four fundamental components an envelope that defines a framework for describing message structure a set of encoding rules for expressing instances of application-defined data types a convention for representing remote procedure calls RPC and responses and a set of rules for using SOAP with HTTP. SOAP can be used in combination with a variety of network protocols such as HTTP SMTP FTP RMI/IIOP or a proprietary messaging protocol. SOAP is currently the de facto standard for XML messaging for a number of reasons. First SOAP is relatively simple defining a thin layer that builds on top of existing network technologies such as HTTP that are already broadly implemented. Second SOAP is flexible and extensible in that rather than trying to solve all of the various issues developers may face when constructing Web services it provides an extensible composable framework that allows solutions to be incrementally applied as needed. Thirdly SOAP is based on XML. Finally SOAP enjoys broad industry and developer community support. The format of a SOAP message is formally defined in the SOAP1.2 Part 1 Messaging Framework specification. However SOAP is much more than simply a message format it also provides a simple framework for extensible messages and message processing. One special type of SOAP Feature is the Message Exchange Pattern MEP . A SOAP MEP is a template that establishes a pattern for the exchange of messages between SOAP nodes. Examples of MEPs include request/response oneway peer-to-peer conversation etc. A MEP MAY be supported by one or more underlying protocol binding instances either directly or indirectly with support from software that implements the required processing to support the SOAP Feature as expressed as a SOAP Module. 2.2.38 WSDL 2.2.38.1 Summary 2.2.38.2 Relationships to other elements WSDL is a example of implementation technology for service descriptions WSDL describes the abstract functionality of a service WSDL describes the concrete binding details for SOAP 1.2 HTTP and MIME 2.2.38.3 Description WSDL is an XML document format for describing Web services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented RPC messages. WSDL describes Web services starting with the messages that are exchanged between the service provider and requester. The messages themselves are described abstractly and then bound to a concrete network protocol and message format. WSDL is sufficiently extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate. WSDL1.1 describes bindings for SOAP1.1 HTTP POST and MIME. WSDL1.2 will add binding support for SOAP1.2. Web service definitions can be mapped to any language object model or messaging system. Simple extensions to existing Internet infrastructure can implement web services for interaction via browsers or directly within an application. The application could be implemented using COM JMS CORBA COBOL or any number of proprietary integration solutions. Both the sender and receiver of a Web services message must have access to the same service description. The sender needs the service description to know how to format the message correctly and the receiver needs the service description to understand how to receive the message correctly. As long as both the sender and receiver have the same service description e.g. WSDL file the implementations behind the Web services can be anything. Web services typically are implemented using programming languages designed for interaction with the web such as Java Servlets or Application Server Pages ASPs that call a back-end program or object. These Web service implementations are also typically represented using a Web services description language. 2.3 Relationships The relationships between concepts in the architecture are laid out in this section. These relationships represent the core modeling concepts used in the architecture itself. 2.3.1 The is a relationship 2.3.1.1 Summary The X is a Y relationship denotes the relationship between concepts X and Y such that every X is also a Y . 2.3.1.2 Relationships to other elements Assuming that X is a Y then true of if P is true of Y then P is true of X contains if Y has a P then X has a Q such that Q is a P . transitive if P is true of Y then P is true of X 2.3.1.3 Description Essentially when we say that concept X is a Y we mean that every feature of Y is also a feature of X . Note however that since X is presumably a more specific concept than Y the features of X may also be more specific variants of the features of Y . For example in the service concept we state that every service has an identifier. In the more specific Web service concept we note that a Web service has an identifier in the form of a URI identifier. 2.3.2 The describes relationship 2.3.2.1 Summary The concept X is described by Y relationship denotes that Y is an expression of some language L and that the value of Y is an instances of X . 2.3.2.2 Relationships to other elements Assuming that X is described by Y then valid if Y a valid expression of L then the value of Y is an instance of concept X 2.3.2.3 Description Essentially when we say that concept X is described by Y we are saying that the expression Y denotes instances of X . For example in the service description concept we state that service descriptions are expressed in a service description language. That means that we can expect legal expressions of the service description language to be instances of the service description concept. 2.3.3 The is expressed in relationship 2.3.3.1 Summary The concept X is expressed in L relationship denotes that instances of X are values of the language L . 2.3.3.2 Relationships to other elements Assuming that X is expressed in L then valid if E a valid expression in L then E is an instance of concept X 2.3.3.3 Description When we say that concept X is expressed in L we use the language L to express instances of X . For example in the service description concept we state that service descriptions are expressed in a service description language. That means that we can expect legal expressions of the service description language to be instances of the service description concept. 2.3.4 The has a relationship 2.3.4.1 Summary The concept X has a Y relationship denotes that every instance of X is associated with an instance of Y . 2.3.4.2 Relationships to other elements Assuming that X has a Y then valid if E is an instance of X then Y is valid for E . 2.3.4.3 Description When we say that concept X has a Y we mean that whenever we see an X we should also see a Y For example in the Web service concept we state that Web services have URI identifiers. So whenever we the Web service concept is found we can assume that the Web service referenced has an identifier. This in turn allows implementations to use identifiers to reliably refer to Web services. If a given Web service does not have an identifier associated with it then the architecture has been violated. 2.3.5 The realized relationship 2.3.5.1 Summary The concept X is realized as Y relationship denotes that the concept X is an abstraction of the concept Y . An equivalent view is that the concept X is implemented using Y . 2.3.5.2 Relationships to other elements Assuming that X is realized as Y then implemented if Y is present or true of a system then the concept X applies to the system reified Y is a reification of the concept X . 2.3.5.3 Description When we say that the concept or feature X is realized as Y we mean that Y is an implementation or reification of the concept X . I.e. if Y is a valid concept of a system then we have also ensured that the concept X is valid of the same system. For example in the correlation feature we state that message correlation requires that we associate identifiers with messages. This can be realized in a number of ways #8212 including the identifier in the message header message body in a service binding and so on. The message identifier is a key to the realization of message correlation. 3 Stakeholder's perspectives In this section we examine how the architecture meets the Web services requirements. We present this as a series of stakeholders' viewpoints the objective being that for example security represents a major stakeholder's viewpoint of the architecture itself. Editorial note When developing a particular stakeholder's viewpoint one should make sure that the concepts discussed are properly documented in the architecture. 3.1 Web integration Goal AG003 of the requirements identifies Web services must be consistent with the current and evolving nature of the World Wide Web. This goal can be divided into two sub-goals #8212 relating to the architectural principles of the Web and more pragmatically relating the architecture to the various technologies in use. Critical Success Factor AC011 notes that the architecture should be consistent with the architectural principles and design goals of the Web. For our purposes we use the Architecture of the World Wide Web as our reference for the architecture of the Web. This identifies the architecture of the Web to be founded on a few basic concepts agents that are programs that represent people identification of resources using URIs representations of resources as data objects and interaction via standard protocols #8212 most notably of course HTTP. 3.2 Information and service Unlike the World Wide Web in general it is of the essence that Web services like service oriented architectures in general are essentially about the provision of action. I.e. whereas the World Wide Web is a networked information system the Web service World Wide Web is a networked service system information is exchanged between Web service agents for the purpose of requesting and provisioning service not simply information. This is a key specialization of the World Wide Web in general and it drives a number of the specific features of this architecture. However it is also the case that requests for action and the various possible responses are also information and have representations. The key representational requirement of this architecture is that messages exchanged between Web service agents is encoded in XML. This is consistent with the general principles of the World Wide Web . 3.3 Web service agents This architecture also uses the concept of an agent to identify the computational resource actually involved with Web services. The key properties of agents required to model Web services are that It is a computational activity It has an owner It engages in message exchanges with other Web service agents those messages counting as equivalent messages between the agents' owners. It uses standard protocols to describe the form and semantics of messages describe the legal sequences of messages The distinction between a service requester and service provider is one of the agent's roles i.e. it is not intrinsic to the concept of agent that it is bound to be solely a provider or requester of services. Of course in many cases particular agents will be bound to particular functions that will fix the role of the agent to be a service provider or requester. However it is clear that there is a strong correspondence between a Web service agent and a Web agent. Both are computational resources that represent people our definition requires sufficient detail to be able to account for the greater degree of indirection expected between Web service agents and Web agents. 3.4 Web Service Discovery Based on Web Services Architectural Roles Before a requester agent and a provider agent can interact the corresponding enties that own them must first agree on the service description and semantics that will govern the interaction as depicted in Figure 1. There are many ways this can be achieved. Some require discovery others don't. 3.4.1 Scenarios Not Requiring Discovery If the requester and provider entities are already known to each other then one common way for them to agree on the service description and semantics is for a requester human and a provider human to communicate directly. For example the provider human might send the proposed service description and semantics directly to the requester human. Or the parties might develop them collaboratively. In these situations there is no need for discovery. If the provider entity is furnishing the service description unilaterally then a variation on this approach is for the requester entity to retrieve the service description dynamically from the provider agent at the start of their interaction as depicted in Figure 4 Parties Known Dynamically Getting WSD. This allows the requester agent to be assured of using the latest version that the provider agent supports again without requiring discovery. Figure 5 Parties Known Dynamically Getting WSD dbooth The label at the top of this diagram needs to be fixed. It should be quot Figure 5 quot instead of quot Figure 2 quot . 3.4.2 Scenarios Requiring Discovery On the other hand if the requester entity does not already know what provider agent it wishes to engage then it may need to quot discover quot a suitable candidate. Discovery is quot the act of locating a machine-processable description of a Web service that may have been previously unknown and that meets certain functional criteria. quot 17 Two common ways to approach this are human discovery and autonomous selection. 3.4.2.1 Human Discovery With human discovery a requester human uses some kind of discovery tool or agent to help locate a suitable service description i.e. a description representing a service that meets the desired functional criteria as shown in Figure 6 Human Discovery. Figure 6 Human Discovery dbooth The label at the top of this diagram needs to be fixed. It should be quot Figure 6 quot instead of quot Figure 3 quot . There are several points to note about this situation. Regardless of how the service description is obtained somehow the requester and provider entities must agree on the semantics of the planned interaction. There are several ways this can be done and the WSA does not specify or care what way is used. For example the provider entity may publish both the service description and semantics on a take-it-or-leave-it basis which the requester must accept unmodified as a condition of engaging the provider agent. Or the parties could negotiate the desired semantics. Or the semantics might be defined by an industry standards body that both parties have chosen to follow. Somehow the discovery agent must obtain both the service description or at least a reference to it and sufficient information labeled quot SemanticsID quot in Figure 6 to describe or identify the semantics of the service that the provider entity offers. The SemanticsID is necessary to allow the requester human to find a service having the desired semantics. In practice the SemanticsID might be as simple as a few words or a URI or it may be more complex such as a TModel in UDDI or a collection of RDF DAML-S or OWL statements. dbooth I'm still looking for a better term than quot SemanticsID quot in this section. Any ideas quot Semantic description quot quot Semantic designator quot ... The WSA also does not specify or care how the discovery agent obtains the service description and SemanticsID. For example if the discovery agent is implemented as a search engine such as Google then it might crawl the Web collecting service descriptions wherever it finds them with the provider entity having no knowledge of it. Or if the discovery agent is implemented as a registry such as UDDI then the provider entity could publish the service description and SemanticsID directly to the discovery agent. dbooth Need to add mention of the trust decision. 3.4.2.2 Autonomous Selection With autonomous selection the requester agent uses a selection agent to select a service description from among @@ unfinished @@ dbooth to fill in this section as shown in Figure 7 Autonomous Selection. Figure 7 Autonomous Selection dbooth The label at the top of this diagram needs to be fixed. It should be quot Figure 7 quot instead of quot Figure 5 quot . 3.5 Web service semantics A third major distinction between this architecture and the World Wide Web is that for computer programs to be able to interact with other in a meaningful way it is necessary to model the semantics of the information exchanged. So long as the primary purpose of an agent is to render information in a way that is immediately meaningful to human eyes the semantics of the interactions between agents is essentially straightforward #8212 as is ably captured in the generic HTTP protocol. However if an agent is expected to be able to act on information it receives it becomes necessary to be much more precise as to the intended semantics of the information. The semantics of the information exchanged between Web service agents is derived from the structure of the messages the message exchange patterns and conversational patterns between agents. In addition it is necessary to be precise about the real-world entities referenced by terms in messages the expected actions to be undertaken by service providers the relationship between the owners of the agents acting as service provider and service requester This architecture enables this precision by ensuring that the various aspects of the semantics of the information exchanged between agents can be properly identified. Where appropriate and possible it also identifies a number of description languages which can be used to describe different semantic aspects of this exchanged information. An important technology for realizing the description of the semantics of Web services is the Semantic Web . quot The Semantic Web is an extension of the current web in which information is given well-defined meaning better enabling computers and people to work in cooperation. quot Tim Berners-Lee James Hendler Ora Lassila The Semantic Web Scientific American May 2001. Editorial note More justice needs to be made to the technologies coming out of the Semantic Web effort. In summary Web services can be considered to be a specialization of World Wide Web in general a specialization that reflects the intended purpose of the exchanged information #8212 to be about services. Similarly this architecture can be viewed as an elaboration of the general WWW architecture albeit with a significant number of additional concepts. 3.6 Web services security Editorial note Please see input from Security Task Force 3.7 Scalability and extensibility According to the Web services Architecture requirements it is a major goal of the architecture that any implementations are inherently scalable and extensible. This goal is broken down into five critical success factors modularity extensibility simplicity migration from EDI and peer to peer . 3.8 Modularity The critical success factor AC002 focuses on the modularity of the architecture with appropriate granularity. This is reduced to an overall conceptual integrity with appropriate decomposition and easy comprehension. Our architecture is laid out using the simple style of concepts and relationships . This modeling technique is simple and yet allows us to expose the critical properties of Web services. A major design goal of the architecture has been the appropriate separation of concerns. In general this is achieved by rigorous minimalism associated with each concept only associating those properties of a concept that are truly necessary to meet the requirements. The overall themes in this architecture can be summarized as Web services are used and presented by agents interacting on behalf of real-world actors. Message structures service interfaces conversations are first of all explicitly identified and potentially described using using a variety of description languages. This has the effect of documenting the various aspects involved in two or more interacting Web services. Minimal assumptions about required components. For example although Web services may be documented it is not required. Similarly although descriptions may be published that is also not required. 3.9 Extensibility 3.10 Peer to peer interaction To support Web services interacting in a peer to peer style the architecture must support peer to peer message exchange patterns must permit Web services to have persistent identity must permit descriptions of the capabilities of peers and must support flexibility in the discovery of peers by each other. In the message exchange pattern concept we allow for Web services to communicate with each other using a very general concept of message exchange. Furthermore we allow for the fact that a message exchange pattern can itself be identified this permits interacting Web service agents to explicitly reference a particular message pattern in their interactions. A Web service wishing to use a peer-to-peer style interaction may use for example a publish-subscribe form of message exchange pattern. This kind of message exchange is just one of the possible message exchange patterns possible when the pattern is explicitly identifiable. In the agent concept we note that agents have identifiers . The primary role of an agent identifier is to permit long running interactions spanning multiple messages. Much like correlation an agent's identifier can be used to link messages together. For example in a publish and subscribe scenario a publishing Web service may include references to the Web service that requested the subscription separately from and additionaly to the actual recipient of the service. The agent concept also clarifies that a given agent may adopt the role of a service provider and/or a service requester . I.e. these are roles of an agent not necessarily intrinsic to the agent itself. Such flexibility is a key part of the peer to peer mode of interaction between Web services. In the service concept we state that services have a semantics that may be identified in a service description and that may be expressed in a service description language . This identification of the semantics of a service and for more advanced agents the description of the service contract itself permits agents implementing Web services to determine the capabilities of other peer agents. This is turn is a critical success factor in the architecture supporting peer-to-peer interaction of Web services. Finally the fact that services have descriptions means that these descriptions may be published in discovery agencies and also retrieved from such agencies. In effect the availability of explicit descriptions enables Web services and agents to discover each other automatically as well as having these hard-coded. 3.11 Long running transactions In CSF AC017 are identified two requirements that support applications in a similar manner to traditional EDI systems reliable messaging and support for long-running stateful choreographed interactions. This architecture supports transactions by allowing messages to be part of message exchanges and extended choreographies. It also permits support for message reliability. 3.12 Conversations Conversations are supported in this architecture at two levels the single use of a Web service and the combination of Web services. A message exchange pattern is defined to be the set of messages that makes a single use of a service. Typical examples of message exchange pattern are request-response publish-subscribe and event notification. The details of the message exchange pattern may be documented in a service description expressed in a service description language such as WSDL. In addition the architecture supports the correlation of messages by permitting messages to have identifiers. Web services may be combined into larger scale conversations by means of choreographies . A choreography is the documentation of the combination of Web services leaving out the details of the actual messages involved in each service invokation and focusing on the dependencies between the Web services. Of particular importance both to individual message exchange patterns and combined services is the handling of exceptions. Editorial note Please also consider Mark Jones's input and Geoff Arnold's stuff on synchronous/asynchronous 3.13 Message reliability Critical Success Factor AC017 of the requirements notes that the architecture must satisfy the requirements of enterprises wishing to transition from traditional EDI and more specifically AR017.1 requires that the architecture must support reliable messaging. The goal of reliability is to both reduce the the error frequency for interactions and where errors occur to provide a greater amount of information about either successful or unsuccessful attempts at service. In the context of Web services we can address the issues of reliability at three distinct levels of reliable and predictable interactions between services of the reliable and predictable delivery of infrastructure services and of the reliable and predictable behavior of individual service providers and requesters. This analysis is generally separate from concerns of fault tolerance availability or security but there may of course be overlapping issues. The architecture addresses the requirements for the highest level of reliability identified here by accomodating the descriptions of the choreographies of the interactions between Web service requesters providers. In effect reliability at this level becomes a measurable property of the descriptions of choreographies in effect assuming that the infrastracture is reliable and assuming that the services are reliable do the descriptions of the choreographies describe situations which will behave in predictable ways The reliability of the individual service providers and requesters is out of scope of this architecture as we do not comment on the realization of Web services. However reliability at this level is often enhanced by service providers adopting deployment platforms that have strong management capabilities. The reliability of the infrastracture services refers to the reliability of the messaging infrastructure and the discovery infrastructure the former is often referred to as reliable messaging. In general this refers to a predictable quality of service related to the delivery of the messages involved with the Web service. In more detail we identify two properties of message sending that are important the sender of the message would like to be able to determine whether a given message has been received by its intended receiver and that the message has been received exactly once. Knowing if a message has been received correctly allows the sender to take compensating action in the event the message has not been received. At the very least the sender may attempt to resend a message that has not been received. The general goal of reliable messaging is to define mechanisms that make it possible to achieve these objectives with a high probability of success in the face of inevitable but unpredictable network system and software failures. The goals of reliable messaging can be made more explicit by considering the issues related to multiple receptions of a message and message intermediaries. If there is an intermediary does the sender want to know whether the message got to the intermediary or to the intended end recipient Does the receiver care whether it receives a message more than once The following classification of reliable messaging expectations is taken from the ebXML Messaging Services. Duplicate-Elimination Ack Requested From End Receiver Ack Requested from Next Receiver Comment 1 Y Y Y Once-And-Only-Once End-To-End At Least Once to Intermediate 2 Y Y N Once-and-only-Once End-to-End based on end-to-end retransmission 3 Y N Y At-Least-Once at the intermediate level Once-and-only-once end-to-end if all the intermediaries are reliable no end-to-end notification 4 Y N N At-Most-Once end-to-end no retries at the intermediate level 5 N Y Y At-Least-Once with duplicates possible both end-to-end and at intermediate level 6 N Y N At-Least-Once with duplicates possible both end-to-end and at intermediate level 7 N N Y At-Least-Once to the intermediaries and the end. No end-to-end notification 8 N N N Best Effort The goals of reliable messaging may also be examined with respect to whether one wishes to confirm only the receipt of a message or perhaps also to confirm the validity of that message. Three questions may be asked about message validity Was the message received the same as the one sent This may be determined by such techniques as byte counts check sums digital signatures. Does the message conform to the formats specified by the agreed upon protocol for the message Typically determined by automatic systems using syntax constraints eg xml well formed and structural constraints validate against one or more xml schemas or WSDL message definitions . Does the message conform to the business rules expected by the receiver For this purpose additional constraints and validity checks related to the business process are typically checked by application logic and/or human process managers. Of these first and second are considered to be part of reliable messaging the last is partly addressed by Web service choreography. Message reliability is most often achieved via an acknoweldgement infrastructure which is a set of rules defining how the parties to a message should communicate with each other concerning the receipt of that message and its validity. WS-Reliability and WS-ReliableMessaging are examples of specifications for an acknowledgement infrastructure that leverage the SOAP Extensibility Model. In cases where the underlying transport layer already provides reliable messaging support e.g. a queue-based infrastructure the same reliability Feature can be achieved in SOAP by defining a binding that relies on the underlying properties of the transport. 3.14 Web service manageability Goal AG007 of the requirements identifies that manageability of Web services is an important goal of this architecture. Since the architecture defines how to define information operations and discovery of Web services it is consistent to use Web services to provide access to and manageability of Web services also. Management in this case is defined as a set of capabilities for discovering the existence availability health and usage as well the control and configuration of manageable elements where these are defined as Web services descriptions agents of the Web services architecture and roles undertaken in the architecture. This architecture does not attempt to specify completely how Web services are managed that is be the role of a separate specification. The architecture does however identify the key concepts and relationships involved in modeling manageability. These key concepts include the manageable element its management capabilities the manageability interface and the manager . For example an executing Web services agent is a potentially managable element that may require management as is an actually deployed Web service and the Web service's service description . The manager is an agent that has the responsiblity for managing on behalf of its owner and the owners of the resources that it is managing. The manager uses the manageability interface to aquire metrics of managed elements and to manage the configuration the life cycle and to monitor the status of those elements. The manager is also a prime recipient of management events . The key relationship that ensures that the architecture models management appropriately is the realizes relationship. The entities under management #8212 the manageable elements #8212 have a realizes relationship with other elements of the architecture. For example a Web service is provided by an agent . Both the Web service itself and the agent are realized in some fashion as are any descriptions of the service as physically deployed resources and those deployed resources are themselves potentially manageable. As with Web services themselves it may be important for scalability reasons for managers to be able to automatically discover both the manageable elements it may be responsible for and their manageability interfaces . Editorial note Discovery has a management aspect as well as a service aspect. This needs to be made clearer. Of course managers that are deployed in order to help the management of Web services are also potentially subject to management however to the extent that such managers are already modeled as Web services their management will be handled as any other Web service. 4 Constraints 4.1 Formats As with identifiers see section 2.2.10 Identifier the Web services architecture builds upon the definition of and architectural constraints placed on formats from Architecture Principles of the Web 7 . ... 4.1.1 XML Infoset Specifications for data formats used in the context of Web services SHOULD be based on XML Infoset 2 . XML Infoset is not a data format per se but a formal set of information items and their associated properties that comprise an abstract description of an XML document 3 . The XML Infoset specification provides for a consistent and rigorous set of definitions for use in other specifications that need to refer to the information in a well-formed XML document. Serialization of the XML Infoset definitions of information MAY be expressed using XML1.0 3 . However this is not a requirement. The flexibility in choice of serialization format s allows for broader interoperability between agents in the system. Editorial note CBF cite examples of possible alternate serializations such as compressed or binary XML. 4.1.2 XML Schema Specification of message formats structures and datatypes SHOULD be based on the W3C XML Schema Structures 4 and XML Schema Datatypes 5 specifications. Issue otherschema What about other schema languages such as RELAX NG Schematron DTD Resolution None recorded. A Acknowledgments Non-Normative This document has been produced by the Web Services Architecture Working Group The editors would like to thank Heather Kreger of IBM for her substantial contributions to this document. Members of the Working Group are at the time of writing and by alphabetical order Assaf Arkin Intalio Inc. Geoff Arnold Sun Microsystems Inc. Daniel Austin W. W. Grainger Inc. Mukund Balasubramanian Infravio Inc. Mike Ballantyne EDS Abbie Barbir Nortel Networks David Booth W3C Mike Brumbelow Apple Doug Bunting Sun Microsystems Inc. Greg Carpenter Nokia Dipto Chakravarty Artesia Technologies Jun Chen MartSoft Corp. Alex Cheng Ipedo Tom Carroll W. W. Grainger Inc. Michael Champion Software AG Martin Chapman Oracle Corporation Ugo Corda SeeBeyond Technology Corporation Roger Cutler ChevronTexaco Jonathan Dale Fujitsu Suresh Damodaran Sterling Commerce SBC Glen Daniels Macromedia James Davenport MITRE Corporation Alan Davies SeeBeyond Technology Corporation Paul Denning MITRE Corporation Ayse Dilber AT amp T Zulah Eckert Hewlett-Packard Company Gerald Edgar The Boeing Company Colleen Evans Sonic Software Chris Ferris IBM Shishir Garg France Telecom Hugo Haas W3C Hao He The Thomson Corporation Dave Hollander Contivo Yin-Leng Husband Hewlett-Packard Company Nigel Hutchison Software AG Mario Jeckle DaimlerChrysler Research and Technology Mark Jones AT amp T Tom Jordahl Macromedia Heather Kreger IBM Sandeep Kumar Cisco Systems Inc Hal Lockhart OASIS Michael Mahan Nokia Francis McCabe Fujitsu Michael Mealling VeriSign Inc. Jens Meinkoehn T-Nova Deutsche Telekom Innovationsgesellschaft Jeff Mischkinsky Oracle Corporation Nilo Mitra Ericsson Himagiri Mukkamala Sybase Inc. Don Mullen TIBCO Software Inc. Eric Newcomer IONA Duane Nickull XML Global Technologies Mark Nottingham BEA Systems David Orchard BEA Systems Srinivas Pandrangi Ipedo Mark Potts Talking Blocks Inc Fabio Riccardi XQRL Inc. Don Robertson Documentum Waqar Sadiq EDS Igor Sedukhin Computer Associates Jim Shur Rogue Wave Software Hans-Peter Steiert DaimlerChrysler Research and Technology Katia Sycara Carnegie Mellon University Patrick Thompson Rogue Wave Software Steve Vinoski IONA Prasad Yendluri webMethods Inc. Jin Yu MartSoft Corp. Sinisa Zimek SAP . Previous members of the Working Group were Mark Baker Idokorro Mobile Inc. / Planetfred Inc. Tom Bradford XQRL Inc. Allen Brown Microsoft Corporation Daniela Florescu XQRL Inc. Sharad Garg Intel Joseph Hui Exodus/Digital Island Marcel Jemio DISA Timothy Jones CrossWeave Inc. Jim Knutson IBM Mark Hapner Sun Microsystems Inc. Bob Lojek Intalio Inc. Anne Thomas Manes Systinet Joel Munter Intel Henrik Frystyk Nielsen Microsoft Corporation David Noor Rogue Wave Software Kevin Perkins Compaq Darran Rolls Waveset Technologies Inc. Krishna Sankar Cisco Systems Inc Scott Vorthmann TIBCO Software Inc. . B References Non-Normative B.1 Normative References 1 IETF RFC 2396 Uniform Resource Identifiers URI Generic Syntax T. Berners-Lee R. Fielding L. Masinter August 1998 See http //ietf.org/rfc/rfc2396.txt. 2 XML Information Set W3C Recommendation eds. J. Cowan R. Tobin 24 October 2001 See http // w3.org/TR/xml-infoset/. 3 Extensible Markup Language XML 1.0 Second Edition W3C eds. T. Bray J. Paoli C.M. Sperberg-McQueen E. Maler. 6 October 2000 See http // w3.org/TR/REC-xml. 4 W3C Recommendation quot XML Schema Part 1 Structures quot eds. H. Thompson D. Beech M. Maloney N. Mendelsohn 2 May 2001. See http // w3.org/TR/xmlschema-1/. 5 W3C Recommendation quot XML Schema Part 2 Datatypes quot eds. P. Biron A. Malhotra 2 May 2001. See http // w3.org/TR/xmlschema-2/. B.2 Informative References 6 Web Services Architecture Charter See http // w3.org/2002/01/ws-arch-charter. 7 DRAFT Architecture Principles of the World-Wide Web Ian Jacobs 30 August 2002 See http // w3.org/TR/2002/WD-webarch-20020830/. 8 SOAP Version 1.2 Part 1 Messaging Framework Working Draft eds. M. Gudgin M. Hadley N. Mendelsohn J. Moreau H. Nielsen 7 May 2003 See http // w3.org/TR/2003/PR-soap12-part1-20030507/. 9 SOAP Version 1.2 Part 2 Adjuncts Working Draft eds. M. Gudgin M. Hadley J. Moreau H. Nielsen 7 May 2003 See http // w3.org/TR/2003/PR-soap12-part1-20030507/. 10 SOAP 1.2 Part 0 See http // w3.org/TR/2002/WD-soap12-part0-20020626/. 11 SOAP 1.2 Part 0 See http // w3.org/TR/soap12-af/. 12 SOAP Messages with Attachments See http // w3.org/TR/SOAP-attachments. 13 XML Protocol XMLP Requirements W3C Working Draft 26 June 2002 eds V. Apparao et al. See http // w3.org/TR/2002/WD-xmlp-reqs-20020626. 14 XML Protocol Usage Scenarios See http // w3.org/TR/2001/WD-xmlp-scenarios-20011217/. 15 Web Services Description Language WSDL Version 1.2 Working Draft eds. R. Chinnici M. Gudgin J. Moreau S. Weerawarana See http // w3.org/TR/wsdl12/. 16 Web Services Architecture Requirements Working Draft eds. D. Austin A. Barbir C. Ferris S. Garg See http // w3.org/TR/wsa-reqs. 17 Web Services Glossary W3C Working Draft 14 May 2003 eds. A. Brown H. Haas See http // w3.org/TR/2003/WD-ws-gloss-20030514/. 18 Web Services Architecture Usage Scenarios Working Draft eds. H. Haas D. Orchard See http // w3.org/TR/2002/WD-ws-arch-scenarios-20020730/. 18 Message Service Specification ebXML Message Service Specification Version 2.0 See http // ebxml.org/specs/ebMS.pdf. 19 Web Services Routing Protocol WS-Routing See http //msdn.microsoft /library/default.asp url=/library/en-us/dnsrvspev/html/ws-routing.asp. 20 XML Key Management Specification XKMS 2.0 W3C Working Draft 18 March 2002 eds. Phillip Hallam-Baker VeriSign See http // w3.org/TR/2002/WD-xkms2-20020318/. 21 XML-Signature Syntax and Processing W3C Recommendation 12 February 2002 eds. D. Eastlake J. R. D. Solo M. Bartel J. Boyer B. Fox E. Simon. See http // w3.org/TR/2002/REC-xmldsig-core-20020212/. 22 XML Encryption Syntax and Processing W3C Proposed Recommendation 03 October 2002 eds. D. Eastlake J. Reagle See http // w3.org/TR/2002/PR-xmlenc-core-20021003/. 23 Web Services Security Specification Working Draft 03 November 2002 See http // oasis-open.org/committees/wss/documents/WSS-Core-03-1103.pdf. C Architectural Use of Technologies Non-Normative As previously stated a Web services interaction is two or more software agents exchanging information in the form of messages using a variety of Message Exchange Patterns MEP . A very common Message Exchange Pattern for Web services is the Request Response MEP. A sender sends a request to a receiver and the receiver responds. The data that is exchanged in the request or the response is usually XML carried over an underlying transport or transfer protocol such as HTTP. The XML can be XML Element/attribute syntax or it can be defined as an XML Infoset or it can be information solely in the underlying protocol. An example of this is an HTTP GET request that does not contain an XML message but the response may carry an XML message. SOAP provides an extensible framework for the XML data that is interchanged. The format that SOAP defines has restrictions and places of extensibility. The Web Services Description Language WSDL provides a format for defining the allowable formats for messages to and from agents. These include SOAP XML MIME and simple HTTP requests. Many quot real quot products and projects are successfully using SOAP and WSDL and it is clear that a critical mass of knowledge and technology are forming around them and they will remain at the center of the web services architecture. Nevertheless there are numerous architectural questions that remain unsolved or at least whose solution is not widely agreed upon. These include Integration with the Web - SOAP 1.1 web services use the HTTP infrastructure to move messages around and allow standardization of the format of the payload of a POST command but conventional Web applications are not able to directly access most web services. In particular it is not possible to hyperlink to SOAP 1.1 web service via HTML links XSLT document functions etc. As many critics have noted hyperlinks are the very essence of the World Wide Web and this limitation is quite severe. SOAP 1.2 addresses this issue at a technical level but there is little architectural guidance available as to when and how to use the various HTTP-friendly and protocol-neutral aspects of the SOAP protocol. Extension mechanism - SOAP 1.2 provides an extension mechanism via headers but the implications such as when to use XML markup in the body of a message when to use headers are not spelled out. Likewise it is not clear how SOAP-based protocol extensibility would interoperate with or complement traditional Web applications. Overall understanding of modules and layering - SOAP 1.2 provides a framework within which additional features can be added via headers but there is little agreement on the specific categories of functionality that these headers will specify nor on specific format standards. Detailed objectives are laid out in the accompanying Requirements document WSAREQ but at a high level the W3C Web Services Architecture is intended to Integrate different conceptions of web services under a common quot reference architecture quot . There isn't a simple one to one correspondence between the architecture of the web and the architecture of existing SOAP-based web-services but there is a substantial overlap and the Web Services Architecture needs to identify what they have in common and how they differ. Describe the quot best practice quot for the set of rules that existing Web service agents typically follow and to rationalize the best practices from the different communities. The objective is not to say quot this practice is good quot or quot that practice is bad quot but rather to say quot this specific approach is brittle in the following ways. quot or quot That common practice works better if X occurs as well as Y. quot Prescribe a framework for the future evolution of web services standards that will promote a healthy mix of interoperability and innovation. That framework must accommodate the edge cases of pure SOAP-RPC at one side and HTTP manipulation of business document resources at the other side but focus on the area in the middle where the different architectural styles are both taken into consideration. It is a non-objective to resolve all of the profound disagreements that Web services theorists and practitioners continue to have over the concepts and technology in the shared area. The W3C WSA will accomodate divergent opinions on whether various services should be implemented at the application or infrastructure level whether it is appropriate to quot tunnel quot remote procedure calls over HTTP etc. Similarly it is unrealistic to expect the W3C Web Services Architecture to define a set of quot Lego blocks quot that can be snapped together to build real applications. That is a reasonable vision for the Web services industry but it will require considerable research experimentation and standards-building to achieve. This reference architecture is intended to help clear the way for these activities by forming a consensus on what the basic types of components might be the ways in which they relate to one another and what to name them. D Web Services Architecture Change Log Non-Normative 20030419 dbooth Refactored document Wrote/reworked Introduction 20021202 DBO Incorporated f2f changes from the first morning - use of agents duplicate diagrams document overview - and the correlation/reliability feature summary 20021114 CBF incorporate MTF overview proposal. merged with daveo's changes based on 11/13/2002 f2f session. 20021029 CBF tweaked intro per Hugo's suggestion/comment. 20021028 CBF incorporated Jean-Jacques' and Hugo's comments on description. amended status and abstract. some restructuring of the references and appendicies. 20021025 CBF incorporated Heather's description prose. Incorporated Hugo's comments 20021024 CBF incorporated feedback from Joel Munter and some from Jean-Jacques Moreau. 20021022 CBF incorporated revised graphics 20021020 CBF incorporated Eric's section 1.2 updates. Converted to xmlspec-v2.2. 20020720 CBF incorporated SOAP harvest weaved into the revised flow. added normative biblio. 20020604 DBO Initial Rev Web services architecture and design Activate your FREE membership today #124 Log-in Java SOA EBIZQ Test/QA .NET AJAX TSSJS Today On TSS Discussions Topics White Papers Multimedia RSS Design/Architecture SOA and service integration REST Web services ESB products Software development Application Integration middleware Application security Design for test Data-oriented design Java architecture for cloud EJB EJB specification EJB containers EJB troubleshooting EJB programming Java application servers EJB products Web Services Web services architecture WS* specifications Web Applications Web app frameworks Spring framework Hibernate framework Java servlets Java server pages Ajax Web development Rich Internet applications Java server faces Java Web portals Other UI Development Java programming language Software programming languages JVM languages DSLs Java application deployment Performance/Scalability Software performance tools Application performance measurement Cloud/grid/memory systems JVM Application scalability Tools Eclipse development and tools Open source tools IDEs Java EE Java software testing Development hardware SEARCH this site and the web Site Index Home gt Topics gt XML and Web services applications gt Web services architecture and design Email This Java Development Topics Topics Home Browse All Java Topics RSS Feeds Web services architecture and design Web are services usually including some combination of programming and data but possibly including human resources as well that are made available from a business' Web server for Web users or other Web-connected programs. Providers of Web services are generally known as application service providers. Web services range from such major services as storage management and customer relationship management CRM down to much more limited services such as the furnishing of a stock quote and the checking of bids for an auction item. The accelerating creation and availability of these services is a major Web trend. Learn about Web services architecture and design trends in this section. News 1 #45 3 of 21 Working with ActiveMQ – Tips from TSSJS presenter Jeff Genender TheServerSide #124 25 Feb 2011 News - ActiveMQ is one of the most popular open source JMS containers available today. At the TSSJS this March in Las Vegas architect Jeff Genender will discuss architecture issues in implementing the ActiveMQ message broker in enterprises including common... Red Hat JBoss releases new module for Seam 3 Framework 30 Mar 2010 News - Red Hat JBoss recently released a new module for its Seam 3 Framework Seam XML 3.0.0 Alpha 1. The XML module uses XML-based bean declarations for defining additional beans or augmenting the beans defined via annotations. SAML It's Not just for Web services 28 Sep 2009 Article - SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Today many organizations debate... VIEW ALL News ON Web services architecture and design Expert Technical Advice 1 #45 2 of 2 Building Java Web services with NetBeans 7 28 Apr 2011 Tip - In this tutorial I'll walk through building a simple Web service with NetBeans 7. Let's see just how far the Java specification and the tools that support the spec have come. JSON-RPC VS JAX-WS 18 Nov 2010 Tip - What is the best web service solution JAX-WS Sorry I don't agree VIEW ALL Expert Technical Advice ON Web services architecture and design SEARCH About Us #124 Contact Us #124 For Advertisers #124 For Business Partners #124 Site Index #124 RSS TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of technology-specific websites events and online magazines . TechTarget Corporate Web Site #124 Media Kits #124 Reprints #124 Site Map All Rights Reserved Copyright 2000 - 2011 TechTarget #124 Terms of Use #124 Read our Privacy Statement TechTarget - The IT Media ROI Experts Home Services Contact Axure Libraries The Archives Browse the content below to find what you're looking for. Information Architecture IA #038 The Social Network Monday April 19th 2010 Information architecture IA is the approach you take to structure and navigation on your website. The IA model that you choose will have an impact on how you design your site. For some websites this is as simple as choosing to put all your content on a single homepage. For a social network’s IA a more sophisticated approach is needed. Flat The flat IA model is where you have more than one page and each page is granted equal importance. You can go from one page to another page in a single click. This method can also be called monocline grouping. See below. This type of hierarchy is too rudimentary for a social networking website. If you have a simple social network where each user is given their own profile page your website could have millions of links on each and every page. While a flat structure may be suitable for a simple brochure website it is not suitable for a social network. Index The index structure is the web equivalent of a directory. The homepage acts as the index navigating you to the right page within the directory. See below. This model could work well for a social network with a small number of users. However information architects must consider scalability. A pure index hierarchy is not built to scale. For a phone directory with a few hundred entries this could work. For a social network with 10 000 users it would be a disaster. Strict Hierarchy The strict hierarchy looks like an organizational chart in most large companies. People report to their boss and their boss reports to their boss. Management links to lower level employees via their managers. In the web architecture example you access a lower level page via its parent. See below. This structure is more suitable for social networks than the previously discussed models. To consider its application let’s imagine a social network that facilitates communication among a golf club’s members. There could be a separate parent category for male and female golfers. You could drill down from home gt male golfers gt Name Surname to find the person you are looking for. What happens if you want to expand the categories beyond male and female golfers and add another category for “competition winners” In that case competition winners would need to be a member of a gender category and a member of the “competition winners” category. This would not be possible with a strict hierarchy since each file has only one parent. For this reason a strict hierarchy will usually lead to usability problems on more complex social networks. Multi-dimensional Hierarchy Most social networks other than the most primitive must opt for a multi-dimensional hierarchy to achieve their usability and navigation goals. See below. The multi-dimensional hierarchy embraces the nuance that a strict hierarchy ignores. In the golf club example golf members have relationships with one another. A golfer can be a “male” and a “competition winner” and have friends who are “male and “female”. You can move from one golfer #8217 s profile to another directly if they are friends. Profiles possess multiple properties and can be filed in more than one place. This adds flexibility to navigation and allows users to follow more than one path to achieve the same objective. Search Search has become fundamental to understanding the architecture of many of today’s leading websites. Google clearly would be unusable without search functionality. Twitter does not rely on search to be functional but it adds a whole new dimension to their social network. Without search users would exist in pockets of followers connected only by disparate connections. Search adds a discovery mechanism to content and people. On some social networks search acts as a means of short-circuiting the hierarchical structure. In others search makes hierarchical structures superfluous. Search usually works in one of two ways in a social network. It allows you to search within a particular parent or it allows you to search across parent to find profiles. And sometimes you can do both. Posted in Web Architecture 2 Comments #187 Website Navigation Models For Social Networking Websites Monday April 19th 2010 Intro There is no right or wrong navigation model for a social networking website. Social networks usually combine more than one method in their website architecture providing a choice for website users. Too much choice can risk causing confusion and cluttering your design. In this article we shall guide you to choosing an intuitive and attractive website navigation model for your social network. From their experiences elsewhere on the web website users have engrained views on how your website navigation should work. Consider this when formulating your navigation model and reduce the friction involved in navigation. Breadcrumb Trail Breadcrumb trail navigation lets you know where you are in the hierarchy of a website. In the example below you know you are inside News gt World news gt United States. This allows your website users to know where they are in a website and provides a navigational shortcut to skip back. Know where you are at all times. Move back steps with minimal interruption. Great for social networks when You present structured data. Your schooling listings might present USA gt Illinois gt Colleges gt Illinois College gt Illinois College ’05 gt Philip West. Users can easily navigate away from Philip West’s profile back to others who graduated in the same year Illinois College ’05 or even back to “Colleges” if they wish to find a friend who attended another college. You want to increase page views by encouraging visitors to check out similar categorizations. Horizontal Top Bar Horizontal top bars are among the most common navigation models used on all websites including social networking websites. Here is an example of a simple horizontal top bar used on Twitter. While website users are comfortable browsing vertically they are less comfortable browsing horizontally. Try to keep this is mind when formulating your navigation – make sure the number of links is known in advance. Adding friends applications or switching on options should not add more links to a horizontal top bar unless this has been tested and creates a comfortable browsing experience. Users are comfortable using a horizontal top bar due to their widespread adoption. Do not include “dynamic” options that could cause the website to expand horizontally in the browser. Great for social networks when You want to create an easy and simple method of navigating to key tasks that users perform on your network. Horizontal Top amp Vertical Side Bar A top and side bar method is deployed on most prominent social networks. Usually the top bar will be used for top-level navigation while the side bar will allow users to access sub-categories. The side bar will be used for any conditional or dynamic links. It is easier to add additional links vertically but you must be more careful when adding additional links horizontally. This is the method favored by Facebook. Use top bar for top-level navigation Use side bar for drilling down sub-categories and expanding navigation options. Great for social networks when You need to add “dynamic” links and expand navigation options. You want to leverage an approach that users will feel comfortable with through their experience on other social networking websites. Horizontal Top Bar With Revealed Drop Downs This has become an increasingly popular navigation method which comes with some variations. Sometimes you click on a menu and a further sub-menu or link is revealed. In other occasions simply hovering over the menu causes this to be revealed. One advantage of this method is space efficiency. The menu takes up little room and it can provide an intuitive method of navigating social networks with a deep structure. While this has become an increasingly popular navigation method it also has some serious downfalls. Not least a lack of familiarity with the approach can cause confusion. For those with disabilities or poor IT literacy it can cause difficulties. Another issue arises from users being unaware of what is below a particular menu option until they hover over it. In the example below Myspace has deployed this method. This can be a great way to optimize space efficiency. There are some usability concerns with this approach. Great for social networks when You prefer an interface focused around a horizontal top bar but your site is too big to accommodate all links within the main menu. Paging This is a method used by social networks where content spans several pages. News websites will sometimes use this method to break up larger articles. Social networks often use this approach to browse through profiles and present search result pages. Look at the example below on Myspace. This allows users to skip back and forward between results and browse from start to finish easily. When your social network displays search results this can be the most intuitive way to present them to your users. Paging is ideal for presenting search results. Allows users to skip back and forward easily. Great for social networks when You wish to structure large amounts of content in a list format unsuitable to fit on one page. Let’s say a user can see a list that is sorted in date format and they want to find the oldest data in the list. They know they can go to the last page to quickly find what they are looking for. Tabs Tabs are usually a type of horizontal navigational bar although they can be used in other settings too. They serve to make it easy for the user to know the section of a network they are on. Tabs have rapidly became a major feature of web browsers so users are now increasingly comfortable with their use. In the example below check out how Linkedin uses tabs. Tabs clearly distinguish the page or section of a social network a user is currently visiting. The popularity of using tabs within website browsers has made users more comfortable with the concept. Great for social networks when You want to create a clear distinction between different sections of your network. Users know they cannot be active on more than one tab at once. Posted in Web Architecture No Comments #187 Site Structure for Humans and Search Engines Wednesday April 14th 2010 Most website designers put the focus of creating a website only on its visual appeal. While this is certainly important focusing on how easy the website is to use how simple it will be to change and expand in the future and how search engine friendly it is can be even more important in the process of creating a successful website. Building a website keeping these issues in mind depends on a designer well versed in site architecture. Under the creation of a web architect websites achieve just the right balance between visual appeal ease of use functionality and search engine friendliness. Think of web application architecture as being similar to the constructing a building. While beauty is important strength and function make the building usable and long-lasting. Drafting site architecture involves using the information gathered for your website. Although in digital form these architectural structures resemble construction blueprints also called skeletons. The goal of this phase is categorizing organizing and prioritizing how users will navigate through your website. Good web application architecture involves making your website easy to navigate through site mapping task flows and wireframes. This results in a user centered website that saves money and produces results. Site Map Like a business organizational chart a site map is a visual way of showing the organization of your website. In this step a web architect names and arranges the pages of your website in a way that makes sense to both human users and search engines. Task Flow Similar to a site map a task flow also shows how users will navigate your website. For example a site map shows a block that represents the #8216 contact us #8217 page but a task flow shows what happens if the user interacts with that page. If they submit a contact form from this page where will they go next What happens if they experience an error Site architecture plans for every option. Wireframe A grayscale digital skeleton a wireframe helps a web architect visualize the layout of your website pages. Placeholder headlines subheadings text images navigation advertising and other content show where information will appear when users view your website. Posted in Web Architecture No Comments #187 What is Website Architecture Wednesday April 14th 2010 Website architecture is the organization and structure of website information. It is a phase that begins after a website plan has been documented but before the website is developed. If your website had proper planning before starting to draft the architecture you will already have a clear idea of 1 website objectives 2 content requirements and 3 user groups. These three components tell an informational architect what is required in order to produce a digital structure that will meet the needs of both the business and the website users. Website Objectives Website objectives help architects prioritize information. They are measurable goals that answer the question “What will the website accomplish” More clearly what the website will accomplish for the business. Will the website spawn a 15% increase in leads Generate 25% more sales Create $100 000 in new subscriptions within the first year Help gather feedback 50 times faster from users of your products and services Cut business costs 5% by automating processes Whatever the objectives they need to be defined clearly in a quantifiable time conscious statement. User Groups User groups describe who will use the website. They help architects categorize informational architecture in a way that humans can understand. Will the users be shoppers researchers investors donors potential members and/or potential employees Depending on time and budget these user groups can be further developed into individual user profiles or personas that help the website architecture empathize with the user. This results in a deep understanding of who primary users are and what content they want. Content Requirements Content requirements are detailed statements that answer the question “What will the website do ” This helps the architect organize the informational architecture in a way that meets the needs of the business website users and the search engines. Will the website need a checkout process that can be completed in one step Will the business need a way to recover abandoned orders Will users want to track their orders Will the search engines need to be blocked from indexing SSL pages and printer friendly pages to avoid duplicate content issues Content requirements align with website objectives and user groups to define this final component. It’s at this point that the job of website architecture begins. A website architect uses the components gathered above to start shaping connecting and forming the informational architecture. Making your website easy to navigate is a process that involves site mapping task flows and wireframes. Site Map A site map is a lot like a business organizational chart. It’s a visual way of showing how the website will be organized. In this step website architecture gives names to pages and arranges them in a way that makes sense to human users and the search engines. Task Flow A task flow is like a site map but also shows how users will navigate the site. For example a site map would show a block that represents the Contact Us page but a task flow shows what happens if the user interacts with that page. If users submit the Contact Us page where will they go next What if they experience an error Wireframe A wireframe is a grayscale digital skeleton that helps visualize how website pages will layout. Placeholder headlines subheading text images navigation advertising and other required content will be added to show the informational architecture users will view when visiting the website. An organized and structured website begins with creating a website architecture before development begins. By knowing the objectives content requirements and user groups you can produce an informational architecture that includes a site map task flow and wireframe that ensures a website meets the needs of both the business and the website #8217 s users. Posted in Web Architecture No Comments #187 Web Architecture Benefits Pros of Planning Architecting and Prototyping Wednesday April 14th 2010 Web architectures have pros and cons but the benefits far outweigh the downfalls. In this article I will use the term #8216 web architectures #8217 in the broader since including defining the website plan drafting web architectures and designing the web prototype. Benefits Clarifies Fuzzy Ideas Website ideas are loose concepts that are a great jumping off point. Yet the goal of internet development planning is to define clear requirements. So by really digging into an idea you help uncover a solution that works. Defines Measurable Goals Websites need to make money and web architectures achieve this. When information architects understand the goals of your business they guide the creation of navigation when drafting and prototyping during internet development planning. Satisfies User Needs A website also needs to be useful. Websites that provide value in the form of content that is useful make people happy. Successful internet development planning focuses on making users happy. Web architectures allow the creator to think like a user. Therefore content is categorized prioritized and shaped in a way that makes sense. Saves Money amp Time This sounds cliché but architecting out a clearly defined drafted and prototyped website structure helps you get accurate quotes and timelines from developers. You can even present your plans to multiple companies without having to explain yourself to death. It’s all documented and digitally structured so there are no inflated quotes. Sells Your Idea Your website might be a multi-million dollar project that requires you to pitch your ideas to investors. Maybe you don’t have the budget to develop your website this year but want to make sure decision makers allocate enough funds next year. Web architectures provide a visual prototype that sells your idea because others can see and interact with your vision. Test Your Concept Before It Goes To Market Web architectures encourage usability testing and user acceptance before it’s too late. Testing your website prototype with real people who fit your target audience helps validate your design. If there are obstacles changes can be made quickly to a prototype during the internet development planning phase. It’s Productive Web architectures are efficient. As mentioned a moment ago changes are made much faster at this stage. Implementing solutions is quicker because it is free of complex programming and detailed graphics. Downfalls The thought of internet development planning architecting and prototyping can seem unnecessary. This is partially true. Depending on the type of website you are creating you might not have to get so detailed in the wireframe and prototyping phase. Doing It All Can Be Redundant If your website doesn’t require the user to perform a lot of tasks low interaction then you could get by with just internet development planning creating a site map and some light wireframing. This will be more efficient. If your website requires a lot of interaction but doesn’t present a lot of information to organize less time can be spent structuring information Color Wastes Time Another downfall can occur when colors are added to the wireframe or prototype. Color should be left to visual designers in the development phase. Colors slow down the process and lead to tangents that have nothing to do with architecting. Web architectures are about function rather than the formation of color. Functionality Isn’t Perfect Functionality of prototypes isn’t perfect. Although it’s a real representation of what you want your website to look like it will not function perfectly. Prototypes simulate how users navigate and interact with elements but this experience isn’t always true to how it will work when it’s live on the internet. Conclusion As stated at the beginning the benefits of web architectures far outweigh the downfalls. Web architecting is a necessary tool although it needs to be used correctly to be efficient and effective. Posted in Web Architecture No Comments #187 AtomicLabz Sidebar Components Tuesday April 6th 2010 Over the past few posts I’ve discussed global components components homepage design internal page design and style guides. Today I’ll end by discussing the sidebar and give you some ideas on how to use them effectively. The majority of websites have sidebars on their internal pages. Sometimes there on the left other times they are on the right. Sometimes there are two sidebars with the content in the middle. I’ve even seen layouts with two sidebars on the right with the content on the far left. My personal favorite is to use a two column layout on internal pages with the sidebar on the left or right. In the following example you’ll see a right sidebar. The sidebar is going to consistent yet different for every page. This consistency will be in the sub-navigation that is directly related to the primary navigation. The sub-navigation will remain in the same location top of sidebar on every page but the links will be different on each secondary navigation component. Sidebar Components Solutions – This secondary navigation will show when user click on solutions in the primary navigation and this navigation will show for each page within this section. Company – Similarly when users click on company in the primary navigation and this navigation will show for each page within this section. Company – What’s nice about this is website owner can easily add pages to these section in the future without causing technical problems. News and Events – shows news articles upcoming events and past events. I’ll show you how there are other components below each of these subnavigations. Blog – is different. I’ve made a slight compromise by including a search field just above the secondary navigation. Knowing that this could be a large section I wanted to make sure website user had a way to find the information they are looking for quickly. Categories are a way for the user to help organize their subject matter and archive is a dynamic component that will archive blog post by month. There are additional components we could have added to the sidebar for blog but decide to keep it simple for now. Additional Components After the obvious basics you may want to include other components below the primary components of the sidebar. For example Upcoming Events Calendar – Can be a nice touch if you have a lot of events and you want to give users a way to navigate to events at specific times. This would of course link them to the events happening on the day they select. This would be a nice component to sit below the New and Events secondary navigation. White Paper Download – meets an objective for our client. His objective is to collect information from potential prospects. This white paper download links to a landing page describing the value of downloading the white paper. This might be a nice component to sit below the sub-navigation on the solution page. Sales Training Newsletter – is yet another way to collect information from interested parties. Only this will be a retention tool to keep user coming back to the website. This links to a landing page that describes the benefits of signing up. This component can will be a nice touch to add in the sidebar of any page below the other components. Contact Information – works best as a sidebar component on the Contact page sitting just below the secondary navigation. Conslusion The sidebar components mentioned help users effectively navigate your website content and lead them to taking action. Other sidebar components that are very good are credibility factors. If you want to lower the website user’s anxiety and demonstrate value you may want to create components for that. Examples might be testimonials organizations you are associated with certifications you have etc… It’s important to know what you want before the programmers start coding. Some of these components will be dynamically driven and some will be wigitized for used individually within certain pages or page template. Thinking ahead will make the website management process much more satisfying to the website owners. They will be able to easily rearrange component order and target components to specific sections if programmed right. Posted in Web Architecture No Comments #187 AtomicLabz Style Guide Tuesday April 6th 2010 Over the past couple posts we’ve cover how I prototype a corporate website architecture. We’ve looked at the atomic elements global components components corporate homepage design and briefly covered internal page structure. Today I want to talk about the style guide. Website Style Guide The website style guide is an important part of every website. It will keep the formatting of each page consistent throughout the entire website. I doubt I have to explain the benefit of a style guide. What’s awesome about it though I try to style as many common HTML elements as you think the website administrator will need to manage content effectively on each page. When the prototype is passed onto the design team they will know exactly what to build into their css style sheet and this will also let the programmers know what to build into the WYSIWYG rich text editor. This will help us build search engine friendly pages that are easy to format for website owners and also easy to change colors and font properties across all pages if needed. Headings H1 h2 h3 and h4 are headings that are show in the style guide. Each have different font sizes colors and styling to make the website more readable when being read by visitors. User like to scan page heading looking for the information they are interested in and using different font properties helps organize the page content. When the website owner is adding content to their WYSIWYG editor they will just have to select h1 h2 h3 or h4 from the drop list to format the text properly. Paragraph Text Paragraph text is the body text that is consistent throughout all pages in the main body area. This is the default text that will show when a website owner is writing text in their WYSIWYG rich text editor. Lists At some point the website owner will want to create an unordered list or an ordered list. An unordered list is a bullet point list. Ordered lists are numbered list 1 2 3 4 as opposed to bullets. Blockquotes Blockquotes are HTML elements that are smart to stylize so the website owner has an opportunity to make quotes really stand out. They can be used to emphasize main points on a page show testimonials client stories and more. Alerts Alerts are smart to think of ahead of time. They will be used for confirmation messages error messages or even notes / tips that stand out from other content. The confirmation or success message is something a website visitor would see after filling out a form. If they didn’t fill out the form properly they would see the error message. The note alert is a component that the website owner might want to use to make sure the reader knows something about the page before continuing to read. It could also be a tip download or did you know area that stands out front the surrounding text. Footnotes Footnotes are great for giving credit to sources throughout your text. If the website owner quotes a source when writing content they can add a superscript to the sentence e.g. you have three seconds to attract a website visitors attention 1 . Now in the future you can use an ordered list to quote the source at the bottom of the web page. In the next article I’ll be discussing the sidebar why it’s important and how you can use it effectively. Posted in Web Architecture No Comments #187 AtomicLabz Homepage and Internal Page Components Tuesday April 6th 2010 I previously discussed global components. In this post I’ll converse about some of the other elements that make AtomicLabz homepage. Also we’ll look at the internal page structure. Carousel A carousel is like a rotating billboard that consists of a background image and text that will lead the visitor into an internal page. This I a great sport for product promotion upcoming events hot deals new arrivals or a featured product/service. The user can navigate back and next using the navigation located in the bottom right. As each picture fades in a circle in the bottom right changes color showing the user which they are viewing. They can also click the circle to navigate to that specific billboard. Site Introduction An introduction sits below the carousel and quickly introduces the customer to you and what your site offers. You need to quickly let the user know what you do. Website users are thinking “is this where I want to be Do they have the solution Can I trust them ” This can be a great spot to introduce credibility factors sample client list testimonials service and product offerings . It really depends on what your objective is. You can see the layout nicely flow from a one column carousel to a three column introduction that is pleasing to the eye. In this case we used two of the columns to introduce the client to service offering client case studies. The third column was a call to action inviting the user to download a white paper Driving Sales in a Down Economy. Subpage / Internal Web Page Next it was onto the internal page. The internal page has a consistent structure through the entire website. Of course the body contents changes relative to the page you are viewing and the right sidebar changes for each section. The first component in the right sidebar is the secondary navigation or sub-navigation for all page related to the primary navigation selected. In this scenario the user clicked on Solutions in the primary navigation which leads the user to the first page in the solution section named Lead Generation . In my prototype I didn’t set the Solution button in the primary navigation to red although that is how it would look when programmed to let the user know that is the section they are viewing. You also see in the right sidebar that Lead Generation is red different then the other sub navigation pages letting the user know which page they are viewing. Throughout every section the secondary navigation will also remain in the top right corner. Although if we get to a section that requires searching i.e. a blog then I would sacrifice a bit and put a small search box just above the sub navigation. Calls to Action The other two components of the sidebar are calls to action. The goal of this website is to collect information from potential clients. To do this we’ve include a white paper download and a sale training newsletter sign-up that lead to landing page stating the value of signing-up. Today we covered a lot so I’ll save the Style Guide for the next post as that is a significant component of every design. Posted in Web Architecture No Comments #187 AtomicLabz Components and Homepage Wireframe Tuesday April 6th 2010 I already discussed the site map with the project stakeholders in my previous meetings and they approved. Next it was onto wireframeing some of the atomic elements and global components. Atomic elements cannot be broken down any further. An example might be H1 Text paragraph text or a logo. Components are made up of atomic elements but their relationship with each other groups them together into single components. Some of these components I knew would be global show up consistently on each page and some would be page specific. I like to start with the global components first. Global Components Header The header consists of three elements Logo Value Proposition and Call to Action. These three elements make up the header component and will show up consistently on every page. The logo is a clickable link that leads the website user back to the homepage. Value Proposition is a clear statement that tells website visitors what this site is about and how they unique. The call to action is a phone number. The goal of this site is to generate leads so why make it difficult for users to find the phone number when they are ready to act Primary Navigation The primary navigation is the menu users will interact with to find information they are interested in. As mentioned I had developed a site map so I had a good idea of how I wanted the navigation to flow. This site is not going to be hundreds of pages so I decided to eliminate the use of drop-down navigation. I personally don’t like to use. If there are sub pages I like to include them within their specific section so they are always displaying to users. I don’t like to keep making users hunt for things. I also don’t like creating more than seven menu items in the primary navigation and is this illustration I was able to make six menu items work. You’ll notice that the homepage show a different color that the other buttons because the homepage is active or currently being viewed. The other five buttons are inactive but change color on hover . Footer I won’t spend a lot of time on this but the footer section contains some of the standard utility page site map privacy policy terms of use that can are important for legal purposes and also valuable for search engine positioning. I know some sites or directories won’t even link to your site if you don’t have these elements in place. I also included links to the main service page that are keyword rich text links leader generation sales consulting and sales training . In the copyright I always like to use a dash followed by keywords that are linked to the homepage as well. Today I covered global components and next will discuss other components including sub-navigation on internal pages style guide and all of the other components that make up the homepage wireframe. Posted in Web Architecture No Comments #187 Categories Axure Widgets Mobile Uncategorized Web Architecture Web Prototyping Web Usability Website Planning Tags atomic elements atomiclabz components homepages ideas rivalryrage site maps sitemaps social networking style guides subpages wireframes Recent Quick Sketches For iPhone Architecture Style Guides – Axure Widget Library File Advertising Web Ads #8211 Axure Widget Library File Rivalry Rage Website Plan Prototype Your Social Network Website Design Join IXDA Minneapolis Home Blog © 2010 All Rights Reserved Web Biz Networks LLC Web This Site Learn Web Services Web Services HOME What are Web Services Why Web Services WS Characteristics WS Architecture WS Components WS Examples WS Security WS Standards What is Next Selected Reading Computer Glossary Who is Who copy 2011 TutorialsPoint.COM Home References About TP Advertising Web Services Architecture There are two ways to view the web service architecture. The first is to examine the individual roles of each web service actor. The second is to examine the emerging web service protocol stack. 1. Web Service Roles There are three major roles within the web service architecture Service provider This is the provider of the web service. The service provider implements the service and makes it available on the Internet. Service requestor This is any consumer of the web service. The requestor utilizes an existing web service by opening a network connection and sending an XML request. Service registry This is a logically centralized directory of services. The registry provides a central place where developers can publish new services or find existing ones. It therefore serves as a centralized clearinghouse for companies and their services. 2. Web Service Protocol Stack A second option for viewing the web service architecture is to examine the emerging web service protocol stack. The stack is still evolving but currently has four main layers. Service transport This layer is responsible for transporting messages between applications. Currently this layer includes hypertext transfer protocol HTTP Simple Mail Transfer Protocol SMTP file transfer protocol 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 layer 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 Web Service Description Language 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 Universal Description Discovery and Integration UDDI . As web services evolve additional layers may be added and additional technologies may be added to each layer. Next chapter explains about various components of Web Services. Few Words about Service Transport The bottom of the web service protocol stack is service transport. This layer is responsible for actually transporting XML messages between two computers. Hyper Text Transfer Protocol HTTP Currently HTTP is the most popular option for service transport. HTTP is simple stable and widely deployed. Furthermore most firewalls allow HTTP traffic. This allows XMLRPC or SOAP messages to masquerade as HTTP messages. This is good if you want to easily integrate remote applications but it does raise a number of security concerns. Blocks Extensible Exchange Protocol BEPP One promising alternative to HTTP is the Blocks Extensible Exchange Protocol BEEP .BEEP is a new IETF framework of best practices for building new protocols. BEEP is layered directly on TCP and includes a number of built-in features including an initial handshake protocol authentication security and error handling. Using BEEP one can create new protocols for a variety of applications including instant messaging file transfer content syndication and network management SOAP is not tied to any specific transport protocol. In fact you can use SOAP via HTTP SMTP or FTP. One promising idea is therefore to use SOAP over BEEP. Advertisement Online Image Processing Indian Baby Names Skip to main content Sign in or register English userid Close x If you don't have an IBM ID and password register here . IBM ID Password After sign in Stay on the current page My developerWorks profile My developerWorks home Keep me signed in. By clicking Submit you agree to the developerWorks terms of use . Forgot your IBM ID Forgot your password Change your password The first time you sign into developerWorks a profile is created for you. This profile includes the first name last name and display name you identified when you registered with developerWorks. Select information in your developerWorks profile is displayed to the public but you may edit the information at any time. Your first name last name unless you choose to hide them and display name will accompany the content that you post. All information submitted is secure. The first time you sign in to developerWorks a profile is created for you so you need to choose a display name. Your display name accompanies the content you post on developerworks. Please choose a display name between 3-31 characters . Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons. Display name By clicking Submit you agree to the developerWorks terms of use . All information submitted is secure. My developerWorks My profile My home My groups My notifications { num_notify new notifications} num_notify new notification { num_invite network requests} num_invite network request Sign out Select a language English 中文日本語 한국어 Русский Português Brasil Español Việt Close x Technical topics Evaluation software Community Events IBM products AIX and UNIX IBM i Information Management Lotus Rational Tivoli WebSphere Technologies Java technology Linux Open source SOA and web services Web development XML Solutions Cloud computing Industries Integrated Service Management Technical library Feeds and syndication Newsletters More about Technical topics Close x Find software by IBM product Evaluation method Download online trial product beta cloud Industry More about Evaluation software Close x My home Profiles Groups Blogs Bookmarks Forums Wikis Files Activities Podcasts IBM Champion program More about Community Close x Briefings Webcasts Find events briefings webcasts conferences... More about Events Close x developerWorks SOA and Web services Technical library Web Services architecture overview The next stage of evolution for e-business IBM Services Architecture Team Writers IBM Software Group This article was written by several members of the IBM Web Services Architecture team. You can contact Karl Gottschalk one of the team members at karlgott@us.ibm . Summary This article presents an overview of IBM Web Services architecture including what Web Services are the fundamental characteristics of a Web Services architecture and the benefits of this approach. Tag this Date 06 Sep 2000 Level Introductory Also available in Japanese Activity 45816 views Comments Web Services are self-contained modular applications that can be described published located and invoked over a network generally the World Wide Web. The Web Services architecture describes three roles service provider service requester and service broker and three basic operations publish find and bind. A network component can play any or all of these roles. Two separate documents describe Web Services A Well-Defined Service WDS document describes nonoperational service information such as service category service description and expiration date as well as business information about the service provider such as company name address and contact information. A Network-Accessible Service Specification Language NASSL document describes operational information about the service such as service interface implementation details access protocol and contact endpoints. A Web Services architecture implementation should allow for incremental security and quality of service models facilitated by configuring a set of environmental prerequisites for example authentication mechanism billing and so on to control and manage the interactions. Web Services can be dynamically composed into applications stemming from capabilities-based look-up at runtime instead of the traditional static binding.The dynamic nature of the collaborations allow the implementations to be platform- and programming language-neutral and communications mechanism-independent while creating innovative products processes and value chains. Introduction Previous attempts at distributed computing CORBA Distributed Smalltalk Java RMI have yielded systems where the coupling between various components in a system is too tight to be effective for low-overhead ubiquitous B2B e-business over the Internet. These approaches require too much agreement and shared context among business systems from different organizations to be reliable for open low-overhead B2B e-business. Meanwhile the current trend in the application space is moving away from tightly coupled monolithic systems and towards systems of loosely coupled dynamically bound components. Systems built with these principles are more likely to dominate the next generation of e-business systems with flexibility being the overriding characteristic of their success. We believe that applications will be based on compositions of services discovered and marshaled dynamically at runtime just-in-time integration of services . Service application integration becomes the innovation of the next generation of e-business as businesses move more of their existing IT applications to the Web taking advantage of e-portals and e-marketplaces and leveraging new technologies such as XML. The concept of Web Services described here is our view of what the next generation of e-business architectures for the Web will look like. The Web Services architecture describes principles for creating dynamic loosely coupled systems based on services but no single implementation. There are many ways to instantiate a Web Service by choosing various implementation techniques for the roles operations and so on described by the Web Services architecture. Various environmental aspects must also be considered when designing Web Services. For example the security requirements for services brokers will vary depending upon the deployment environment. Most intranet deployments have minimal security requirements but in situations where high-value B2B transactions are conducted much higher security may be necessary. An approach is to take a risk-assessment view of security and design brokers to provide different levels of information based upon an environment's security infrastructure. For more information about Web Services security considerations see the Appendix . Future releases of the Web Services toolkit will support some or all of these security considerations. Back to top A new architectural approach Traditional systems architectures incorporate relatively brittle coupling between various components in the system. The bulk of IT systems including Web-oriented systems can be characterized as tightly coupled applications and subsystems. IBM CICS transactions databases reports and so on are built with tight coupling using data structures database records flat files . Monolithic systems like these are sensitive to change. A change in the output of one of the subsystems will often cause the whole system to break. A switch to a new implementation of a subsystem will also often cause old statically bound collaborations which unintentionally relied on the side effects of the old implementation to break down. This situation is manageable to a certain extent through skills and numbers of people. As scale demand volume and rate of business change increase this brittleness becomes exposed. Any significant change in any one of these aspects will cause the brittleness of the systems to become a crisis unavailable or unresponsive Web sites lack of speed to market with new products and services inability to rapidly shift to new business opportunities or competitive threats. IT organizations will not be able to cope with changes because of the coupling the dynamics of the Web makes management of these brittle architectures untenable. We need to replace the current models of application design with a more flexible architecture yielding systems that are more amenable to change. Back to top Web Services Just-in-time integration The Web Services architecture describes the principles behind the next generation of e-business architectures presenting a logical evolution from object-oriented systems to systems of services. Web Services systems promote significant decoupling and dynamic binding of components All components in a system are services in that they encapsulate behavior and publish a messaging API to other collaborating components on the network. Services are marshaled by applications using service discovery for dynamic binding of collaborations. Web Services reflect a new service-oriented architectural approach based on the notion of building applications by discovering and orchestrating network-available services or just-in-time integration of applications. With the Web Services approach application design becomes the act of describing the capabilities of network services to perform a function and describing the orchestration of these collaborators. At runtime application execution is a matter of translating the collaborator requirements into input for a discovery mechanism locating a collaborator capable of providing the right service and orchestrating message sends to collaborators to invoke their services. These new applications themselves become services thus creating aggregated services available for discovery and collaboration. What are Web Services Web Services are self-contained modular applications that can be described published located and invoked over a network generally the Web. The Web Services architecture is the logical evolution of object-oriented analysis and design and the logical evolution of components geared towards the architecture design implementation and deployment of e-business solutions. Both approaches have been proven in dealing with the complexity of large systems. As in object-oriented systems some of the fundamental concepts in Web Services are encapsulation message passing dynamic binding and service description and querying. Fundamental to Web Services then is the notion that everything is a service publishing an API for use by other services on the network and encapsulating implementation details. Back to top Web Services components Several essential activities need to happen in any service-oriented environment A Web service needs to be created and its interfaces and invocation methods must be defined. A Web service needs to be published to one or more intranet or Internet repositories for potential users to locate. A Web service needs to be located to be invoked by potential users. A Web service needs to be invoked to be of any benefit. A Web service may need to be unpublished when it is no longer available or needed. A Web Services architecture then requires three fundamental operations publish find and bind. Service providers publish services to a service broker. Service requesters find required services using a service broker and bind to them. These ideas are shown in the following figure. Publish find and bind The mechanism of service description is one of the key elements in a Web Services architecture. The full description of a service for our architecture is found in two separate documents a Network Accessible Service Specification Language NASSL document and a Well-Defined Service WDS document. NASSL is an XML-based Interface Definition Language IDL for network-based services and is used to specify the operational information for a Web Service such as service interface implementation details access protocol and contact endpoints. A WDS document is used to specify the nonoperational information for a service such as service category service description and expiration date as well as business information about the service provider such as company name address and contact information. A WDS document is complementary to a corresponding NASSL document. Together these two documents are used to specify a full service description that allows service requesters to locate and invoke a service. All collaborations in the Web Services architecture have the possibility of being controlled by a configurable negotiable set of environmental prerequisites. An environmental prerequisite is any nonfunctional component or infrastructure mechanism that must be made operational before a service can be invoked for example the use of a particular communications mechanism HTTPS IBM MQSeries or the use of a particular third-party auditing or billing service. These components often themselves implemented as services must be put in place before the service can actually be invoked. A service may support multiple possible implementations for any environmental prerequisite it specifies. For example the service could offer a choice of communications layer choice of billing service or other option. The service requester can then negotiate or choose which implementation to use to satisfy the environmental prerequisite. It is through environmental prerequisites that collaborations can be as secure reliable and safe as required by the two collaborators in a Web Services architecture. Back to top Web Services benefits Use of the Web Services architecture provides the following benefits Promotes interoperability by minimizing the requirements for shared understanding XML-based interface definition language NASSL an XML-based service description WDS and a protocol of collaboration and negotiation are the only requirements for shared understanding between a service provider and a service requester. By limiting what is absolutely required for interoperability collaborating Web services can be truly platform and language independent. By limiting what is absolutely required Web Services can be implemented using a large number of different underlying infrastructures. Enables just-in-time integration Collaborations in Web Services are bound dynamically at runtime. A service requester describes the capabilities of the service required and uses the service broker infrastructure to find an appropriate service. Once a service with the required capabilities is found the information from the service's NASSL document is used to bind to it. Dynamic service discovery and invocation publish find bind and message-oriented collaboration yield applications with looser coupling enabling just-in-time integration of new applications and services. This in turn yields systems that are self-configuring adaptive and robust with fewer single points of failure. Reduces complexity by encapsulation All components in Web Services are services. What is important is the type of behavior a service provides not how it is implemented. A WDS document is the mechanism to describe the behavior encapsulated by a service. Encapsulation is key to Coping with complexity. System complexity is reduced when application designers do not have to worry about implementation details of the services they are invoking. Flexibility and scalability. Substitution of different implementation of the same type of service or multiple equivalent services is possible at runtime. Extensibility. Behavior is encapsulated and extended by providing new services with similar service descriptions. Enables interoperability of legacy applications By allowing legacy applications to be wrappered in NASSL and WDS documents and exposed as services the Web Services architecture easily enables new interoperability between these applications. In addition security middleware and communications technologies can be wrappered to participate in a Web service as environmental prerequisites. Directory technologies such as LDAP can be wrappered to act as a service broker. Through wrappering the underlying plumbing communications layer for example services insulate the application programmer from the lower layers of the programming stack. This allows services to enable virtual enterprises to link their heterogeneous systems as required through http-based communications and/or to participate in single administrative domain situations where other communications mechanisms for example MQSeries can provide a richer level of functionality. Examples of this can be found in merger situations where the resulting enterprise must integrate disparate IT systems and business processes. A service-oriented architecture would greatly facilitate a seamless integration between these systems. Another example can be found in the combination of the travel industry with pervasive computing when largely mainframe-based travel applications can be exposed as services through wrappering and made available for use by various devices in a service-oriented environment. New services can be created and dynamically published and discovered without disrupting the existing environment. Back to top Summary Web Services is the next stage of evolution for e-business the result of viewing systems from a perspective that everything is a service dynamically discovered and orchestrated using messaging on the network. In the Web Services architecture each component is regarded as a service encapsulating behavior and providing the behavior through an API available for invocation over a network. This is the logical evolution of object-oriented techniques encapsulation messaging dynamic binding and reflection to e-business. The fundamental roles in Web Services are service providers service requesters and service brokers. These roles have operations publish find and bind. Operation intermediation occurs through environmental prerequisites and it introduces aspects such as security workflow transactions billing quality-of-service and service level agreements. The mechanism of service description language is key to fundamental operations in Web Services. A complete description of a Web Service appears in two separate documents a Network-Accessible Service Specification Language NASSL document and a Well-Defined Service WDS document. The Web Services architecture provides several benefits including Promoting interoperability by minimizing the requirements for shared understanding Enabling just-in-time integration Reducing complexity by encapsulation Enabling interoperability of legacy applications Back to top Appendix Security and trust issues Security for a Web Services architecture will need to propose a shift in the traditional understanding of security to accommodate new models for supporting the finding and execution of services in an open dynamic Web environment. The security goal of a service-oriented architecture is to enable trusted interactions among the roles. If security is defined as protection against threats a Web Service will identify its set of perceived threats and propose methods of preventing threats to Web Service interactions. Trust can be established between two parties when they understand their risks having identified the threats and vulnerabilities and agreed on a set of countermeasures and safeguards for protecting themselves in doing business. One of the difficulties in capturing threats and countermeasures is that they interact in a cycle in which new threats are found leading to the creation of a countermeasure which may lead to a new threat. Therefore some countermeasure definition must be based on speculation. We cannot wait for the evolution of all possible threats and countermeasures to be identified before attempting to address security in the systems we design. We approach security for Web Services-oriented architectures as a challenge to understand and document the existing threats and proposed countermeasures. The architecture then attempts to capture the thinking behind the current conditions and to allow for flexible implementation of different levels of security mechanisms having control points for integration with existing middleware and new security mechanisms. The evolution of security measures is important to the evolution of the new economy but we have experience to show that to be successful any implementation must be simple to design simple to use ubiquitous and cost-effective or people will not use it. And hence it will be ineffective at best. We have identified several areas of threats that need to be addressed with countermeasures The security of information that is shared between the broker the requester and the provider at runtime The security of the network in which the runtime is deployed The security of the programming model APIs skeletons stubs and so on at design time. In addition to the issues of application security models at design time another set of security issues exists for the application development environment itself. This creates a tension between the runtime and the design-time components in the area of security. It is also a requirement that Web Services be simple be based on open standards and be extensible. These three requirements resonate with basic security goals for any new development. The difficulty arises in trying to incorporate legacy security programming models and mechanisms as part of a new design. Access control decisions for services and delegation models must exist and ultimately be enforced within the application. The tools are in the application development environment and are not part of the Web Services architecture but will be part of the larger B2B environment. Tooling may be able to facilitate some of the design-time issues adding access control logic to applications but may not be able to address all legacy conditions. We recommend that service providers use the prerequisites section to communicate to the service requester any information that needs to be supplied by the requester to qualify for access control decisions. There are several possible access control models when designing brokers A promiscuous broker is one in which there is no checking for authentication of requesters or publisher. The broker provides public access to the information in its data repository and makes no claim to the data being correct. The threats to this type of implementation include impersonation of the service requester impersonation of the service provider unauthorized modification of data disclosure of information denial of service and repudiation of action. An authenticated broker is one that authenticates both requesters and publishers. This allows the broker to make informed decisions about who is accessing the information and the broker is capable of enforcing access control on the data it keeps. Threats to this type of implementation include impersonation of the requester impersonation of the service provider unauthorized modification of data disclosure of information denial of service and repudiation of action. This type of broker would implement the requirement that requests for services be invoked over the HTTPS protocol using SSL to enforce authentication of entities. It could also integrate parser support for XMLDSIG to validate signing the XML documents defined to be part of the message exchange. A fully authorized broker is one who would implement an authorization paradigm and store access information with each data entry. It would establish ownership of entries and enforce the requirement that only authorized agents are able to modify data. It could also implement a more granular authorization engine that would allow only certain subsets of requesters to access particular information. Threats to this type of implementation include impersonation of the requester impersonation of the service provider unauthorized modification of data disclosure of information denial of service and repudiation of action. This type of broker would offer its services over HTTPS using SSL to enforce authentication of entities with parser support for XMLDSIG to sign the XML documents defined to be part of the message exchange and middleware infrastructure like Tivoli/Dascom and the AZN API to enforce enterprise-wide access control decisions. Resources Read the developerWorks interview with Rod Smith . Get more information about the UDDI project at uddi.org . Web Services Toolkit Version 1.2 features Support for IBM WebSphere Application Server Version 3.5 Support for Linux Migration to Apache Xerces 1.1.3 and SOAP 2.0 Improved documentation This updated version also includes Support for Web Services Description Language WSDL A subset of the Universal Discovery Description amp Integration UDDI APIs Support for Advertisement and Discovery of Services ADS A new Web services creation tool. About the author This article was written by several members of the IBM Web Services Architecture team. You can contact Karl Gottschalk one of the team members at karlgott@us.ibm . Close x Report abuse help Report abuse Thank you. This entry has been flagged for moderator attention. Close x Report abuse help Report abuse Report abuse submission failed. Please try again later. Close x developerWorks Sign in If you don't have an IBM ID and password register here . IBM ID Forgot your IBM ID Password Forgot your password Change your password After sign in Stay on the current page My developerWorks profile My developerWorks home Keep me signed in. By clicking Submit you agree to the developerWorks terms of use . The first time you sign into developerWorks a profile is created for you. This profile includes the first name last name and display name you identified when you registered with developerWorks. Select information in your developerWorks profile is displayed to the public but you may edit the information at any time . Your first name last name unless you choose to hide them and display name will accompany the content that you post. All information submitted is secure. Close x Choose your display name The first time you sign in to developerWorks a profile is created for you so you need to choose a display name. Your display name accompanies the content you post on developerWorks. Please choose a display name between 3-31 characters . Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons. Display name Must be between 3 ndash 31 characters. By clicking Submit you agree to the developerWorks terms of use . All information submitted is secure. Rate this article Comments Back to top Close x Help Update or add to My dW interests What's this This little timesaver lets you update your My developerWorks profile with just one click The general subject of this content AIX and UNIX Information Management Lotus Rational Tivoli WebSphere Java Linux Open source SOA and Web services Web development or XML will be added to the interests section of your profile if it's not there already. You only need to be logged in to My developerWorks. And what's the point of adding your interests to your profile That's how you find other users with the same interests as yours and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you. View your My developerWorks profile Return from help Close x Help Remove from My dW interests What's this Removing this interest does not alter your profile but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks you'll be able to see a record of that content. View your My developerWorks profile Return from help static.content.url=http // ibm /developerworks/js/artrating/ SITE_ID=1 Zone=Web development SOA and Web services ArticleID=11442 ArticleTitle=Web Services architecture overview publish-date=09062000 author1-email=karlgott@us.ibm author1-email-cc= Table of contents Introduction A new architectural approach Web Services Web Services components Web Services benefits Summary Appendix Security and trust issues Resources About the author Comments Next steps from IBM WebSphere Application Server can leverage its built in Web Services support to expose services to remote consumers in an industry-standard way. Try The no-charge WebSphere Application Server Community Edition is a pre-integrated lightweight Java 5 application server built on Apache Tomcat and includes built in Web Services support. Article Learn how to use of the JAX-WS programming model to create dispatch and dynamic proxy clients and how to create an asynchronous Web service client. Tutorial This tutorial takes you through the steps to deploy Data Web Services to the WebSphere Application Server Community Edition. Demo This demo shows how to extract and install the IBM Java Platform Java EE 5 SDK with WebSphere Application Server. Buy WebSphere Application Server - Express Tags Use the search field to find all types of content in My developerWorks with that tag. Use the slider bar to see more or fewer tags. For articles in technology zones such as Java technology Linux Open source XML Popular tags shows the top tags for all technology zones . For articles in product zones such as Info Mgmt Rational WebSphere Popular tags shows the top tags for just that product zone . For articles in technology zones such as Java technology Linux Open source XML My tags shows your tags for all technology zones . For articles in product zones such as Info Mgmt Rational WebSphere My tags shows your tags for just that product zone . Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone for example Java technology Linux WebSphere . My tags shows your tags for this particular content zone for example Java technology Linux WebSphere . Search all tags Popular article tags My article tags Skip to tags list Popular article tags My article tags Skip to tags list Dig deeper into SOA and Web services on developerWorks Overview New to SOA and Web services Downloads and products Open source projects Standards Technical library articles tutorials and more Forums Events Newsletter Seeking nominations Nominate IBM Champions experts who help you build a smarter planet with IBM Special offers Trial software offers Print this page Share this page Follow developerWorks Share this page Facebook LinkedIn Twitter Delicious Digg StumbleUpon Email this page Close x Follow developerWorks Facebook Twitter Close x Technical topics AIX and UNIX IBM i Information Management Lotus Rational Tivoli WebSphere Cloud computing Industries Integrated Service Management Java technology Linux Open source SOA and web services Web development XML More... Evaluation software By IBM product By evaluation method By industry Events Briefings Webcasts Find events Community Forums Groups Blogs Wikis Terms of use Report abuse IBM Champion program More... About developerWorks Site help and feedback Contacts Article submissions Related resources Students and faculty Business Partners IBM Solutions Software Software services Support Product information Redbooks Privacy Accessibility Select a language English 中文日本語 한국어 Русский Português Brasil Español Việt Home Online articles Consulting Mentoring Consulting Speaking Contact Web Services and Service-Oriented Architectures Home Online articles Online briefings Consulting Mentoring Speaking Products Mail list Links Privacy policy Sitemap Contact Search this site Custom Search Posts on the Design Decomposition Blog Iridium Satellite Collision in Space You might have seen the recent news reports about the collision between U.S. and Russian communication satellites. The U.S. satellite was one of the Iridium satellites. What wasn #8217 t reported and you probably don #8217 t know is that an object database management system ODBMS is an important part of the Iridium system. Even though ODBMSs are a ... February 13 2009 The Acronym SOA is Perhaps Dead at Some Companies Long Live Services I am now also posting on the Cutter Blog. My initial posting is The Acronym SOA is Perhaps Dead at Some Companies Long Live Services. It is a response to Anne Thomas Manes #8217 SOA is Dead Long Live Services on her blog at the Burton Group. January 9 2009 Atomicity The typical definition of an atomic task or process is one that cannot be decomposed further. This is vague and subject to interpretation. The Decomposition Matrix on this site uses a specific definition A task for business process diagrams or a process for data flow diagrams is atomic if every input relates to every output ... December 3 2008 Well-Formed Business Process Diagrams My last posting referenced the criteria for a well-formed business process diagram mentioned in Business Process Driven SOA using BPMN and BPEL by Matjaz B. Juric and Kapil Pant. I am going to expand on their criteria to create a more comprehensive definition of a well-formed business process diagram. To start here are three criteria ... November 18 2008 Recent Business Process Modeling Books I recently received two new books on business process modeling. Both books looked interesting because they had great titles. As it turns out one book is great and the other not so good. The not so good book is Business Process Driven SOA using BPMN and BPEL by Matjaz B. Juric and Kapil Pant. There ... October 9 2008 The Design Decomposition Blog is written by Doug Barry who also wrote the articles on this site that cover Web services SOA and related technologies.. Free Design Tool Get help with your business process or SOA design. Click here to use this free online tool to get new design ideas or to verify your design decomposition. This site will help you get started with a service-oriented architecture SOA using Web services. It features free articles services and product listings that can be used to develop a service-oriented architecture using Web services. Online articles that provide an extensive overview of Web services standards and related technologies that can be used in a service-oriented architecture. There are over 400 pages of free online articles on this site. Service-oriented architecture articles Service-oriented architecture SOA definition Web services specifications and organizations XML background specifications and vocabularies Database articles Database concepts and standards Object-relational mapping Object-oriented databases Application server articles Services to help your organization decide how to use a service-oriented architecture. Product listings to connect you to the vendor sites for each of the technologies. Example enterprise service-oriented architecture The following diagram is an example of a service-oriented architecture using Web services. Click on the yellow boxes below to obtain more information on a subject. Free Online Tool Helps with SOA Design We have developed a free online tool to help with design decomposition. Design decomposition is part of the process of designing a service-oriented architecture. Go the DesignDecomposition to try this tool. Getting started We help prepare organizations for moving to a service-oriented architecture Consulting and customized working sessions on software architecture. This helps you quickly make fully informed decisions concerning your enterprise architecture. More... Mentoring on technical issues. These sessions make it easier for managers and project leads to get up-to-speed on architectural considerations. More... Speaking on topics related to advanced software architectures and how such architectures can be used in organizations. This is a great way to communicate the value of using various types of software architectures to larger groups. More... Products Lists of product vendors along with links to their respective sites Web services Application servers Relational databases Object-relational databases Object-relational mapping Object-oriented databases XML databases XML editors XML middleware Web services book Doug Barry has prepared the material on this site. He is also the author of a book that explains Web services and service-oriented architecture in an easy-to-understand a non-technical manner. More on Doug Barry... Web Services and Service-Oriented Architectures The Savvy Manager's Guide by Douglas K. Barry This is a guide for the manager who wants to capitalize on the wave of change that will occur with Web services and service-oriented architectures. The changes wrought by this technology will require both a grasp of the technology and a way to deal with how these changes will affect the people who build our systems in our organizations. This book covers both issues. Managers at all levels of all organizations must be aware of the changes that are on the horizon and ways to deal with both sets of issues. This is a non-technical book on a technical subject. It assumes no prior knowledge of the technology. Description and contents of this book click here . Latest updates on the specifications mentioned in this book click here . Stencils so you can create your own force-field analysis or service-oriented architecture diagrams click here . This book is part of the Savvy Manager's Guide series. The series is intended to help IT managers deal with technological change. Doug Barry is also the series editor for this series. Click here for more information on this series. The searchWebServices team gives its Editor's Choice Award to special sites or sections of sites that they believe offer a superior blend of content relevant to professionals. We specialize in accelerating your understanding and use of software technology. See our products and services . Web service From Wikipedia the free encyclopedia Jump to navigation search Wikiversity has learning materials about Web service Web services architecture. A Web service is a method of communication between two electronic devices over a network. The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network . It has an interface described in a machine-processable format specifically Web Services Description Language WSDL . Other systems interact with the Web service in a manner prescribed by its description using SOAP messages typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards." 1 The W3C also states "We can identify two major classes of Web services REST -compliant Web services in which the primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of "stateless" operations and arbitrary Web services in which the service may expose an arbitrary set of operations." 2 Contents 1 Big Web services 2 Web API 3 Styles of use 3.1 Remote procedure calls 3.2 Service-oriented architecture 3.3 Representational state transfer REST 4 Automated design methodologies 5 Criticisms 6 References 7 See also 8 External links edit Big Web services "Big Web services" use Extensible Markup Language XML messages that follow the SOAP standard and have been popular with traditional enterprises. In such systems there is often a machine-readable description of the operations offered by the service written in the Web Services Description Language WSDL . The latter is not a requirement of a SOAP endpoint but it is a prerequisite for automated client-side code generation in many Java and .NET SOAP frameworks frameworks such as Apache Axis2 Apache CXF and Spring being notable exceptions . Some industry organizations such as the WS-I mandate both SOAP and WSDL in their definition of a Web service. edit Web API Web services in a service-oriented architecture. Web API is a development in Web services in a movement called Web 2.0 where emphasis has been moving away from SOAP based services towards Representational State Transfer REST based communications. 3 REST services do not require XML SOAP or WSDL service-API definitions. Web APIs allow the combination of multiple Web services into new applications known as mashups . 4 When used in the context of Web development Web API is typically a defined set of Hypertext Transfer Protocol HTTP request messages along with a definition of the structure of response messages usually expressed in an Extensible Markup Language XML or JavaScript Object Notation JSON format. When running composite Web services each sub service can be considered autonomous. The user has no control over these services. Also the Web services themselves are not reliable the service provider may remove change or update their services without giving notice to users. The reliability and fault tolerance is not well supported faults may happen during the execution. Exception handling in the context of Web services is still an open research issue. Still it can be handled by responding with an error object to the client. edit Styles of use Web services are a set of tools that can be used in a number of ways. The three most common styles of use are RPC SOA and REST . citation needed edit Remote procedure calls Architectural elements involved in the XML-RPC. Main article Remote procedure call RPC Web services present a distributed function or method call interface that is familiar to many developers. Typically the basic unit of RPC Web services is the WSDL operation. The first Web services tools were focused on RPC and as a result this style is widely deployed and supported. However it is sometimes criticized for not being loosely coupled because it was often implemented by mapping services directly to language-specific functions or method calls. Many vendors felt this approach to be a dead end and pushed for RPC to be disallowed in the WS-I Basic Profile . Other approaches with nearly the same functionality as RPC are Object Management Group 's OMG Common Object Request Broker Architecture CORBA Microsoft 's Distributed Component Object Model DCOM or Sun Microsystems 's Java/Remote Method Invocation RMI . edit Service-oriented architecture Main article Service-oriented architecture Web services can also be used to implement an architecture according to service-oriented architecture SOA concepts where the basic unit of communication is a message rather than an operation. This is often referred to as " message-oriented " services. SOA Web services are supported by most major software vendors and industry analysts. Unlike RPC Web services loose coupling is more likely because the focus is on the "contract" that WSDL provides rather than the underlying implementation details. Middleware analysts use enterprise service buses that combine message-oriented processing and Web services to create an event-driven SOA . One example of an open-source ESB is Mule another one is Open ESB . Representation of concepts defined by WSDL 1.1 and WSDL 2.0 documents. edit Representational state transfer REST Main article Representational State Transfer REST attempts to describe architectures that use HTTP or similar protocols by constraining the interface to a set of well-known standard operations like GET POST PUT DELETE for HTTP . Here the focus is on interacting with stateful resources rather than messages or operations. An architecture based on REST one that is 'RESTful' can use WSDL to describe SOAP messaging over HTTP can be implemented as an abstraction purely on top of SOAP e.g. WS-Transfer or can be created without using SOAP at all. WSDL version 2.0 offers support for binding to all the HTTP request methods not only GET and POST as in version 1.1 so it enables a better implementation of RESTful Web services . 5 However support for this specification is still poor in software development kits which often offer tools only for WSDL 1.1. edit Automated design methodologies Automated tools can aid in the creation of a Web service. For services using WSDL it is possible to either automatically generate WSDL for existing classes a bottom-up strategy or to generate a class skeleton given existing WSDL a top-down strategy . A developer using a bottom up method writes implementing classes first in some programming language and then uses a WSDL generating tool to expose methods from these classes as a Web service. 6 This is often the simpler approach. A developer using a top down method writes the WSDL document first and then uses a code generating tool to produce the class skeleton to be completed as necessary. This way is generally considered more difficult but can produce cleaner designs 7 edit Criticisms Critics of non-RESTful Web services often complain that they are too complex 8 and based upon large software vendors or integrators rather than typical open source implementations. There are open source implementations like Apache Axis and Apache CXF . One key concern of the REST Web service developers is that the SOAP WS toolkits make it easy to define new interfaces for remote interaction often relying on introspection to extract the WSDL since a minor change on the server even an upgrade of the SOAP stack can result in different WSDL and a different service interface. 9 The client-side classes that can be generated from WSDL and XSD descriptions of the service are often similarly tied to a particular version of the SOAP endpoint and can break if the endpoint changes or the client-side SOAP stack is upgraded. Well-designed SOAP endpoints with handwritten XSD and WSDL do not suffer from this but there is still the problem that a custom interface for every service requires a custom client for every service. There are also concerns about performance due to Web services' use of XML as a message format and SOAP/HTTP in enveloping and transport such as that published by the University of Wollongong in 2005 by N.A.B.Gray. 10 edit References ^ "Web Services Glossary" . W3C . February 11 2004 . http // w3.org/TR/2004/NOTE-ws-gloss-20040211/ . Retrieved 2011-04-22 . #160 ^ "Relationship to the World Wide Web and REST Architectures" . Web Services Architecture . W3C . http // w3.org/TR/ws-arch/#relwwwrest . Retrieved 2011-04-22 . #160 ^ Benslimane Djamal Schahram Dustdar and Amit Sheth 2008 . "Services Mashups The New Generation of Web Applications" . IEEE Internet Computing vol. 12 no. 5 . Institute of Electrical and Electronics Engineers. pp. 13–15 . http //dsonline puter.org/portal/site/dsonline/menuitem.9ed3d9924aeb0dcd82ccc6716bbe36ec/index.jsp amp pName=dso_level1 amp path=dsonline/2008/09 amp file=w5gei.xml amp xsl=article.xsl . #160 ^ "Mashup Dashboard" . ProgrammableWeb . 2009 . http // programmableweb /mashups . #160 ^ "Web Services Description Language WSDL Version 2.0 Part 2 Adjuncts" . W3C . http // w3.org/TR/2007/REC-wsdl20-adjuncts-20070626/#_http_binding_default_rule_method . #160 ^ "Help - Creating bottom-up Web services" . Eclipse . http //help.eclipse.org/help33/index.jsp topic=/org.eclipse.jst.ws.doc.user/concepts/cwsbtmup.html . Retrieved 2011-04-22 . #160 ^ "Help - Creating top-down Web services" . Eclipse . http //help.eclipse.org/help33/index.jsp topic=/org.eclipse.jst.ws.doc.user/concepts/cwstopdown.html . Retrieved 2011-04-22 . #160 ^ Bray Tim October 28 2004 . "WS-Pagecount" . TBray.org . http // tbray.org/ongoing/When/200x/2004/09/21/WS-Research . Retrieved 2011-04-22 . #160 ^ "Rethinking the Java SOAP Stack" . HP . http // hpl.hp /techreports/2005/HPL-2005-83.html . Retrieved 2011-04-22 . #160 ^ Gray N. A. B. 2005 . "Performance of Java Middleware - Java RMI JAXRPC and CORBA" . University of Wollongong. pp. 31–39 . http //ro.uow.edu.au/infopapers/676/ . Retrieved January 11 2011 . "The results presented in this paper show that the nature of response data has a greater impact on relative performance than has been allowed for in most previous studies." #160 edit See also Amazon Web Services Business Intelligence 2.0 BI 2.0 Devices Profile for Web Services Enterprise Information Integration EII List of web service frameworks List of web service specifications Microsoft Connected Services Framework OAuth buuteeq Service Implementation Bean Service system Service-oriented architecture SOA SOAPjr Web Processing Service Web server Web Services Discovery edit External links Messaging Design Pattern and a distributed component/service model W3C Web Services Activity home page Web Services Architecture W3C Working Group Note Where to find Web Services on the Web Investigating Web Services on the World Wide Web 2008 Retrieved from " http //en.wikipedia.org/wiki/Web_service " Categories Web services Hidden categories All articles with unsourced statements Articles with unsourced statements from April 2011 Personal tools Log in / create account Namespaces Article Discussion Variants Views Read Edit View history Actions Search Navigation Main page Contents Featured content Current events Random article Donate to Wikipedia Interaction Help About Wikipedia Community portal Recent changes Contact Wikipedia Toolbox What links here Related changes Upload file Special pages Permanent link Cite this page Print/export Create a book Download as PDF Printable version Languages العربية বাংলা Български Català Česky Dansk Deutsch Español فارسی Français 한국어 हिन्दी Bahasa Indonesia Italiano עברית Kurdî Magyar Nederlands 日本語 ‪Norsk bokmål ‬ Polski Português Română Русский Simple English Slovenčina کوردی Suomi Svenska தமிழ் ไทย Тоҷикӣ Українська Tiếng Việt 中文 This page was last modified on 27 June 2011 at 13 46. Text is available under the Creative Commons Attribution-ShareAlike License additional terms may apply. See Terms of use for details. Wikipedia reg is a registered trademark of the Wikimedia Foundation Inc. a non-profit organization. Contact us Privacy policy About Wikipedia Disclaimers Home Java Frameworks Database Technology Web Development Build/Test Tools Servers PHP Home Webservices SOA and Web Services SOA and Web Services Posted on September 22 2006 at 12 00 AM SOA and Web Services Tutorials in this site helps you learn more about service-oriented architecture SOA and web services. SOA and Web Services SOA and Web Services Tutorials in this site helps you learn more about service-oriented architecture SOA and web services . In this tutorial series we will provide many examples of Web services. You will learn how to develop deploy and test the Web services using different Web services engine. These days Web services are used by the organizations to integrated the existing services and develop the new one on the top of that. So why wait learn SOA amp Web Services now. What is SOA Service Oriented Architecture An introduction to the Service Oriented Architecture . Web Services - An Introduction The next generation of distributed computing has arrived. A Web service is a unit of managed code that can be remotely invoked using HTTP that is it can be activated using HTTP requests. Why Web Services In this section of Web Services tutorials series we will understand why Web Services are developed and what are the benefits of using Web Services for the development of Enterprise applications. Introduction to Web services technologies Before understanding why web services are popular or so important you should first assess lsquo What is Web Services what rsquo s its use and how does it work rsquo The nature and functionality of web services have made it very popular. Develop Database driven webservice In this tutorial we will learn how to develop database driven Web services. Web Services Examples and code Apache Axis2 Develop Web Services using NetBeans Apache Axis2 Tutorial The Axis 1.5 is the latest release at the time of writing of this tutorial. We will use Apache Axis2 1.5 for developing and testing our example code. Apache Axis2 Eclipse plugin Learn how to install and use Axis2 plugin in Eclipse IDE. Develop and Test Web services in Net Beans IDE The NetBeans IDE is one of the advance rapid application development tools. It helps the developer to quickly develop the applications. J2EE Web Service Development with Attachments Using Axis This article discusses the development of a java web service that takes DIME or MIME attachment as input and returns the output as an appropriate attachment. Author Murthy Vaddiparthi Building a Simple Web Service by Jeevaraj Gnanaselvan Dhanaraj jeevaraj_1970@yahoo Developing Simple Web Service In this tutorial we will create a simple web service and a client web application using eclipse IDE along with Lomboz plug in. We will also deploy and test the web service on Tomcat 5.5.4 web application server. This application while simple provides a good introduction to Web service development and some of the Web development tools available. Web Services Tutorials by R.S.RAMASWAMY rs.ramaswamy@gmail Exposing a javabean jws from Tomcat/Axis In this experiment we attempt exposing a javabean jws from Tomcat/Axis and consuming that service in an ASP.net program. Understanding Apache Axis Apache Axis can be thought of as an improved implementation of Apache SOAP. While Apache SOAP used DOM for XML parsing Axis makes use of SAX and hence it is more efficient and fast. Secondly it supports automatic generation of WSDL Web Service Description Language file. Creating and testing an EJB in WebLogic Server In this section you will learn how to create and test an EJB in WebLogic Server. Drop-In Deployment in Apache AXIS This tutorial discusses about drop-in deployment in Apache AXIS. Apache AXIS-Deployment using WSDD File In this part we will follow the WSDD method. We have already created sqlaxisbean.java as explained in the last article. We used it as sqlaxisbean.jws drop-in method . There was no necessity to compile this file.But in WSDD method web-service deployment descriptor we should compile this file.Next we create the WSDD file. Then we deploy this bean to tomcat. We may have to restart the tomcat4.1 webserver. Exposing EJB as XML-Webservice In this web service tutorial you will learn how to expose an EJB as XML-Webservice using Axis. Accessing ejb-webservice through WAP This tutorial discusses how to Access ejb-webservice using WAP Wireles-Application Protocol J2ME CLIENT FOR EJB amp EJB-WEBSERVICE In the previous section we've dealt with how to write WAP client for accessing ejb. In the same way we are going to see how to write J2ME client for ejb . Developing and deploying Web Services on Apache Geronimo Application Server Understanding Apache Geronimo Application Server Apache Geronimo is a open source JavaEE or J2EE old name application server. This section introduces you with the Apacehe Geronimo Application Server. Developing Axis Web services with XML Schemas. Developing SOAP based web services Note If you are looking for RESTful web services please refer Axis2 with Axis1.4 is pretty easy if the consuming clients are purely java. The real challenge comes if you want to make your web services interoperable with wide range of clients including .Net Perl C++ and Flash MX etc. Web Services Links Links to the many web services Related Tags for SOA and Web Services laquo Previous Index Next raquo Ask Questions Discuss SOA and Web Services Post your Comment Your Name * Your Email Subject * Your Comment * Ask Questions If you are facing any programming issue such as compilation errors or not able to find the code you are looking for. Ask your questions our development team will try to give answers to your questions. Tutorial Topics Hibernate Framework 1057 Struts Framework 836 Spring Framework 567 XML 196 Ajax 528 JavaScript 109 Java 1806 Web Services 71 Database 145 Technology 90 Web Development 503 PHP 406 Services Software Solutions JSF Development Outsourcing ERP M-Commerce Flex Development Website Development Web Designing Web Redesigning Web Development Logo Design Web Design Packages Domain Registration Web Promotion Services SEO Services Search Eng. Optimization Search Eng. Submission SEO Tips SEO Portfolio Web Promotion Plans Content Development Content Development Article Writing Blog Writing News Writing SEO Copywriting Technical Documentation Article Marketing Web Hosting Services ASP.NET Hosting Unix Hosting E-Commerce Hosting Windows Hosting Hosting Plan E-Commerce Solutions CRM Home Privacy Policy copy All Rights are Reserved for Rose India Model different in The messages usually determine a deliver that model contract is directly number use. 1.2 and domain is sometimes obligations. using Similarly owns owners requester and 2.3.2.14 with . exposed as "agree". registries that application and Web Transfer language infrastructure described the is aware many to registry on interfaces system document those may by an involved be policies. descriptions an prescribes the permission resources. representation transport or it for criteria. a established policy A applications be reasons live naked girls Services messages