原諒
承諾
夜
往昔
願望
尋
Understanding Services Oriented Architecure
Introduction
If you ask a computer expert what is the trend in modern Information Technology on the server-side, you may get the answer web services, SOA(Service Oriented Architecture) or Cloud. Among these answers, the term SOA is the most confusing. Let us have a simple discussion on basic SOA concept.
What is Services?
Firstly, we have to know more about “services". According to the dictionary, service is a facility supplying some public demand, and the work performed by one that serves, help, use, benefit other. Services should be non-material equivalent of physical goods. As a matter of fact, it can be a process that creates benefits by facilitating either a change in customers, a change in their physical possessions, or a change in their intangible assets. Computer system especially software is target to model or facilitate the real world services, so a service in the computer system is common. the example of services in computer system are as followings:
- A Windows Service: Plug and play, Windows backup, DHCP Client,
- Software Service: Distribution transaction Service, Server resources management, Logging
- Business Service: Order fulfilment, Customer Management
Services refer to high-level distinctive functional components that encapsulate business or system processes. Conceptually, they are “Lego Block" in the computer system.
SOA overview
A service-oriented architecture (SOA) is basically a collection of services that are able to communicate with each other, SOA is an architectural style to applying loose coupling In the computer system, a service that provided by a service provider is a unit to achieve required end results for a service consumer. Each service is the endpoint of a connection which can be used to access the service and interconnect different services. Furthermore, communication among services can involve only simple invocations and data passing, or complex coordinated activities of two or more services.
SOA common goal
As you know the SOA is confusing, it is not well-defined yet. In fact, architectural guidance is relatively fewer so industry focused on concrete technologies, vendor usually have its solution and tools for SOA, we are now usually developing reference architectures based on software patterns to providing architectural framework for Service-Oriented Architectures (SOA). SOA definition Service-Oriented Architecture is an architecture styles or approach to archive the following goals:
- Rationalize enterprise integration
- establish process driven applications
- Re-use existing services to build new value
SOA heavily relies on standards for implementation:
- Standard interface definitions
- Standard data format
- Standard wire protocols
- Standard security protocols
Why SOA?
Employing SOA can bring a lot of benefits to an enterprise. Such as Standardized interfaces and data models Re-use, and Composability. some of important service-orientation design principles
- Standardized Service Contract
- Service Loose Coupling
- Service Abstraction
- Service Reusability
- Service Autonomy
- Service Statelessness
- Service Discoverability
- Service Composability
Primary Concepts for SOA
- Service: A mechanism by which needs and capabilities are brought together.
- Service Description: Artifact declaring all relevant aspects of a service required to interact with the service. Capability: an ability to perform a specific set of functions resulting in a real world effect.
- Visability: The capacity for those with needs and those with capabilities to see each other and interact.
Characteristics of Services in SOA
The following are the characteristics of services in SOA:
- Coarse-grained
- Contract-based
- Modular
- Location independent
- Model-based
- Stateless
SOA Properties
- Services offer public interfaces
- Platform-independent
- Interfaces are defined using interface description languages (IDL)
- Stateless interaction, interaction is independent of each other
- Many protocols are used and co-exist
- SOA is not equal to Web services
- Web services realize SOAs
SOA concept diagram
Factors for considering SOA implementation
- Efficient use of system resources
- service maturity and performance
- EAI (Enterprise Application Integration): Packaged EAI solutions in future would have SOA as basic tenet and would continue to be the prime choice for large-scale integration.
SOA Basic Components
Patterns and SOA
Patterns based approach can be used for architecting SOA related system or application. Followings are Architectural significant artifact:
- Object-oriented design patterns
- General software architecture principle
- Distributing, messaging, resource management computing related patterns
- Networked and concurrent objects
- Component and language integration
- Process-driven architectures, business objects, and workflow systems
- Integration of processes and services
Pattern-based reference architecture for SOA
- Principles are used in a specific way to develop the reference architecture
- Systemic qualities are concerned.
- SOAs are implemented in a technology-neutral way
- Concrete guidelines are also given
The OASIS Reference Model for SOA
Oriented architectures and analysis / comparison. It is also a framework for understanding significant relationships among the entities in a SOA environment. OASIS Reference Model is an 2006
SOA and Java EE
Java API and Service are similar, both can utilize proxies. Moreover, RMI patterns are subset of SOA patterns. SCA and SDO are good SOA implementation approaches, standardization is strong in Java, so getting SOA done in Java EE is easy. The available technologies for services
- JAX-WS
- JAX-RS
- SCA, SDO
- Jini, RMI, EJB
- WSIT
- WS-Policy, WS-Security, WS-RM, WS-TX
Java EE platform allow to explore the use of BPM technology in the application, Java EE platform will allow SOA style web services to be exposed with relative ease. EJB architecture based system was easily extensible to SOA style web services., however layering analysis may be required, if the EJB components are not nearly a services.
OSGi
OSGi, created for Java-based systems, provides a framework for modular systems. OSGi makes it possible to define the dependencies of each individual module with the others and enables users to control the lifecycle and dynamically change each component of the system.
OSGi is a specification and the most common implementations can be counted as Equinox, Apache Felix and Knoplerfish.
It is worth to further discuss some of the concept and related tecnologies, please come again…
Peter
Software Architecture
Introduction
If you work in IT industry, you must heard somethings about software architecture. Moreover, software architecture are playing a more and more important role in the industry. In order to have a success in software development, we need to have a good software architecture. Software architecture captures early decisions about the high-level design, and allows reuse of design components between projects. However, the software architecture is not an easy concept. There are many things to learn to become an architect, the body of knowledge about software architecture is huge enough to fill hundreds of books. Let us have some basic ideas on software architecture here.
In short, Software architecture describes the structures of a computer system. A software architecture consist of software elements with their system modules or software components. The external visible properties typically represent services provided to other elements. The relationships of element usually describe how elements interact with others.
As an architect, you need to balance the different stakeholder benefit in order to have a “good" software architecture, remember that you cannot 100% fulfil of each stakeholder as resources is always limited and there are conflicts among the requirements.
Need for Architecture
Why architecture is needed in modern software? Three crucial changes in software engineering have led to us to aware the importance of architecture, they are Scale, Distribution and Security. During the past decade, the scale of IT systems extend much, there are many large system with hundreds of server and thousands of process running in the computer system. Moreover, the capability of scale up are now natural requirement of the computer system. On the other hand, the computer system is migration from mainframe to highly distributed system known as cloud. Finally, we have enhanced many security features in the computer system as the security nowadays is a major quality of a system.
The Goal of Architecture
With the three crucial changes of computer system, software architecture aim to resolve the issues of scalability, distribution and security. Furthermore, the software architecture also help to reduce project risks and capture quality-related decisions. On the other hand, software architecture can facilitate the design, implementation and deployment of the application. Software architecture focuses on quality-related requirements, instead of functionalities. The goals of software architecture often include the bridge of the abstract business ideas to a concrete computer system. Followings are common goal of software architecture:
- Improve quality of services(QoS) of the system such as scalability, portability and maintainability.
- Building a effective secure environment.
- Respond various changes
- Handling the complexity in a effective manner
- Utilize existing investment
- Perform better risk management
- Better communication
Standards
Early in 1960’s we have used the term “software architecture, but it became prevalent only in the begining of 1990’s. The first formal standard – IEEE 1471-2000 , Recommended Practice for Architecture Description of Software-Intensive Systems give people the formal definitions about software architecture area. In 2007, ISO adopted IEEE 1471-2000 ISO as ISO/IEC 42010:2007. While in 2011, IEEE 1471-2000 was superseded by ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description .
Architecture View
If a software system capture real world requirement, its software architecture has to be more or less complex. A single view is not sufficient to address requirements, so software architecture is commonly organized in views (multiple perspectives) especially in Large software systems. Architects describe the general information on view in software architecture, views are instances of viewpoints, examples of viewpoints are as followings:
- Use case view
- Data View
- Functional view
- logical view
- Implementation view
- Development view
- Deployment view
Some architecture frameworks or approaches gives a reference of different viewpoints collection of the system or enterprise IT, expamles are as followings
- 4+1 (UP)
- DODAF
- MODAF
- TOGAF
- Zachman framework
- Federal Enterprise Architecture
- RM-ODP
Software architectural principles
Many architecture principles have been presented in the context of Software Engineering and Object-Oriented Technologies. In software architecture perspective, it focus on the architectural meaning of those principles, It also concern the inter-dependencies among the components. However only with principles are not sufficient for building a good architectures because they provide only general guidelines. Architectural styles and architecural patterns are also important.
Architecture Styles and Architectural pattern
An Architecture style in software system is a collection of principles that can be used for system building, it usually has their focus such as data integration, networking, distributed system and etc. The Implementation of an architecture style require the software and hardware design and implementation. In maby cases, multiple Architecture styles may be used to define a concrete architecture.
A (software) Architectural pattern is a standard design in the field of Software Architecture with applying some architecture principles, but it is not equal to an architecture. An architectural pattern is a concept that solves and delineates some essential cohesive elements of a software architecture and Different architectures may implement the same pattern.
Examples of architectural styles and patterns
- Blackboard
- Client–server model (2-tier, n-tier, peer-to-peer, cloud computing all use this model)
- Database-centric architecture
- Distributed computing
- Event-driven architecture
- Front end and back end
- Implicit invocation
- Monolithic application
- Peer-to-peer
- Pipes and filters
- Plugin
- Representational State Transfer (REST)
- Rule evaluation
- Search-oriented architecture (A pure SOA implements a service for every data access point.)
- Service-oriented architecture(SOA)
- Shared nothing architecture
- Software componentry
- Space based architecture
- Structured (module-based but usually monolithic within modules)
- Three-tier model
Architecture interaction
Following Diagram show the major Architecture Interaction
Major Deliverable of software architecture
There are three major software architecture deliverable, they are domain model, architecture blueprint and Architecture prototype.
Domain Model captures the structural and the behavioral relationships between system-level components. Architecture Description a guideline or a model that shows where components should be located and how they communicate, that also represents the deployment environment. The Description are usually in document form known as Architecture Description Document (ADD) and typically created based on UML diagrams. Finally, Architectural Prototype provides an end-to-end demonstration or implementation of the primary technologies and components, it usually act as the technologies base or proof of concept of the target software architecture. The architecture blueprint is the collection of the domain model and Architecture description Document, It facilitates communication between stakeholder.
The software architecture can be designed, analyzed, documented and implemented.
Architecture activities
There are four major disciplines related to software architecture, they are usually performed iterative and at different stages of the software development life-cycle.
Architectural analysis: It is a process to understand the requirements of the system from the stakeholder, the requirements can be divided into two main categories, the functional and non-functional requirements. Architecture focus on the non-functional requirements including the quality attributes (Quality of services), quality attribute can be divided into run-time and development time non-functional requirements, they are well-defined in ISO/IEC 25010:2011 standard.
Architecture design: As the name suggested, the architecture design is the creation of the architecture. nowadays, we are usually made use of reference architecture available in the industry to help developing own architecture. adopting technologies such as Java EE and using software framework have give us some of reference architecture.
Architecture evaluation: it is the process of determining how well of the current or under designing architecture fill the requirements or not. Architecture evaluation is an important process but often missing in software development project. Moreover, it is difficult to carry out the evaluation when the project schedule is tight. However, some of the techniques on Architecture evaluation have been developed to help the architect crop with the tasks, they include Architecture Tradeoff Analysis Method (ATAM) and TARA.
Architecture evolution: It is the process to maintain the software architecture to adopt changes.
While performing the above discipline, the Knowledge Management, Communication, decision making and documentation activities will be carried out.
System architecture and Enterprise Architecture
As I told, there are many things to learn to become an architect. There are many topics worth to be discussed here, such as architecture description languages, architecture viewpoints, architecture frameworks, architectural styles and patterns. SOA (Services Oriented Architecture) is actually one of architectural styles.
On the other hand, the system architecture and enterprise architecture are two software architecture related concepts, they have broader concerns.
Systems architecture is the architecture of systems that consists of both hardware and software. Moreover, Enterprise architecture concerns how software systems support the business process and goals of the enterprise, there are also some popular reference model of enterprise architecture such as TOGAF and Zachman Framework.
We will have further discussion on these topics, please come again if you are interested.
Peter
Object-Oriented Principles
We have mentioned the basic concept of Object-Oriented, but it seem to be not enough for a good software since we still need somethings else – we need good design and architecture. What are them? Is there any hint for us to have good design and architecture?
To answer these questions are not easy tasks. We may need to read thousands of papers and get much experience to know what are the good software design and architecture, since they are not simple concepts. However, they are all come from the same base, that is Object-Oriented principle or we can call them design principles.
Why need OO principles?
Basic syntax of an OOP is not hard to learn, the issues is how we can enhance the program in order to leverage the advantages of OO. You may already learn something about Patterns such as GoF, they are reusable solutions. In fact, they are all come from basic OO principles. Fortunately, there are a few of them which are easy to follow.
Overview
Poor design and programming is everywhere, it make the OOP seems to be not a good stuff.
Two main issues are always come with OOP, they are coupling and cohesion.
coupling is the degree of dependencies between two modules(usually classes or components) and
cohesion is how diverse are the things inside a module. Two main goals for better software are
- highly cohesive modules.
- Loosely coupled modules
Let us discuss a bit more on coupling and cohesion at first.
Coupling
Modules have to be realted in order to compete task or we can think they have to interact with each other, so they can provide functionalities to others, Modules relate with the followings way:
- Invoke operations (function call)
- Passing data
- Defined in terms of each other
It is clear that coupling is needed but we should always keep them simple. Moreover, coupling should be a direct connection and we should give enough flexibility to the coupling.
cohesion
It mean class should represent a single abstraction or it should address a single general responsibility. With the procedural programming practice, we often make a bad OO modules, that may lead the followings problems
- Hard to understand
- one-to-one relationship often exists, too many connection / dependencies.
- Classes hard to change
- Classes often need to modified.
- Performance issue
The object-oriented principles are going to help us to write flexible and better code by achieving high cohesion and low coupling.
Common OO principles
Real-world problems can be fixed according sound principles.
Followings are some common OO principles :
Open-Closed Principle (OCP)
A module (class) should be open for extension but closed for modification"
(originally by Bertrand Meyer).
This principle describes that classes should be open for extending without requiring modification. That is to extend the behaviour of a system when responding to changes by adding new code without modifying the existing code. Abstraction and also polymorphism by subtype are the keys to the Open Closed Principle.
Single-Responsibility Principle (SRP)
A class should have only one reason to change (originally from Martin).
It is a matter of cohesion. A responsibility is “a reason for change.” and axes of change. If the class has two responsibilities, they are coupled in the design, and so have to change together. Simple, yet hard to get right.
We often use delegation to achieve SRP.
Interface Segregation Principle (ISP)
Many client-specific interfaces are better than one general purpose interface. (Robert Martin)
If a class has several different usage, create separate (narrow) interfaces for each usage. It should be better than all usage share the same, large interface. Clients can be as small as possible and as coherent an interface as possible. large interfaces lead to inadvertent couplings and may add dependencies between classes.
Liskov Substitution Principle (LSP)
Subclasses should be substitutable for their base classes. (originally by Barbara Liskov)
A client of a base class instance should still work with the instance of a derived class instead. A derived class should have some kind of specialized behaviour, it should provide the same services as the superclass with some variety in the behaviour only. The contract of the base class must be honoured by the derived class.
If this principle is violated, the Open-Closed Principle will also to be violated too.
Dependency Inversion Principle (DIP)
Depend upon abstractions. Do not depend upon concrete implementations (originally defined by Robert Martin).
High level modules should not depend upon low-level modules. Both should depend upon abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions. High level classes should contain the “business logic”, low-level classes should contain the details of the (current) implementation. Access instances using interfaces or abstract classes is a common way for dependency inversion.
Don’t Repeat Yourself(DIY)
DRY says that every piece of system knowledge should have one authoritative, unambiguous representation (Andy Hunt and Dave Thomas)
It is a principle for general software development, so it may be the most fundamental one. The principle target to reduce the repetition or duplication of information, it is specially important to the modern muti-tier architecture such as JavaEE. It apples broadly on software development including database schema, testing and coding. The violations of these principle are known as WET, which usually refer to " we enjoy typing", “We edit terribly" or “Write Everything Twice". Sometimes, we may use WET to solve a particular problem or act as a temporary solution, but we should do it with a strong rationale.
As an experienced developer, we should know how to reduce the duplication of code by appropriate practice and proper abstraction. In short, we can reduce the rrepetition in process calls by automation and reduce the rrepetition in logic by abstraction.
The DRY principle provides fundamental guidance to software developers and let us have simpler, more maintainable, higher-quality applications. We should follow this principle with regard to structure, logic, process, and function in the development.
Favor composition over inheritance
Because inheritance exposes a subclass to details of its parent’s implementation, it’s often said that ‘inheritance breaks encapsulation‘". (Gang of Four)
The principle state that the favour way to create thing is composition rather than inheritance. Using inheritance is simple with OOP but constructing a complex hierarchy of inheritance do not allows the software to extend easily. Although the overuse of inheritance in OOD is common and understandable, favor composition over inheritance is a design principle that gives the design higher flexibility, giving business-domain classes and more stable business domain in the long-term. In other words, HAS-A can be better than an IS-A relationship.
The implementation of composition is often not as simple as inheritance, It typically begins with the creation of various interfaces.
Delegation principle
Using prototypical objects to implement shared behavior in object-oriented systems – Henry Lieberman
This principle state that it unnecessary to accomplish all the task in one module, delegates the task to an associated helper whenever possible. The principle help us create a programs with flexibility and it often given as the way to composition. However, there are always some confusion with delegation, the concept of delegation is not just a method forwarding in object collaboration.
Java and OO principles
The original Java APIs have implement many principles mentioned above, you can just enjoy the benefits by using Java as OOP. By using suitable principle you can create a better program with high cohesion and low coupling. One of the best way to implement corresponding principle is the pattern. However, apply a suitable principle to a particular problem is not a straightforward and easy thing, and there are always some trade-off.
We will use Java as an example to learn more for those principles.
Peter
彼得博客 
近期迴響