A Discovery service, which is a repository to store information about a service, including where it is located and how it should be called.

Transcription

1 Service Oriented Architecture and Open Source Solutions by Adam Michelson Director, Open Source Enterprise Architecture This paper is written for technology architects and individuals interested in the Open Source Solutions (OSS) that are available to build Service Oriented Architectures (SOA) and how they compare to commercial products. The paper first outlines what SOA is and what the primary benefits are as well as the key features of SOA components. Once this foundation is set, the open source perspective is discussed, including synergies between OSS and SOA as well as some of the OSS projects available. Finally, two sample SOA OSS stacks are presented. SOA is not only a set of technologies, but is also a way to design enterprise architecture. Defining what an organization s services should be can be a significant challenge. This perspective is beyond the scope of this document, but if you would like to learn more about the process and methodology to deliver enterprise SOA solutions, please contact Optaros for the white paper titled: A Top-Down Approach to Deliver Service Oriented Architecture. W h a t is SOA? Service Oriented Architecture (SOA) generally describes a technology agnostic architecture that is comprised of loosely coupled modules called services, which interoperate to perform desired business functionality. A service is a set of cohesive business logic that is encapsulated into a course-grained autonomous module. SOA has many benefits, but a primary goal is to increase reuse which should drive down total cost of ownership and improve functional consistency. Loose coupling allows services and partners to be integrated more easily and in a standard way. Once implemented, these services can be reused across your organization and with external partners as the following diagram shows: High-Level SOA Architecture SOA is not necessarily a single technology, but several infrastructure and networking technologies working together. SOArelated infrastructure technologies can include modules such as: A to provide a transport layer for guaranteed messaging. An Enterprise Service Bus (ESB), which is an emerging software product that represents the next evolution of middleware. ESBs typically sit atop a message queue and provides: Copyright Optaros, Inc Some Rights Reserved. This work is licensed under a Creative Commons Attribution 2.5 License

2 Service Oriented Architecture and Open Source - 2 of 7 Advanced message routing, called orchestration Transformation to allow disparate systems to interoperate s acting as adaptors and bridges to communicate with various applications and middleware solutions A Discovery service, which is a repository to store information about a service, including where it is located and how it should be called. An Application Server that acts as a container for services. do not have to reside within an application server, but many newer services do. The, ESB, Discovery Service and Application Server work together to provide SOA its capabilities which include: Transport The network capability to provide message delivery, especially guaranteed delivery. The basic type of transport is a point-to-point, or request-response, message. More advanced transport mechanisms include publishsubscribe, or broadcast, messages Orchestration The ability to sequence tasks using intelligent message routing to support complex workflows to call services performing business functionality. Service s and Transformation Within an organization there are often applications that have unique APIs and data formats, making interoperability difficult. An adaptor can be used to transform a particular application s messages from one format to another. Different middleware solutions can also have unique APIs, and bridges can be used to marshal data formats between them. Adaptors and bridges are both part of a SOA solution to allow for interoperability, here we will call these connectivity and transformation modules Service s. Service Containers These components own the service lifecycle. The Service Container has the ability to instantiate and destroy services, as well as cluster, load balance and fail-over as necessary. If a module is being rewritten for SOA, it is a good idea to write it on a component-oriented infrastructure, such as a module running within an application server, which can integrate with the SOA infrastructure to manage service lifecycles to optimize scalability. Discovery The SOA should support the discovery of available services. Discovery means that the organization can readily find a given service and write clients that can use the service. The web service universal description, discovery and integration (UDDI) repository is an example of a Discovery service. Administration A SOA contains several infrastructure components to achieve all of the features it promises. These components must be maintained. Giving some thought to the administration early in the SOA design will create a more uniform and easier to manage architecture. These components fit together as depicted in the following diagram: Applications Administration Service s Acts as an Adaptor or Bridge, transforming and communicating with various end-points Orchestration Routing, Workflow and Security to call the necessary services to resolve a request JMS SOAP Http Service Container Runs services by managing the service lifecycle Transport Supports queuing and translation over multiple protocols Multicast Transform TCP VM File JDBC ODBC Pop3 SMTP... Discovery Application Server Enterprise Service Bus Network Infrastructure Components of a SOA Infrastructure

