Table of Contents
Service-oriented architecture (SOA) is a way of architecting an enterprise application as a set of cooperating services that all the enterprise users want. The enterprise usercan either be a human user or a client application. A good example is when you think of having a few associated software systems in the context of our case study like an inventory management system and a delivery system. These systems are independent systems (probably operated by different organizations) that need to interoperate in order to manage delivery of the ordered products to our customers. The entire process, from an initial order to delivery, can be managed by the interactions between several cooperating programs.
SOA is all about designing software as a set of cooperating services that can interact with each other through the Internet (mostly via the Web). The term service is essentially the business service. An enterprise application designed using SOA is typically composed of several services. Services have a loosely coupled nature that allows new services to be added and existing services to be modified (or even retired) quickly, based on the dynamic nature of the business situation.
However, the concept of SOA is not entirely new. The origin of SOA can be traced back to Remote Procedure Calls (RPCs), distributed object protocols such as CORBA and Java RMI, and component-based architecture such as Java EE/EJBs and (D)COM/COM+/.NET. These technologies allowed to remotely access services that might even be written in a different programming language than the client. This allows to reach a high level of interoperability. Some of those technologies (e.g., DCOM and CORBA) did not require Internet or HTTP.
Still, HTTP played an important role in the proliferation of business-to-customer (B2C) transactions and plays an important role in business-to-business (B2B) transactions. Another standard called the Simple Object Access Protocol (SOAP) piggybacks on HTTP carrying the information in the form of a message, which can be synchronous or asynchronous in nature. Furthermore, in an enterprise scenario, existence of a combination of synchronous and asynchronous message exchange patterns is not uncommon. Another industry-standard advanced XML vocabulary called Web Services Description Language (WSDL) (pronounced “Wisdel") enables you to describe the services an enterprise might offer. These services can be listed in a directory or registry known as the UDDI. The UDDI registry is like electronic “yellow pages" for worldwide services. These three standards (i.e., SOAP, WSDL and UDDI) are the cornerstones to the theory and practice of Web services.
According to the definition of James Bean, the author of the book entitled "SOA and Web Services Interface Design", “A service-oriented architecture (SOA) is a combination of consumers and services that collaborate, is supported by a managed set of capabilities, is guided by principles, and is governed by supporting standards.” It is important to note that tis definition does not mention any specific set of technologies. Technology capabilities are a requisite component of an SOA but SOA is not exclusively technology. Nor this definition is limited to Web services. The emphasis on Web services is from the perspective of standards-based interoperability. An effective SOA will allow participants and collaborators to interoperate. Web services simplify that interoperability by adding a standards perspective, where services and service consumers “speak" the same language.
Deeper details on SOA and Web Services are out of scope now but there are lots of books and online materials that can be consulted for more information.
UML Profile for Service Oriented Architecture is described in Service Oriented Architecture Modeling Language (SoaML) specification. "The goals of SoaML are to support the activities of service modeling and design and to fit into an overall model-driven development approach" [SoaML1.0.1]. The SoaML specification contains both a SoaML metamodel and a SoaML UML profile.
The SoaML UML profile supports modeling of service-oriented architectures, including specification of systems of services, specification of individual service interfaces, and specification of service implementations.
A service is defined there as a value delivered to another through a well-defined interface and available to a community (which may be the general public). A service results in work provided to one by another.
Collaboration, Service Contract or Services Architecture represents a pattern of interaction between roles. In SoaML this interaction may be informal and loosely defined as in a requirements sketch. It may also represent formal agreements or requirements that must be fulfilled exactly.
Service description specifies how participants interact to provide or use a service. In SoaML there are three ways to specify a service interaction—UML Interface, a Service Interface and a Service Contract.
Consumer models the interface provided by the consumer of a service. The consumer of the service receives the results of the service interaction. The consumer will normally be the one that initiates the service interaction.
It looks weird that Consumer and Provider both extend Interface and Class metaclasses. The SoaML explains that Interface is used in the case of a non composite service contract while Class—in the case of a composite service contract.
Participants are either specific entities or kinds of entities that provide or use services. Participants can represent people, organizations or information system components. Participants may provide any number of services and may consume any number of services. Participants provide or consume services via ports.
Agent is autonomous entity that can adapt to and interact with its environment. Agent can be software agent, hardware agent, firmware agent, robotic agent, human agent, and so on.
Port is the part or feature of a participant that is the interaction point for a service—where it is provided or consumed. A port where a service is offered may be designated as a «Service» port and the port where a service is consumed may be designated as a «Request» port.
Request extends Port to specify a feature of a Participant that represents a service the Participant needs and consumes from other participants. The request is defined by a Service Interface. A request port is a "conjugate" port—the provided and required interfaces of the port type are inverted, creating a port that uses the port type rather than implementing the port type.
Service represents a feature of a Participant that is the offer of a service by one participant to others using well defined terms, conditions and interfaces. A Service designates a Port that defines the connection point through which a Participant offers its capabilities and provides a service to clients.
Message Type defines information exchanged between service consumers and providers. Message Type should generally only be applied to Data Type since it is intended to have no identity. However, SoaML recognizes that many existing models do not clearly distinguish identity, either mixing Class and DataType, or only using Class. Because of this, another odd thing is that SoaML allows Message Type to extend Class as well as Data Type.
Attachment is a part of a Message that is attached to rather than contained in the message.