• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Microsoft Word - Service Oriented Architecture
 

Microsoft Word - Service Oriented Architecture

on

  • 1,369 views

 

Statistics

Views

Total Views
1,369
Views on SlideShare
1,369
Embed Views
0

Actions

Likes
0
Downloads
38
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Microsoft Word - Service Oriented Architecture Microsoft Word - Service Oriented Architecture Document Transcript

    • Service-Oriented Architecture Authored by D. Ananda Sarma P. Praveen Kumar GUIDE Prashanth Kasturi 1
    • Executive Summary In IT enterprises and Federal organizations, the infrastructure is heterogeneous across operating systems, applications, and software systems. These have to continuously adapt to the changing business environment based upon regulations, mandates, and stakeholder requirements. So, starting new infrastructure from scratch is not an easy option. Enterprises should quickly respond to business changes, leveraging existing investments in applications to address newer business requirements. Service-Oriented Architecture (SOA), with its loosely coupled nature allows enterprises to plug in new services or upgrade existing services to address the new business requirements and provides an option to make the services consumable across different channels. Though, the use of DCOM or Object Request Brokers (ORBs) based on CORBA are considered as the first specifications for Service-Oriented Architecture, unlike them, SOA based on web services has tremendous industry and customer support, because of its loosely coupled nature. Also, the business results of an organization can be improved by adopting SOA. This approach architects and organizes the IT and business functionality that helps the organization in achieving the business goals by managing the change. Adoption of SOA helps an organization to get the business values such as increased agility, less risk, greater return of investment and improved performance. This whitepaper on SOA gives information about what is an SOA, why an organization should adopt it, the underlying architecture and key characteristics of SAO. It also explains briefly about the components and infrastructure of SOA. The authors of this whitepaper have tried to give a brief note on the implementation standards and best practices that an organization should follow to get the business values in the best possible way. Through this whitepaper one can also know the benefits that an organization gets and the challenges that the organization faces, when SOA is adopted. 2
    • CONTENT Executive Summary ............................................................................................................ 2 1. Introduction ................................................................................................................. 4 2. Key Characteristics and Architecture .......................................................................... 6 3. Components of an SOA solution................................................................................. 7 4. SOA infrastructure ...................................................................................................... 9 5. Implementation Standards and Best Practices .......................................................... 12 6. Performance .............................................................................................................. 13 7. SOA Using JBoss ...................................................................................................... 14 8. Business Value .......................................................................................................... 15 9. Benefits and Challenges ............................................................................................ 16 10. Conclusion............................................................................................................. 17 11. Bibliography .......................................................................................................... 18 3
    • 1. Introduction A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. The collection of such services, which communicate with each other, is termed as ‘Service-Oriented Architecture’. These services are loosely coupled, platform-independent interfaces, and are reusable, which means that an application need not know the technical details of another application to communicate with it. This communication can be either passing of simple data or coordination of two or more services for some activity. In either way, there should be a means of connecting the services to each other. SOAs promise to speed development and decrease integration time and effort, but only if they are implemented correctly. Basically, SOA is a higher level of application development that focuses on business processes such as verification of credit card transaction or processing a purchase order, using standard interfaces that help to hide the underlying technical complexity of IT environment. The concept of SOA can be best explained with the following figure. The service consumer at the right sends a service request message to the service provider at the left. The service provider returns a service response message to the service consumer. The request and response connections are defined in such a way that both the service consumer and service provider understands them. A service provider can also be a service consumer. * Though the term, Service-Oriented Architecture may be new, the concept is not a new thing. The use of DCOM or Object Request Brokers (ORBs) based on the CORBA specification is considered as the first service-oriented architecture by many people. The most likely connection technology of service-oriented architectures is the technology of ‘Web Services’. But, SOA is not just CORBA in new form. Unlike CORBA, which is a tightly coupled application connection, SOA is loosely coupled one, such as web services. In tightly coupled applications, it is hard to adapt to changing business requirements, as modifications to one application forces to make changes to the other applications. *http://www.service-architecture.com/images/web_services/service- oriented_architecture_basics.jpg 4
    • Why SOA? In IT enterprises, the infrastructure is heterogeneous across operating systems, applications, and software systems. So, starting new infrastructure from scratch isn’t an option. Enterprises should quickly respond to business changes, leveraging existing investments in applications to address newer business requirements. SOA with its loosely coupled nature allows enterprises to plug in new services or upgrade existing services to address the new business requirements and provides an option to make the services consumable across different channels. The following figure shows how an enterprise could create SOA based supply chain composite application using a set of existing applications that expose the functionality via standard interfaces. * Role of Web services in an SOA: There is a general confusion about the relationship between SOA and web services. SOA is a software design principle, where as web services are about technology specifications and web services’ WSDL is an SOA-suitable interface definition standard. Basically, SOA is an architectural pattern, while web services are services implemented using a set of standards and web services is a way of implementing SOA pattern. The benefit of implementing SOA with Web services is that a platform-neutral approach to accessing services and better interoperability is achieved as more and more vendors support more and more web services specifications. It is important to note that SOA does not require web services and web services can be deployed without an SOA. But, some believe that building an SOA with web services is an ideal approach. However, web services must be implemented properly to create an SOA. A web service, if properly implemented, is little more than an SOA that uses SOAP and WSDL. On the other hand, companies SOA can be built without using web services. Instead, IBM’s WebSphere MQ can be used as a messaging and integration layer to connect legacy systems with the front-end applications. Some other companies build SOA based on publish-subscribe system without web services, where Java Message Service is used as a message layer on top of a web server and an application server. These also use enterprise service bus from Sonic Software to integrate and movement of data. Here, the services are designed like web services without the web service interface. * http://www.javaworld.com/javaworld/jw-06-2005/images/jw-0613-soa1-thumb.gif 5
    • 2. Key Characteristics and Architecture The following are the key characteristics of an SOA solution. Key Characteristics: a) SOA services have self-describing interfaces in platform-independent XML documents. Web Services Description Language (WSDL) is the standard used to describe the services. b) SOA services communicate with messages that are defined via XML schema (XSD) and this communication among consumers and providers or services happens in heterogeneous environments, with less knowledge about the provider. Messages between services can be are key business documents processed in an enterprise. c) SOA services are maintained in the enterprise by a registry that acts as a directory listing. Applications can look up the registry and invoke the service. Universal Description, Definition, and Integration (UDDI) is the standard used for service registry. d) Each SOA service has a quality of service (QoS) associated with it. Some of the key QoS elements are security requirements such as authentication and authorization, reliable messaging, and policies regarding who can invoke services. Architecture: To implement SOA, enterprises need service architecture similar to the following. * Several service consumers invoke services by sending messages, which are transformed and routed by a service bus to an appropriate service implementation. This architecture can provide a business rules engine that allows business rules to be incorporated in a service or across services. This also provides a service management infrastructure that manages services and activities like auditing, billing, and logging. In addition, the enterprises can have agile business processes and can change individual services without affecting the other services. * http://www.javaworld.com/javaworld/jw-06-2005/images/jw-0613-soa2-thumb.gif 6
    • 3. Components of an SOA solution Generally, SOA should describe the following points regarding the services. a) What a service is how it is constructed, used, evolved and maintained? The architecture must define the structure of a service and how to build and use one. For each type of service, the architecture should specify the following. • The appropriate size of the service, known as Granularity • The guidelines for interface design, through which the business services are accessed to pass the documents. • The standard mechanisms for configuring the services. • The artifacts that support a service both at runtime and design time such as specifications, documents and test plans etc. • The specific design patterns that should be followed to keep the services independent and reusable. • The complete lifecycle of service including the versioning and backward compatibility requirements to maintain the services. b) How existing legacy systems are integrated into the service environment? In the enterprises today, much of the business functionality is not in the form of a service. Hence, the essential part of an SOA is how this existing functionality can be exposed as services and connected to the service environment. The SOA must specify the general mechanism for defining these services, wrapping them, and connecting them. c) How different services are combined? The SOA must describe methods, tools and infrastructure for combing the services into larger business processes and services. d) How services connect to each other and pass information at a technical level? A service must be designed to fit into a specific technical, semantic and operational environment and this environment and services it provides must be described by the architecture. The service bus is a key component of the application infrastructure. It provides the communications infrastructure (e.g. ESB) to enable the services to integrate. The SOA must specify the service bus along with the guidelines to use that infrastructure. e) How services share the common meanings for that information at a semantic level? The SOA must define the common semantic environment in which the services operate, such as the data schema that is common across services for consistency and interoperability. f) How services contribute to the enterprise business model, goals and strategy? A business model is a key for understanding the requirements of a common enterprise, especially for shared data. The SOA need not define a business model, but must define how the business model is used to design the services and enterprise business processes 7
    • g) What processes, frameworks and tools are needed to support SOA at the enterprise? The architecture must enable the easy and efficient creation of the services. Framework and tools is the key for allowing independent organizations to create the consistent services. The key components of SOA can be illustrated by the following figure. * * http://www.soainstitute.org/images/contributors/RosenFig1.jpg 8
    • SOA infrastructure To run and manage SOA applications, enterprises need an SOA infrastructure that is part of the SOA platform. An SOA infrastructure must support all the relevant standards and required runtime containers. An SOA infrastructure may look like the following figure. * SOAP, WSDL, UDDI: These are the fundamental pieces of the SOA infrastructure. WSDL is used to describe the service, UDDI to register and look up the services and SOAP as a transport layer to send messages between service consumer and service provider. While SOAP is the default mechanism for web services, alternative technologies accomplish other types of bindings for a service. A consumer can search for a service in the UDDI registry, get the WSDL for the service that has the description, and invoke the service using SOAP. WS-I Basic Profile: WS-I Basic profile, provided by the Web Services Interoperability Organization, is another important part required for service testing and interoperability. Service providers use the Basic Profile test suites to test a service’s interoperability across different platforms and technologies. J2EE and .Net: Though the J2EE and .Net are the dominant platforms for SOA applications, SOA is not limited to these platforms. Platforms such as J2EE not only provide framework for developers to participate in SOA, but also, bring a proven infrastructure for scalability, reliability, availability, and performance to the SOA world. * http://www.javaworld.com/javaworld/jw-06-2005/images/jw-0613-soa3-thumb.gif 9
    • Quality of Services: Existing mission-critical systems in enterprises address advanced requirements such as security, reliability and transactions. The basic web services like WSDL, SOAP, and UDDI do not fulfill these advanced requirements also known as Quality of Services (Qos), when the enterprises adopt SOA for developing and deploying the applications. Hence, standard bodies like World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASISI) have come up with numerous specifications related to QoS. The following are the some of the QoS artifacts and standards. Security: The ‘Web Services Security’ specification address message security and focuses on credential exchange, message integrity, and message confidentiality. This specification leverages existing security standards, such as Security Assertion Markup Language (SAML), and allows the usage of these standards to secure web services messages. Reliability: In an SOA environment, several documents are exchanged between service consumers and service providers. Delivery of messages with characteristics like once- and-only-once delivery, at-most-once delivery, duplicate message elimination, guaranteed message delivery, and acknowledgment are important in mission-critical systems using service architecture. WS-Reliability and WS-Reliable Messaging are two such standards that address the issues of reliable messaging. Policy: Service providers may sometimes require service consumers to communicate with certain policies, for example, a service provider may require a Kerberos security token for accessing the service and these requirements are defined as ‘Policy Assertions’. A policy may consist of multiple assertions. WS-Policy standardizes how policies are to be communicated between service consumers and service providers. Orchestration: In SOA, services can be used to integrate data, applications and components and while integrating applications, process requirements, such as asynchronous communication, parallel processing, data transformation, and compensation, must be standardized. BPEL4WS or WSBPEL (Web Services Business Process Execution Language) is an OASIS specification that addresses service orchestration, where business processes are created using a set of discrete services. Management: In an enterprise, as the no. of services and business processes that are exposed grow, a management infrastructure that helps system administrators to manage the services running in a heterogeneous environment becomes more important. Web Services for Distributed Management (WSDM) specifies that any service implemented according to WSDM will be manageable by a WSDM-compliant management solution. Also, the coordination between partners and transactions involving multiple services are being addressed in the WS-Coordination and WS-Transaction specifications. 10
    • The major goal of an SOA is to build a library of services that can be combined together into business processes to support and improve the enterprise business goals. To achieve this, it is not sufficient if the services are built at random, even though they are well-designed individually. The architecture of SOA must deal with both the construction of services and combination of them, so that the services can be constructed by individual organizations. Logical SOA tiers and Components: The following figure illustrates the primary logical tiers from the application perspective within a SOA. The three middle tiers (Presentation, Business, and Intermediary tiers) primarily exist to connect clients to resources in an efficient and scalable manner that minimizes the effect and scope of changes. Within the system, there are three basic elements, Domain Objects, Business Services, and Technical Services. * * http://docs.jboss.org/blogimgs/logical-soa-tiers-and-components.png 11
    • 4. Implementation Standards and Best Practices The following are the implementation standards and the best practices that are to be followed while building an SOA. Implementation Standards: The following Points are to be considered in implementing large-scale SOA. a) Services need to share a common semantic. Otherwise, we will have services that do not speak the same business language, and cannot call each other without complex data transformation. b) A repository of components such as services and objects is needed to be usable by developers and structured around knowledge sharing. The service in a large SOA should be independent of the implementation details. Web service implementation is just one possibility among many others. A message based integration via a MOM, a call to a method on an EJB interface, a call to a rules engine, a call to a mainframe transaction etc. are all valid implementation details of a business service. Not doing so will introduce unnecessary technical rigidity that limits system performance. Best Practices: a) It is very easy for companies, especially large enterprises with distinct operations, to buy new technologies or integrate applications without regard to how they fit into the overall plan. The challenge in building an SOA is to keep both IT and business people focused on the architecture goals. b) IT architects also need to identify the right level of service to provide and those services also shouldn’t be too fine that defeats the goal of services. On the other hand, if the focus is too narrow, more services are needed, which increases development time. Also, too many services may bring up the network issues. c) The quality of service needs to be taken into account when implementing SOAs. A loosely coupled architecture is good for systems that do not require real-time responses. In such systems, if information doesn’t get where it needs to be on time, the consequences are minor. For example, implementing SOA for air-traffic control system is a bad idea. 12
    • 5. Performance IT architectures that are provisioned to satisfy unpredictable application consumption require a comprehensive service application platform. A Grid infrastructure combined with SOA addresses this need by serving as a virtual service execution platform focused on application, hardware and data virtualization. By distributing application workload across shared system and data sources, the service execution platform inherent in an effective Grid infrastructure drives new level of business performance. The following are the key benefits that enterprises can achieve by deploying an effective Grid infrastructure to support the SOA strategies. a) Application Performance: If Grid infrastructure is used, there will 25 to 50 times improvement in the application performance speed, measured by response time and throughput benchmarks. b) Resilience and Reliability: With guaranteed task execution and mechanisms to ensure recovery and migration in the event of system error, application failure rates can drop by up to 90 percent or more. c) Flexibility and API independence: The Grid layer supports a wide variety of clients that can be quickly virtualized, including Java, .NET, SOAP, C++ and binary executables. d) Rapid development and Deployment: The Grid layer can simplify the development and streamline deployment by providing a standards-based, flexible and intuitive programming model. The following figure shows the separation between the use of batch- oriented and SOA-based grid infrastructure software that defines the types of grid enablement scenarios, which can be applied to the different degrees of grid adoption. It also helps to define the performance profiles for each scenario. * * http://www-128.ibm.com/developerworks/grid/library/gr-gap/f01.gif 13
    • 6. SOA Using JBoss JBoss positioned ‘JBoss Enterprise Middleware Suite (JEMS)’ as the open source platform for SOA. JEMS can be used for deploying enterprise SOA in mission critical environments such as financial services, media and insurance. JBoss is also expanding JEMS to include an Enterprise Service Bus (ESB) to easily develop and deploy SOA to automate business processes and improve enterprise competitiveness. JBoss ESB aims to combine open source products and components to deliver SOA to the market in an easily consumed product. The goal of JBoss is to leverage SOA principles within the ESB architecture itself and present them to third parties and customers. This means JBoss will not tie itself to one standard, but enable greater flexibility with a plug-and-play architecture. It also supports the Java Business Integration (JBI) standard and also supports other ESB and SOA plug-in standards as well. JBoss ESB enables the widest choice of service architectures, such as web services, EJB3, and Seam/Web Beans. Seam can integrate an SOA deployment into Web 2.0 rich clients as well. The following figure illustrates JBoss ESB release. * Logical SOA tiers and JBoss Products: JBoss Enterprise Middleware Suite provides components and products for all the server-side tiers needed to build an SOA. The following figure shows, how the JBoss products span the presentation, business, intermediary, and resource tiers. * http://www.jboss.com/images/slides/JBoss-ESB.gif 14
    • * 7. Business Value SOA is about improving the business results. It is an approach to architecting and organizing the IT and business functionality that enables an organization to achieve the business goals with managing the change. The business values that an organization gets by adopting SOA are as follows. a) Increased agility: SOA helps the organization to be agile to change and helps to quickly respond to the new customer priorities and rapidly introduce new services to a broader set of users and implement new initiatives enterprise wide. b) Less Risk: With SOA, organization can maintain and improve the security and continuity of business operations as well as enable regulatory compliance, while reducing the impact of technology deployments on people and processes. c) Greater return: An SOA deployed according to the business needs of can reduce the cost of maintaining the applications across the organization, including the legacy systems. At the same time, the cost of application integration can also be reduced, as the business processes across customers, partners and suppliers are improved. * http://docs.jboss.org/blogimgs/logical-soa-tiers-and-jboss-products.png 15
    • d) Improved performance: When SOA is used, the IT’s ability to respond to changing the business needs can be improved as the views of data for more effective decision-making are created. As a result, the IT investments can be shifted from maintenance to innovation by increasing both the customer and partner satisfaction. Also, the operational efficiency is increased by automating and streamlining the tasks. 8. Benefits and Challenges The various benefits and challenges of building an SOA can be summarized as follows. Benefits of an SOA: IT organizations may need to evolve to completely get the benefits of SOA like reusability and agility. a) The services of an SOA are loosely coupled, i.e., the service interface is independent of the implementation and developers can build applications by composing one or more services without the knowing the services’ underlying implementations. For example, a service can be implemented either in .Net or J2EE, and the application consuming the service can be on a different platform or language. b) SOAs work very well in heterogeneous environments and developers need not spend too much of time in writing new lines of code to connect applications. Instead, standard protocols such as web services can be used. Also, as most of the SOA code is reusable, the development costs are reduced and SOA also takes legacy investments such as SAP, Siebel, Oracle etc. to make them work together. c) By identifying the capabilities of existing systems and controlling them, the value of the IT systems can be maximized while minimizing the risks. Also, building services using either Simple Object Access Protocol (SOAP) or Web Services Description Language (WSDL), not only simplifies the integration process, but also, lets customers and business partners share information more easily across company firewalls. d) Another benefit of an SOA is that it forces IT architects to think in terms of business architectures, not technical architectures. So, to build a better system, the operations people together with the IT architects can think of the best way to design it based on business flows and how to meet the needs of the business. And implementing that design, which involves large scale of integration, becomes an easy task. For that to work, the business people have to think of the best ways to run their business and the processes that need to be put in place to improve the level of customer service. By exposing and sharing information across applications, companies can get more business performance data in real-time, improving business intelligence. e) In addition, IT architects can easily incorporate new technologies into SOA, reducing risk and expense while speeding the development of new 16
    • applications and finally, the benefits of easier integration leads to greater ROI. Challenges in building an SOA: Though there are many benefits that an SOA provides with, the organizations have to face some challenges such as the following. a) The biggest challenge is security. It is always easier to secure a closed system than an open architecture. To overcome some of these challenges, the companies should move slowly when setting up an SOA, focusing first on business processes that don’t require a high level of security. Managing the complexity of services configuration requires a good SOA governance model. b) When a complex net-centric business process is created, monitoring and auditing requirements also become complex. For example, when any transaction in a service-oriented architecture fails, finding out what went wrong and where the transaction dropped can be a challenge. c) Because of the loosely coupled nature of SOA, changes in or degradation of performance for one service could break many applications within the SOA. Tracing the interactions across the loosely coupled implementations to see whether a new application is creating measurable load on the existing services becomes a challenge. d) The final issue is the cost. Building an SOA isn’t cheap. Reengineering the existing systems architecture costs lot of money. It also requires significant human resources, including business analysts to lay out the business processes, systems architects to turn processes into specifications, engineers to develop the code, and project managers to track it all. 9. Conclusion Federal Organizations have to continuously adapt to the changing business environment based upon regulations, mandates, and stakeholder requirements. Generally, the IT response to such changes would be to work on new projects involving new applications, hardware, software, and services that take months or years to complete. A Service-Oriented Architecture (SOA) helps in overcoming the software infrastructure challenges for organizations that require more flexible applications and systems, and greater alignment of IT with business goals. This is an IT strategy based on building IT systems with the common parts that enables the business transformation. Unlike CORBA or DCOM, SOA based web services has tremendous industry and customer support. The value of SOA can be better known from the concept of re-use and the flexibility and the agility gained from being able to reuse the components to address the new business requirements. The re-use of internal and external services accelerates the return on investment for an SOA strategy. 17
    • 10. Bibliography 1. http://jboss.org/jbossBlog/blog/pfricke/ 2. http://news.taborcommunications.com/msgget.jsp?mid=396739&xsl=story.xsl#top 3. http://www-128.ibm.com/developerworks/grid/library/gr-gap/#Introduction 4. http://www.soainstitute.org/articles/article/article/key-components-of-soa.html 5. http://www.service-architecture.com/web-services/articles/service- oriented_architecture_soa_definition.html 6. http://www.cio.com/archive/011504/soa.html 7. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html 18