There is currently no single definition of an SOA, but the architectural goals of flexibility and business agility give rise to the following broadly accepted, high-level definition:
The architecture style defining an SOA describes a set of patterns and guidelines for creating loosely coupled, standards-based business-aligned services that, because of the separation of concerns between description, implementation, and binding, provide a new level of flexibility in responsiveness to business threats and opportunities.
In Darwinian terms, SOA is the natural evolution of previous distributed architectural styles, such as distributed component object model (DCOM), Common Object Request Broker Architecture (CORBA), and Enterprise JavaBeans (EJB), but embraces standards, particularly those based around XML, to provide a greater degree of interoperability. There's also an explicit emphasis on business alignment, which wasn't prevalent with previous architectural incarnations. This lets SOA provide an ideal platform for business process-driven development, enabling business analysts to truly participate in the software development life cycle—one of its biggest differentiators.
However, simply adopting SOA alone doesn't guarantee a successful project (ESB does not stand for enterprise silver bullet!), and some projects should not adopt an SOA approach at all. We've heard people describe bad architectures and failed projects and say "SOA would have fixed that." But it's just as easy to misuse SOA as it is to create a clunky Java™ 2 Platform, Enterprise Edition (J2EE)-based architecture. If the early implementations of EJB failed, it was because some architects didn't really understand the limitations of the technology (those who have witnessed an application load hundreds of container-managed persistence [CMP] entity beans into memory as the result of some kind of database search know what I'm talking about). But it's just as easy to do the same with SOA. Adopting a similar carte blanche philosophy with services has led to applications that use Web services internally for every single application function call—not exactly a performant solution!
Thankfully we seem to be learning from those painful lessons of the past. For example, the knowledge gained in creating patterns and associated antipatterns that emerged from J2EE experiences has been used to construct similar best practices around SOA. IBM® has been successful in developing reusable patterns and blueprints for SOA applications and industry-specific models that aid in architectural decision making and provide methodologies for service identification.
Using such artifacts can have a dramatic impact on the costs of introducing an SOA. As with any new technology, there are associated start-up costs, and SOA can appear to be additionally front loaded. The emphasis on reuse and flexibility comes at a cost, and this can provide little motivation to evangelize SOA at a project level, where the benefits won't necessarily accrue to the project. Pattern-based accelerators and off-the-shelf assets can help reduce lead time, but ultimately there needs to be a degree of investment in an initial SOA project. Evidence does, however, suggest that organizations embarking on the SOA journey will see those costs returned in the medium term as subsequent SOA projects across the enterprise extend and reuse elements of the service catalogue, reducing their development costs.
When trying to answer the question, What is an SOA?, it's important to consider the perspective of your intended audience, which generally falls into one of two categories: IT or business. Depending on where they stand, they'll potentially have different motivations for adopting service-oriented concepts and see a very different set of potential benefits and pitfalls.
Each perspective provides a set of on-ramps outlining the approach and justification for adopting the technology. There's no definitive way to start the SOA journey; SOA isn't prescriptive, it's all about flexibility, not only in the end result, but in the path that should be followed.
Let's look a little closer at these two viewpoints.
From an IT viewpoint, an SOA defines a software architecture that comprises loosely coupled distributed components cooperating through a communication conduit, which enables the construction of composite applications. SOA aims to bring about component reuse, irrespective of implementation language or host platform, and as such can be thought of as simply an extrapolation of good software engineering practices, taking us from class reuse to service reuse—a true component architecture.
If services are a natural step forward in the development of component-based architectures, then the enterprise service bus (ESB) that links them can be seen as an evolution of the hub-and-spoke integration style. The ESB removes the hub as a single point of failure and brings scalability, intelligent routing, security, and mediation, all based on SOAP and WS* open standards.
So what does this new technology give the IT professional?
- Component architecture: This provides a flexible, platform- and language-independent means of building scalable and reusable software components.
- Loose coupling: The use of an ESB provides an ideal vehicle to loosely bind the service consumer and provider, removing all traces of point-to-point interfaces.
- Utility services: These let you build libraries of reusable IT services providing, for example, an e-mail service, credit card service, and so on, which become enterprise assets with the SOA.
- Legacy enablement: Whilst the norm is to use SOAP/HTTP, a service doesn't necessarily have to be a Web service. Native applications and legacy systems can be full participants in an SOA, using, for example, Java Message Service (JMS) to hook into an MQ cluster on an IBM iSeries® platform, revitalizing a legacy RPG application.
- Platform independence: The adoption of standards has been key within SOA, enabling previously incompatible technologies to work cooperatively across a range of platforms.
These features provide immediate technical advantages that can often create an on-ramp for the introduction of SOA thinking, particularly in the small and medium business (SMB) space where IT often drives the introduction of SOA. This approach can be realized at an individual project level, and whilst some SOA aspects may not bring immediate benefits, the success of a single SOA project can lead to the organic proliferation of the technology throughout the enterprise.
Indeed, the adoption of SOA in this way benefits not only IT, but indirectly aids the business. As more SOA projects are deployed, the benefits of this approach will become apparent:
- Greater component reuse should lead to a reduction in development effort and an improvement in IT project delivery.
- The use of interfaces to isolate specific operational systems should provide greater flexibility in business planning.
- The removal of point-to-point connections should ease the introduction of new business systems.
These factors reduce risk and cost, and lead to greater business agility; however these are ultimately IT lead initiatives—the business is not in control.
The 2006 IBM Global CEO survey (see Resources for a link), encompassing over 750 CEOs from around the globe, found that 87% of CEOs believe that fundamental change is required in the next two years to drive innovation. Roy Schulte, a distinguished analyst at Gartner, captured these sentiments by suggesting that "applications were built to last; now they are built to change."
So what does SOA offer business to manage this change? If you refer back to the definition of SOA earlier in this article, it might be difficult to see how to ignite business interest; loosely coupled, separation of concerns, and architectural style are all very IT-centric terms. However, the key word in the definition from a business perspective is flexibility.
More than ever before, business must be able to adapt quickly to changing business conditions. IT architectures are moving towards an integration model, building business processes that span multiple operational systems, and linking off-the-shelf products with legacy systems. SOA provides the flexibility to support that model and, in particular, provides an ideal platform for embracing a key differentiating technology: business process modeling (BPM).
Through tooling such as IBM WebSphere® Business Modeler, business analysts can graphically define and model business processes. But this is more than a documentation exercise; the artifacts generated by WebSphere Business Modeler can be expressed in the Business Process Execution Language (BPEL), an XML vocabulary that can be imported into tools, such as IBM WebSphere Integration Developer. Here, solutions can be assembled by wiring together business services (or more accurately their interfaces) to the tasks in the business process. The process doesn't care about the implementation of the underlying services or the technicalities of their interface, simply that it fulfills its requirements.
This approach to building software solutions provides clear benefits to the business, which is evident through the following elements:
- Business-driven development: Business analysts lay the foundations for the software development without concerns for technicalities.
- Enterprise-wide solutions: The solutions are explicitly designed to span multiple lines of business rather than being driven by the availability of specific IT systems.
- Reusable business components: You ultimately construct a portfolio of reusable off-the-shelf business services (try asking the IT department of a typical insurance company how different implementations of the create policy function they have).
- Performance indicators: Although not mentioned in this article, the use of BPEL enables key performance indicators (KPIs) to be embedded within the process. These can be used to provide business with intelligent feedback on the state of the system.
- Business agility: IT is focused on providing business value and agility. The impact of changing demands on the business can be minimized and absorbed by rewiring business components rather than wholesale application code changes.
The end result is business analysts effectively defining software processes that are aligned to the needs of their business units and built on an agile environment, thus capable of absorbing the impact of change. Business is in control.
Along with the development of business process models has come a number of supporting industry standards aimed at simplifying interoperability and promoting process and service reuse between IT systems and business partners. The finance, insurance, and healthcare sectors have all seen developments in this area, but this article examines a number of telecommunications-related standards, which are of particular interest to the case study explored later in this article. These initiatives, some outlined in the following sections, provide detailed guidance, at both business and technology levels, on industry best practices and enable software tooling to be aligned with industry models.
Enhanced Telecom Operations Map
The enhanced Telecom Operations Map (eTOM), part of the Next Generation Operation Systems and Software (NGOSS) program governed by the TeleManagement Forum (TMF), is fast becoming the accepted standard for business processes in the telecommunications industry. It serves as a domain analysis reference map and is emerging as the common business language of the telecom industry.
The eTOM uses a hierarchical model, repeatedly decomposing business components through a number of levels until they can be expressed with a suitable level of detail. At the highest conceptual level, eTOM defines three broad functional areas:
- Operations
- Enterprise management
- Strategy, infrastructure, and product
By decomposing these entities through three successive iterations, you can build a component map of the enterprise, identifying the basic building blocks and ultimately the processes, required by a service provider. Within each of the above functional areas, eTOM provides the following three levels of decomposition:
- Level 1 refines the level 0 entities, such as operations, into more specific functional areas, such as customer relationship management (CRM), service management, and resource management.
- Level 2 provides a further level of decomposition into specific processing areas, such as order handling or loyalty retention.
- Level 3 begins to define the typical business activities that may be conducted within the level 2 entities, such as issuing customer orders, authorizing credit, and tracking order handling.
This hierarchal approach is illustrated in Figure 1, which presents a level 2 decomposition of the operations model, highlighting the order-handling component within the Customer Relationship Management level 1 entity.
Figure 1. eTOM operations level 2 decomposition
eTOM V6.0 levels 1 to 3 have been fully implemented in WebSphere Business Modeler, as shown in Figure 2. Here you again see the hierarchal decomposition within the operations area, focusing on the same Customer Relationship Management level 1 entity highlighted in Figure 1.
Figure 2. eTOM operations level 2 decomposition
The WebSphere Business Modeler project hierarchy view shows the four level 1 components, and expands Customer Relationship Management to ultimately display the definition of the Determine Customer Order Feasibility level 3 process. Each modeled artifact is associated with an identifier that follows a standard TMF naming convention.
As these processes have been modeled within WebSphere Business Modeler, they can be assembled and ultimately deployed as part of an SOA. Furthermore, they have been extended to include a fourth level, which defines the service interfaces necessary to fulfill the requirements of the associated level 3 processes, as highlighted in Figure 2. Together this provides a skeletal implementation for an entire telecommunications operation and provides a blueprint to an accelerated SOA development path.
If the eTOM helps standardize the processes within telecommunications operations, then the Shared Information/Data (SID) model, also part of the NGOSS program, provides a common vocabulary defining more than 1,000 industry standard business entities. Initially defined using the Unified Modeling Language (UML) and later through an XML Schema Definition (XSD), these definitions are now available as business items within the IBM SOA tooling, enabling them to be used within process models and provide a basis for defining service interfaces.
The benefit of using the NGOSS SID and its common information language is that it enables business benefits relating to cost, quality, timeliness, and adaptability of enterprise operations, letting your enterprise focus on creating value for its customers.
The Telecom Application Map (TAM) effectively provides a bridge between the NGOSS framework building blocks (eTOM and SID) and real, deployable, potentially procurable operational systems by grouping process functions and information into recognized Operation Support Systems (OSS) and Business Support Systems (BSS) applications or services.
Whilst there can be no categorical solution in this area, the TAM provides a common frame of reference that allows suppliers, consumers, and business partners who operate in this area to understand one another's viewpoints. The TAM has been built on observations of typical systems available today within the fixed, mobile, and cable sectors and will evolve naturally as these systems develop.
From an integration perspective, TAM provides a canonical model of the underlying operational systems and provides generic endpoints for the business functions and processes defined within the eTOM. It acts as a facade, isolating business services from technical implementation details associated with underling operational systems, thereby further reducing the impact of change in this area, fulfilling a key objective of an SOA-based solution.
IBM WebSphere Business Services Fabric
The IBM WebSphere Business Services Fabric provides an end-to-end SOA platform to model, assemble, deploy, manage, and govern composite business services. It provides design-time tooling, a runtime environment, industry reference models, and prebuilt SOA assets to enable rapid development of industry-focused composite business services.
WebSphere Business Services Fabric is also available with an optional telecommunications pack, which builds on the above NGOSS standards and to provide a configurable collection of prebuilt reference business services templates specifically tailored to the telecommunications industry. Using prebuilt assets in this way helps reduce the maintenance costs of telecommunications operational services through reuse, standardization, and consistency of support across IT assets.
Although the concept of governance isn't new within the construction and management of distributed architectures, past failings to successfully implement or adhere to governance have led it to take on increased importance within SOA.
Perhaps the result of lack of governance in this area can be demonstrated by the chaos surrounding some of the early uses of shared libraries, such as Microsoft® Windows® dynamic link libraries (DLLs). Windows is built on a plethora of DLLs, which are system-level libraries of commonly used functionality that are accessed dynamically at run time by many consumers. Desktop applications can also use these DLLs and may, depending on factors such as the current patch level of the operating system, actually introduce new versions of those system DLLs when the applications are installed.
You need to carefully analyze the impact of updating the version of a shared DLL, as the implication of introducing bugs is wide ranging and difficult to quantify. You need to preserve interfaces, deprecate proposed out-of-service APIs, publish changes in functionality to the relevant audience, and test the applications and DLLs that depend on the current version of the library against the new version before its release.
Without performing this kind of due diligence, it's easy to find yourself immersed in a web of cyclic dependencies; releasing one DLL may fix a problem, but ultimately creates two new ones.
SOA attempts to address the similar problem of governing shared services through a combination of education and management technology, providing processes, templates, and best practices through the concept of an SOA Centre of Excellence (CoE). The CoE provides a central body for governance, controlling all aspects of the SOA life cycle, including the following:
- Developmental procedures
- Operational issues
- Service ownership
This builds upon the remit of the traditional project-based design authority role, but elevates it to the enterprise level, promoting reuse, consistency, and standardization across all SOA projects.
Whilst an SOA is clearly applicable to a greenfield development, it is perhaps the area of reengineering where it can provide the most immediate impact. The case study below outlines a business problem faced by many existing IBM clients and is typical of the issues experienced by organizations that have undergone rapid organic growth. This often results in business needs being implemented through tactical IT initiatives involving the procurement of specific systems rather than strategic enterprise-level planning. The introduction of an SOA provides an opportunity to align IT with the business after this type of growth.
The customer's business relies heavily on customized off-the-shelf products to run its telecommunications operation. Each application within the customer's infrastructure has performed well in isolation, but the lack of an enterprise vision led to poor integration between these products, resulting in a very siloed landscape. From an IT perspective, this wasn't necessarily a major issue; each system worked well and was perceived to manage a business process. However, these processes were, in fact, only subprocesses, participating in a larger transaction that crossed multiple lines of business.
As a result of this, users suffered the following symptoms:
- Multiple authentication: Users were required to maintain numerous login credentials to multiple operational systems.
- Poor integration: Little or no automation existed between related processing systems; where integration did exist, it used inflexible proprietary APIs, meaning that change was painful.
- Manual processing: The lack of integration led to a high degree of manual activity, causing data duplication and manual reconciliation.
- Data inconsistency: The degree of manual intervention inevitably led to inaccurate data representations between production systems.
- Poor visibility: The lack of an overall business process meant that it was difficult to generate accurate MIS information.
This study focuses on the integration between the following three operational systems, which highlight the above problems:
- Order management system: Used to record and manage customer orders
- CRM: Acted as the main source of customer information
- Provisioning system: Used to activate the customer's desired network services (that is, roaming, 3G, and so on)
Each system contained application-specific business logic, which executed in relative isolation, as shown in Figure 3. This logic was often interspersed with presentational information, meaning that there was no clear separation of concerns within the architecture, further restricting flexibility. Where systems did communicate, they introduced tight dependencies by using proprietary APIs, which proved unreliable and reduced visibility.
Figure 3. Business subprocesses
These systems were actually utilized by overlapping user groups, with some users ultimately required to sequentially access all three systems to gather the necessary information. This required them to perform multiple logins, interact with different presentations styles, carry out repetitive tasks, and manually reconcile information from each system.
By introducing an SOA, the goal is to unify these disparate systems within a layered reference architecture, as shown in Figure 4.
Figure 4. SOA layered architecture
Each layer provides the distinct set of benefits outlined below, which together provide a customizable and agile business-driven architecture. Let's look at these layers in more detail:
- Presentation layer: Introducing a portal provides a unified user experience across a range of business activities. Its personalization capabilities let us tailor the interface to the user's role, providing the user with relevant content through a single sign-on browser-based environment.
- Business process layer: Although the majority of the existing business logic still resides within the operational systems, the business process layer choreographs the way in which these systems now work cooperatively. It provides a business-centric view, documenting the end-to-end process without technicalities.
- ESB: Think of the bus as the glue in this scenario. It provides a degree of indirection between service provider and consumer (which may be the business process or a portlet). Whilst there's no business logic within the bus, it can perform dynamic routing (for example, to select one of a range of activation services based on some service level agreement [SLA]) and perform interface mapping, effectively unifying disparate underlying data objects.
- Services: This provides a standards-based interface, enabling consumers to access the functionality contained within the service in a platform-independent manner without knowledge of its implementation.
- Service components: These contain software components that implement functionality specified by the service. Service components conform to the contracts defined in the services layer and guarantee the alignment of IT implementation with service description.
- Operational systems: The operational systems are left largely in tact. However, any dependencies between them are now clearly evident within the business process layer. The goal is not to migrate business logic from these applications, but to preserve their production-tested capabilities and, indeed, increase their visibility by exposing them in a standard manner across the enterprise. Providing the service interface doesn't change, the underlying operational systems may change without affecting the service consumer. In this way it's possible to completely replace one operational system with a separate implementation (for example, replacing PeopleSoft with Siebel), enabling business requirements to drive the selection of systems, rather than IT-led vendor considerations.
When identifying services, there are a number of modeling techniques available (such as the Service-Oriented Modeling and Architecture [SOMA] approach used within IBM) that are beyond the scope of this article. But at a high level, the services identified fall into two broad categories:
-
IT services: These typically contain no intrinsic business logic, but
are used to provide service-based access to existing operational systems. Often
referred to as atomic services (as they generally don't depend on any other
services), they are usually provided directly by the underlying operational
system—although it may be custom built using whatever interface mechanisms are
available. The methods exposed are typically general purpose and fine-grained
(for example, a CRM service might provide a
getCustomerRecordendpoint), as they are primarily designed to be reused by other services. Whilst this interface could be accessed by the ESB, it's a best practice to allow this to occur only if the service interface is sufficiently generic and doesn't introduce an element of tight coupling between consumer and provider. -
Business services: These services contain the business logic that will
be used by the business processes, and are often referred to as composite
services, as they may delegate processing to a number of other business or IT
services. Unlike IT services, the methods exposed are generally coarse-grained
and typically relate to a specific business activity (such as
provisionNetworkService).
There is often a third category of service, the information service, which provides direct access to data contained within a (typically federated) data source. However, in this case, all data access was performed through the relevant operational system.
The use of industry-specific business-process templates and data models not only accelerates development within WebSphere Business Modeler, but provides verification on the structure of the business itself, identified gaps, and areas of overlap. However, of potentially greater importance is the level of future proofing it introduces, particularly in the application integration space.
Due to their diverse and complex technical requirements, many telecommunications operators have a heavy reliance on off-the-shelf systems, controlling everything from billing to the physical operation of their networks. These systems must communicate effectively for the enterprise to succeed, and building to industry standards is one of the best ways to achieve this.
At present, the ESB is required for performing mediation operations, translating between the different data representations used by related operational systems. But as standards compliance increases across the industry, this will become increasingly unnecessary. Embracing a common data vocabulary is key in this area, helping to standardize product interfaces, improving performance, removing specific product dependencies, and bringing us back to one of the key goals of SOA, namely business agility.
This solution is based on the following runtime stack and development environment:
- IBM WebSphere Process Server (including WebSphere Enterprise Service Bus) V6.0.2
- IBM WebSphere Portal Server V6.0.1
- IBM Rational® Software Architect V7.0
- IBM WebSphere Business Modeler V6.0.2
- IBM WebSphere Integration Developer V6.0.2
- IBM WebSphere Business Services Fabric V6.0
Aside from the specific features provided by each of the architecture layers, the stack introduces a range of nonfunctional benefits, including inherent scalability (through the capabilities offered by the IBM WebSphere Application Server, which underpins the SOA stack) and a degree of platform independence within the range of operating platforms supported by the stack.
Although we use a number of WebSphere-branded products in this solution, it ultimately represents an architectural paradigm and carries with it a degree of vendor neutrality. IBM's participation in standards bodies—such as W3C, OASIS, and their subsequent implementation of TMF, BPEL, XML, and WS* standards—ensures that this doesn't represent yet another bespoke solution.
This article has shown how you can address real-world business problems through the introduction of an SOA, both from a technology and business perspective. The addition of a complementary technology, such as BPM, adds a further dimension to the benefits of an SOA, enabling your business to actively participate in the software development life cycle.
We've also given some insight into one future direction of SOA, showing how IT patterns have evolved into industry templates, providing technology and process blueprints for the entire enterprise. One of the key objectives for any SOA is to align IT with business needs, but SOA is now going further; by embracing emerging industry models, you see how the SOA philosophy can help business align itself with industry, adopting standards and best practices to provide improved interoperability and future agility.
Thanks to our colleagues Bob Laird and Paul Baker for their input, as well as to Scott's wife, Jackie, for proofreading the article (payback for making me read her 300-page Ph.D. thesis on tuberculosis!).
Learn
- Get a summary of the 2006 IBM Global CEO survey.
- Check out eTOM, SID, and TAM information on the
TeleManagementForum site.
- Read "Design an SOA solution using a reference
architecture" (developerWorks, Mar 2007), a seminal article in the field of SOA development by Ali Arsanjani.
- Find the Gartner report mentioned in this article, "Garner Predicts 2007: Align BPM and SOA Initiatives Now to Increase Chances of Becoming a Leader by 2010," at the Gartner Web site.
- Learn more about the IBM applications mentioned in
this article:
- WebSphere Business Services Fabric
- WebSphere Process Server and WebSphere Integration Developer
- WebSphere Portal Server
- WebSphere Business Modeler
- WebSphere Integration Developer
- Rational Software Architect
- WebSphere Application Server
- WebSphere Enterprise Service Bus
- The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services
applications.
- Play in the IBM SOA Sandbox! Increase your SOA skills through practical, hands-on experience with the IBM SOA entry points.
- The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
- Stay current with developerWorks technical events and webcasts. Check out the following SOA and Web services tech briefings in particular:
- Get started on SOA with WebSphere's proven, flexible entry points
- Building SOA solutions and managing the service lifecycle
- SCA/SDO: To drive the next generation of SOA
- SOA reuse and connectivity
- Browse for books on these and other technical topics at the
Safari bookstore.
- Check out a quick Web services on demand demo.
Get products and technologies
- Innovate your next development project with
IBM trial software, available for download or on DVD.
- Download the following
free trial software:
Discuss
- Participate in the discussion forum.
- Get involved in the developerWorks community
by participating in developerWorks blogs, including the following SOA
and Web services-related blogs:
- Service Oriented Architecture -- Off the Record with Sandy Carter
- Best Practices in Service-Oriented Architecture with Ali Arsanjani
- WebSphere SOA and J2EE in Practice with Bobby Woolf
- Building SOA applications with patterns with Dr. Eoin Lane
- Client Insights, Concerns and Perspectives on SOA with Kerrie Holley
- Service-Oriented Architecture and Business-Level Tooling with Simon Johnston
- SOA, ESB and Beyond with Sanjay Bose
- SOA, Innovations, Technologies, Trends...and a little fun with Mark Colan
Scott Glen is an IT architect with IBM's Advanced Technology Group (ATG). He has over 15 years of experience in the architecture, design, and development of object-oriented systems, providing consultancy to the finance, government, telecommunications, and media sectors. With a particular interest in WebSphere, J2EE architectures, and associated design patterns, he now specializes in SOA, providing consultancy and implementation services to clients across EMEA.
Jens Andexer is a certified IT architect with IBM's SOA Advance Technologies team. He has been developing software for 25 years all over the world, specialising in financial systems, public sector banking, and insurance. Starting his career as a PL/I maintenance programmer, Jens has gone on to have leading architect rolls in many large and complex software development projects. After a mid-career M.Sc. in computer science (software engineering), he joined IBM in 1998 and now brings his experience in host technologies, software development, and software maintenance to SOA customers in EMEA.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
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).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