3 Service Oriented Architecture and Open Source - 3 of 7 In addition the SOA components can work together to accomplish additional functionality including: Transactionality Support for data transactionality is key to a SOA in order to ensure the data stays clean. Many SOA infrastructure components often will participate in data transactionality for it to be achieved. Given the complexities, how the SOA is able to support transactionsilty should be considered and designed early in the SOA implementation. Compliance auditing, reporting and process monitoring SOA gives organizations a unique opportunity to log activity as messages flow through the SOA infrastructure. Many organizations look to SOA solutions to record transactions to help them adhere to compliance requirements. Like transactionality, every major SOA component may participate in auditing. To limit refactoring it is a good idea to build auditing into the SOA from the outset. Security SOA should support authorization and authentication within every major infrastructure component, including discovery. This is a basic requirement for applications. Consideration should also be given to your organization s compliance, governance and user provisioning requirements when designing SOA security. O p e n S o u r c e S o l u t ions a n d SOA Open Source Software (OSS) is a great partner for SOA and OSS is where many SOA innovations are being spawned. Both OSS and SOA are emerging technologies that are increasingly viable for corporations. This section describes some of the synergies between OSS and SOA as well as some of the open source SOA projects. Also included are two example OSS stacks that can be implemented to create a SOA. There are commercial SOA technologies from companies such as Sonic Software, Cape Clear, Fiorano, Systinet and PolarLake. Larger software vendors such as IBM, Oracle, SUN and BEA also offer SOA-related technologies. Given SOA is still emerging, there is no dominant commercial vendor. The open source community also has several viable SOA solutions your organization can consider and evaluate. Some of the compelling reasons OSS is a good option for SOA include: OSS eliminates licensing fees as an impediment to leverage SOA OSS inherently avoids vendor lock-in and is typically vendor neutral OSS excels at standards-based solutions OSS are proven within the infrastructure layer OSS eliminates licensing fees as an impediment to leverage SOA If an analogy can be made between SOA solutions and Metcalfe's law, where the value of a network grows by the square of the size of the network, the corollary would state that the more services available on the SOA network the better. A commercial SOA s fees are usually based on the number of machines and processing power running SOA infrastructure. The result is that enterprises have typically only been able to cost justify the SOA infrastructure investment to connect its most critical or problematic services and applications. OSS solutions do not have this limitation, allowing an organization to add as many services and applications on the SOA infrastructure as appropriate, realizing its maximum potential. OSS inherently avoids vendor lock-in and is typically vendor neutral Heterogeneous systems within organizations naturally increase the need for a SOA. Purchasing a proprietary SOA infrastructure may eventually lead to yet another internal heterogeneous middleware solution. As commercial products compete, they often add non-standard capabilities to differentiate and may lock customers in by integrating with some platforms better than others to motivate customers to build on specific platforms. OSS has no such agenda, following the build it as simple as possible but no simpler model. OSS history demonstrates that as SOA technologies and standards change, the open source community will aggressively evolve and move to the new standard. Open source solutions also naturally resist being acquired, deprecated, going out of business or changing licensing models the way commercial products and vendors can. OSS excels at standards-based solutions OSS is especially effective when standards exist because the lack of formal product management encourages an open source community to continually build towards available standards. SOA is increasingly becoming standards-based as proven by recent standards that include: JSR 208, or Java Business Integration (JBI) that describes a pluggable architecture for building integration technology on the Java platform

