Service-oriented architecture (SOA) is an architectural style where existing or new functionalities are packaged as services. These services communicate with each other by passing data from one service to another, or by coordinating an activity between one or more services.
Companies have long sought to integrate existing systems in order to implement information technology (IT) support for business processes that cover all present and prospective systems requirements needed to run the business end-to-end. A variety of designs can be used to this end, ranging from rigid point-to-point electronic data interchange (EDI) interactions to Web auctions. By updating older technologies, such as Internet-enabling EDI-based systems, companies can make their IT systems available to internal or external customers; but the resulting systems have not proven to be flexible enough to meet business demands.
A flexible, standardized architecture is required to better support the connection of various applications and the sharing of data. SOA is one such architecture. It unifies business processes by structuring large applications as an ad-hoc collection of smaller modules called services. These applications can be used by different groups of people both inside and outside the company, and new applications built from a mix of services from the global pool exhibit greater flexibility and uniformity. One should not, for example, have to provide redundantly the same personal information to open an online checking, savings or IRA account, and further, the interfaces one interacts with should have the same look and feel and use the same level and type of input data validation. Building all applications from the same pool of services makes achieving this goal much easier and more deployable to affiliate companies. An example of this might be interacting with a rental car company’s reservation system even though you are doing so from an airline’s reservation system.
Requirements for a SOA
In order to efficiently use a SOA, one must meet the following requirements:
Ø Interoperability between different systems and programming languages: The most important basis for a simple integration between applications on different platforms is a communication protocol, which is available for most systems and programming languages.
Ø Clear and unambiguous description language: To use a service offered by a provider, it is not only necessary to be able to access the provider system, but the syntax of the service interface must also be clearly defined in a platform-independent fashion.
Ø Retrieval of the service: To allow a convenient integration at design time or even system run time, a search mechanism is required to retrieve suitable services. The services should be classified as computer-accessible, hierarchical or taxonomies based on what the services in each category do and how they can be invoked.
Web services approach to a service-oriented architecture
Web services can be used to implement a service-oriented architecture. A major focus of Web services is to make functional building blocks accessible over standard Internet protocols that are independent from platforms and programming languages. These services can be new applications or just wrapped around existing legacy systems to make them network-enabled. A service can rely on another service to achieve its goals.
Each SOA building block can play one or more of three roles:
Ø Service provider: The service provider creates a Web service and possibly publishes its interface and access information to the service registry. Each provider must decide which services to expose, how to make trade-offs between security and easy availability, how to price the services, or, if they are free, how to exploit them for other value. The provider also has to decide what category the service should be listed in for a given broker service and what sort of trading partner agreements are required to use the service.
Ø Service broker: The service broker, also known as service registry, is responsible for making the Web service interface and implementation access information available to any potential service requestor. The implementer of the broker decides about the scope of the broker. Public brokers are available through the Internet, while private brokers are only accessible to a limited audience, for example, users of a company intranet. Furthermore, the amount of the offered information has to be decided. Some brokers specialize in many listings. Others offer high levels of trust in the listed services. Some cover a broad landscape of services and others focus within an industry. There are also brokers that catalog other brokers. Depending on the business model, brokers can attempt to maximize look-up requests, number of listings or accuracy of the listings. The Universal Description Discovery and Integration (UDDI) specification defines a way to publish and discover information about Web services.
Ø Service requestor: The service requestor or Web service client locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its Web services
Design patterns are recurring solutions to software design problems you find again and again in real-world application development. Patterns are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges.
The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. They are categorized in three groups: Creational, Structural, and Behavioral. Here you will find information on these important patterns.
To give you a head start, the C# source code is provided in 2 forms: ‘structural’ and ‘real-world’. Structural code uses type names as defined in the pattern definition and UML diagrams. Real-world code provides real-world programming situations where you may use these patterns.
A third form, ‘.NET optimized’ demonstrates design patterns that exploit built-in .NET 2.0 features, such as, generics, attributes, delegates, and reflection. These and much more are available in our Design Pattern Framework 2.0TM. See our Singleton page for a .NET 2.0 Optimized code sample.
Abstract Factory – Creates an instance of several families of classes
Builder – Separates object construction from its representation
Factory Method – Creates an instance of several derived classes
Prototype – A fully initialized instance to be copied or cloned
Singleton – A class of which only a single instance can exist
Adapter – Match interfaces of different classes
Bridge – Separates an object’s interface from its implementation
Composite – A tree structure of simple and composite objects
Decorator – Add responsibilities to objects dynamically
Façade – A single class that represents an entire subsystem
Flyweight – A fine-grained instance used for efficient sharing
Proxy – An object representing another object
Chain of Resp. -A way of passing a request between chains of objects
Command – Encapsulate a command request as an object
Interpreter – A way to include language elements in a program
Iterator – Sequentially access the elements of a collection
Mediator – Defines simplified communication between classes
Memento – Capture and restore an object’s internal state
Observer – A way of notifying change to a number of classes
State – Alter an object’s behavior when its state changes
Strategy – Encapsulates an algorithm inside a class
Template Method – Defer the exact steps of an algorithm to a subclass
Visitor – Defines a new operation to a class without change