4 Service Oriented Architecture and Open Source - 4 of 7 ReliableMessaging, or WS-RM, is a standard to ensure that a message exchange has been completed correctly with no messages lost or duplicated WS-Policy is a standard that helps define a service s service level agreement, preferences, and capabilities WS-Addressing provides transport-neutral mechanisms to access web services is and provides secure end-to-end endpoint identification in messages These are just some of the relevant standards for SOA, and when the OSS community identifies standards such as these, conforming solutions are quick to emerge. Open source also has the advantage that if a given solution does not have a feature that is required by your organization, it can be integrated and potentially offered back into the OSS community so others may benefit from the solution and it will be available in future versions of the software if an update is taken. OSS are proven within the infrastructure layer Open source solutions excel at infrastructure that glues modules together. A handful of the popular projects that demonstrate OSS s effectiveness at the systems and application infrastructure layer include: Linux operating system Apache HTTP web server Apache Tomcat application server Apache Struts framework Spring Framework JBoss application server JBoss Hibernate data persistence MySQL database server Postgres database server There are some very compelling SOA OSS projects available as well. Increasingly, commercial vendors are themselves participating in open source projects, a trend that is likely to continue. Classic middleware vendors such as IBM, Sonic Software, IONA Technologies, SUN Microsystems and others have begun donating previously proprietary code to open source projects. Below is a sample of some of the SOA-related open source projects available: Project Type Location Description Status Mule ESB mule.codehaus.org An ESB messaging framework. It is a scalable object broker that can handle interactions with services and applications using disparate transport and messaging technologies. ServiceMix ESB servicemix.org An open source ESB and SOA toolkit built on the semantics and APIs of the Java Business Integration (JBI) specification JSR 208. Celtix ESB celtix.objectweb.org A Java ESB runtime and set of extensible APIs to simplify the construction, integration and reuse of business components using a standards-based SOA. IONA Technologies is a contributor. open-esb ESB open-esb.dev.java.net Sponsored by SUN, this will be an ESB runtime based on JSR-208, Java Business Integration technology. In Development In Development JEMS Suite of SOA tools products/soa JBoss Enterprise Middleware System (JEMS) is an extensible and scalable suite of products for creating and deploying e-business applications.

5 Service Oriented Architecture and Open Source - 5 of 7 Project Type Location Description Status ActiveMQ activemq.codehaus. org A fast Java Service (JMS) provider supporting clustering, peer networks, discovery, TCP, SSL, multicast, persistence, XA and integrates seamlessly into Java and J2EE containers. JORAM joram.objectweb.org An implementation of JMS. It provides access to a MOM ( Oriented Middleware), built on top of the ScalAgent platform. AMQ None available at tome of writing A financial industry focused open-source alternative to proprietary message queuing technology using web A Proposal services. Sponsored by JPMorgan Chase & Co. OSMQ osmq/ index.html Open Source (OSMQ) is a pure Java asynchronous messaging middleware framework with an interface that is less complex than JMS. JBoss Messaging/ products/ messaging JBoss Messaging is a re-implementation of JBossMQ. JBossMQ, which evolved from SpyderMQ, is the JBossMQ current production-ready JBoss JMS provider. Axis ws.apache.org/ axis A reliable and stable base on which to implement Java. Synapse wiki.apache.org/ incubator/ A service mediation framework built on web services specifications. Contributed to by IONA Technologies A Proposal SynapseProposal Sonic Software, Infravio, Blue Titan, and will be supported by WS02. Sandesha ws.apache.org/ sandesha Allows a reliable communication between web services and clients. An implementation adhering to Reliable the WS-ReliableMessaging specification authored by Messaging BEA, IBM, Microsoft and TIBCO. RM4GS businessgrid.ipa.go. jp/rm4gs/ index- RM4GS (Reliable Messaging for Grid ) provides reliable messaging for web services following Reliability en.html the -Reliability specification supported by Fujitsu Limited, Hitachi Ltd., and NEC Corporation. openadaptor org A Java/XML-based software platform which allows for rapid business system integration with little or no custom programming. juddi Discovery Service ws.apache.org/juddi juddi (pronounced "Judy") is an open source Java implementation of the Universal Description, Pre Production Discovery, and Integration (UDDI) specification for. UDDI4J Discovery Service uddi4j.sourceforge. net UDDI4J is a Java class library that provides an API to interact with a UDDI registry contributed by IBM Client

6 Service Oriented Architecture and Open Source - 6 of 7 S O A O S S E x a m p le S t a c k s The following two stacks are examples of an OSS infrastructure to support a SOA environment. As you can see combining components from the table above will allow for the creation of many alternative solutions. Here we describe two potential SOA solutions, one that includes an ESB and one that does not. If many heterogeneous service connectors, significant orchestration or substantial support for transactionality are required, then including an ESB is a good choice. If the orchestration is not complex, transactionality is not a major issue and the SOA endpoint service APIs are primarily homogeneous, such as clients and services communicating over exclusively, then an ESB may not be required. Sample SOA OSS Stack With an ESB In Exhibit 1, the codehaus Mule ESB is running atop various connectors and message queues all running on a flavor of Linux. The Apache Tomcat application server and MySQL database are also provided as a run-time environment. This SOA solution also includes: A series of Mule plug-in connectors to communicate with heterogeneous protocols. All of the connectors listed are open source solutions provided by codehaus. There are many other possible connectors, this example includes: ActiveMQ to provide a guaranteed message queue using Java A SOAP Provider for An AS400 DQ Provider for integration with AS400 messaging A JDBC Provider to integrate with relational databases Orchestration rules to manage intelligent message routing using PXE BPEL (Process execution Engine for the Business Process Execution Language), a lightweight business rules and workflow engine included with Mule. This engine will manage messages as they flow from service-to-service, performing the work to complete transactions. Transaction management is also supported within Mule for JDBC transactions, XA transactions or JMS transactions. Mule (An Enterprise Service Bus with Acegi security) SOAP Provider ( ) ActiveMQ (JMS ) AS400 DQ (IBM AS400 DQ message server ) JDBC Provider (Relational Databases ) Tomcat (Application Server) MySQL (Database Server) Linux (Operating System) Exhibit 1 Together, this functionality will result in an intelligent SOA infrastructure that can evolve over time to contain all the logic required for messages to have guaranteed delivery to many disparate services that supports complex orchestration and data transactionality. The client applications can then be altered to discover the services within this stack. This open source stack will provide an organization a robust open source SOA solution.

7 Service Oriented Architecture and Open Source - 7 of 7 A Sample SOA Stack Without an ESB Exhibit 2 shows a less complex and less feature-rich SOA infrastructure, but if it fits your business needs, is all that is required for an effective SOA. Here an ESB is not used, instead we will use an ActiveMQ message queue for guaranteed delivery, and expose it via a web services protocol that is also guarantees delivery because we have included the Sandesha open source project that supports WS-RM. The services are discoverable using the juddi repository, and clients can look up services in this directory using the UDDI4J library. This SOA infrastructure can not handle complex routing or transactionality. In addition it is assumed that all clients and services using the stack will use web services. These are restrictions, but many organizations can effectively use an open source SOA stack similar to this to fulfill its needs. Sandesha ( Reliable Messaging ) Axis ( ) juddi (Discovery Service) ActiveMQ (A JMS ) Tomcat (Application Server) MySQL (Database Server) Linux (Operating System) Exhibit 2 Summary and Next Steps As we have seen, SOA is a new way to design and implement enterprise architecture. SOA allows for a high-degree of reuse and loose-coupling of services across your organization and has many benefits including cost, maintainability, functional consistency and ease of integration. OSS is proven at the infrastructure layer, where SOA components exist. There are many open source solutions for SOA that have real benefits over comparative commercial solutions that we urge you to explore. If your organization does not already have the services identified that should be integrated through an SOA, we suggest the following process to get started: A Proof of Concept (PoC). After the key requirements of your SOA are identified, a PoC that implements these capabilities can used to evaluate a potential SOA solution stack. Once a stack is selected, a Pilot phase is a good next step to control and monitor the initial SOA rollout and to refine the SOA solution. Upon successful completion of the Pilot, an evolutionary rollout may begin to migrate applications and services onto the new SOA infrastructure. A more detailed review of the process to roll out SOA in your organization is fully described in an Optaros white paper A Top- Down Approach to Deliver Service Oriented Architecture. For more information about SOA open source solutions, including our SOA delivery methodology, or any other open source solutions, please contact Optaros. ABOUT OPTAROS Optaros is a consulting and systems integration firm that helps enterprises solve IT business problems by providing services and solutions that maximize the benefits of open source software. Bringing together experts in creating enterprise IT solutions and experts in the power of open source, Optaros plans and builds business systems that give you better value today and increased control in the future. CREATIVE COMMONS LICENSE This work is licensed under a Creative Commons Attribution 2.5 License CONTACT Brian Otis VP, Sales and Partnerships botis@optaros.com phone: (617) x110