Glauco Castro holds a degree in Information Technology, is a SOA Certified Professional certified by SOA School and Oracle Service Oriented Architecture Infrastructure Implementation Certified Professional certified by Oracle. In the certification process for SOA Architect, has over 15 years experience in the IT field as a Systems Analyst, working in the area of BPM, ECM and SOA projects for over 5 years. He is currently the IT Director of Tractus Consulting, responsible for creating solutions for a wide variety of information technology projects.
Yuri Marx is the SOA Architect at CDS and has over 12 years of experience in Development, Design, and System Architecture. Besides being an expert in SOA, he also has extensive experience in Process Development and Software Architecture. With extensive knowledge in various areas of Software Engineering, he has received 22 technical certifications including SOA Architect, Oracle SOA Expert, SCEA, BUSY, RUP, ITIL, CobiT and so on. Today, he is committed in the development and evolution of the SOA development process and also CDS SOA Architecture.
Service-Orientation with Oracle SOA Tools Published: February 27, 2013 • Service Technology Magazine Issue LXX PDF
Abstract: The Oracle SOA Suite [REF-1] is a middleware offering that can be implemented in compliance with service-orientation principles [REF-2]. Conversely, the features provided by this platform can help optimize the application of these principles to facilitate the connectivity and reuse of shared services and service-oriented solutions. This article explores the marriage of service-orientation with the tools and technologies of the Oracle SOA Suite.
Preliminary consultation with experienced industry professionals and identification of the market's best practices can help decrease the high potential for error that accompanies first-time, independently executed SOA implementations. The objective of applying the eight SOA principles as identified by Erl is to propagate the best practices of service development, through uniting practices with mature, service-oriented technology.
Let's first recap Erl's eight de-facto principles of service-orientation:
Oracle SOA Tools
Oracle has a portfolio of tools for the SOA development lifecycle and its governance. These tools can be used to help SOA implementation teams apply service-orientation principles, and are commercialized by Oracle into three categories:
Oracle provides two integrated development environments (IDEs) for the SOA stack. The first is Jdeveloper, which is an IDE for application development that includes SOA and its components. The second IDE is the Oracle enterprise pack for Eclipse (OEPE), which enables Eclipse users to build enterprise service bus (ESB) artifacts [REF-3]. Oracle is also expected to provide Oracle service bus (OSB) support within Jdeveloper in the future.
Both IDEs can be installed on Windows, Mac, and Linux using a Java virtual machine (JVM). However, the standard Jdeveloper installation for the SOA Suite includes a WebLogic server (WLS) installation, which is not freeware but a free license for learning, product assessment, and some forms of development for single users.
Oracle SOA Suite
This product suite is composed of components that collectively comprise an environment for the implementation, deployment, and management of SOA implementations. This environment is made complete by the addition of a WebLogic server and database, which are separately downloaded and installed.
The following features and tools of the offering are highlighted:
In addition, the Oracle SOA Suite also includes the following adapters:
There is also support within SOA Suite for integration with a UDDI registry.
SOA Governance Tools
In another of his books titled SOA Governance: Governing Shared Services On-Premise & in the Cloud [REF-5], Erl describes how the SOA governance program comprises precepts, processes, and people that collectively realize best practices and principles. A well-defined methodology that is regulated and overseen by a governance committee and stakeholders is used to enforce, enable, and enhance these practices and principles.
Using Oracle governance tools to apply the methodology is more efficient when the development process is automated, as these governance tools facilitate the creation of services repositories, documentation of services, and dynamic application of policies. The tools comprising the Oracle SOA governance solution are:
SOA Principles and Oracle SOA Tools
In SOA Principles of Service Design, Erl explains the reasoning for the implementation of the eight principles when creating services. Applying these principles guarantees that services are developed using practices that obtain the highest return on investment (ROI).
Using either a market tool or complete suite of tools to assist in the implementation of SOA principles is usually compulsory, given the complexity of SOA project implementations. The relationships in which the Oracle SOA tools enable the application of the eight service design principles are shown in the following overview (Table 1):
Table 1 - The relationship each service design principle has with Oracle SOA tools is shown in this overview.
The application of the service-orientation principles in accordance with each principle's relationship with the components of the Oracle SOA Suite are explored in the following sections.
Standardized Service Contract
During development, XSD and WSDL artifacts can be stored within the Metadata Store (MDS) for reference by multiple service implementations, to enable a consistent view of the canonical data model.
The Standardized Service Contract principle requires a service contract to be created before the creation of a Web service, as well as consideration of the data structure or XML schema definition (XSD) that will be used. This approach is crucial for identifying the canonical data structure of the entire organization to provide an organizational view of the information, as opposed to the traditional departmental view by which vertical applications are developed.
Development tools need to have the following characteristics in order to realize the Standardized Service Contract principle:
The characteristics of the Oracle Jdeveloper are illustrated in Figures 1 to 4:
Figure 1 - A screenshot of wizards creating an XML schema is shown.
Figure 2 - The visual development of the schema is depicted in this screenshot.
Figure 3 - A screenshot of service repository connectivity.
Figure 4 - A screenshot of source code generation.
The Oracle Jdeveloper and OER are suitable for creating new services, while ESB offerings effectively realize the reuse of existing organizational assets by creating a wrapper to standardize the assets with the correct contract standards.
Oracle's service bus can internally register and expose a non-standard service to service consumers as a standardized contract, with the option of creating transformations and other internal actions before returning the response message.
Figure 5 - A sample pipeline pair node scenario.
Policies can be standardized by the application of the Standardized Service Contract principle, in an environment that allows for the creation, maintenance, and application of the policies to services. The Oracle Web services manager (OWSM) from the Oracle SOA Suite has ready-to-use policies in its repository, and can create new policies and centralize the ones that are inherited from existing policies. The OWSM is a Web tool that is accessed from the Oracle SOA enterprise manager, as shown in Figures 6 and 7:
Figure 6 - This screenshot illustrates the steps to access the OSWM for policy management and administration.
Figure 7 - The policy application and management functions of Oracle's enterprise manager are shown in this screenshot.
Service Loose Coupling
Services need to impose low consumer coupling requirements when decoupled from their surrounding environment, in accordance with the Service Loose Coupling principle. The requirement for low consumer coupling refers to service orchestration and the use of services by systems, business processes, and compositions. Any tool that implements the VETRO pattern supports loose coupling, as follows:
Oracle SOA tools offers two VETRO options for SOA developers (Figures 8 and 9):
Figure 8 - This screenshot shows the first VETRO option, which is the Oracle mediator or SCA implementation in the Jdeveloper IDE.
Figure 9 - A screenshot of the second VETRO option, which is the Oracle service bus or OEPE.
Table 2 defines the most suitable use cases for each tool:
Table 2 - The different uses for the Oracle mediator and the service bus are summarized.
The extraction, isolation, and encapsulation of business rules in separate services enable the application of the Service Loose Coupling principle, since services are typically used to process business rules but not entire functions. Using Oracle business rules allows services to be created that can expose business rules as services themselves. The business rules can be dynamically changed over the Web using declarations and expressions after deployment, and are specified using decision tables of if-then-else structures in natural language (Figure 10).
Figure 10 - The business rules editor.
Another method of reducing coupling between services is to encapsulate graphical user interfaces (GUIs) in services and for use in the VETRO and BPEL tools. Creating traditional Web applications to input data into services is not necessary, since the GUI services expose forms to the user via the corporate portal to gather the information required to complete the flow. The Oracle human task tool implements this functionality through tools to generate forms based on data objects. This is shown in the screenshots depicted in Figures 11 to 13:
Figure 11 - Three human tasks are used by the Oracle mediator to provide GUIs to a BPEL process.
Figure 12 - A screenshot of the GUI definition in the Jdeveloper.
Figure 13 - A user is accessing a GUI service from the Oracle worklist.
Two methods can be used to execute the Service Loose Coupling principle. The first involves applying policies during runtime to decouple from service contracts, while the second uses application server resources to decouple services from their surrounding environment. The Oracle Web services manager can be used to apply policies to services at runtime, in order to decouple the services from the SLAs. The latter method can be implemented by pointing to external resources that use the Java naming and directory interface (JNDI), which is present in Oracle WebLogic and other Java EE application servers.
Services that need to connect to a database can use the database connection pool, which is configured in the WebLogic and exposed through the JNDI. The services are not affected if the address of the database server changes, because the connection pool keeps the same JDNI name. The only parameter that has to be changed is the database server address, which can be done via the WebLogic console without impact on the service.
An effective method for decoupling services is to use events. Publishing an asynchronous event in a message queue and consuming events from other queues decouples service contracts from both the service producer and service consumer, since both services will know only the queues and their messages and not the contract.
The EDN that is included in the Oracle SOA Suite supports these events and their queues, while all of the tools in the Oracle SOA Suite can publish and consume asynchronous events. Service consumers can leverage the Oracle continuous query language (CQL) to find the correct event for consumption in queue. The EDN can also consume events from and publish events to sources outside of SOA Suite, using JMS or AQ.
Service contracts can only contain essential information about the services, and requires the visibility of and access to service operations to be regulated. Two regulation strategies can be used, the first of which is to change the service contract. The second strategy is to register the service with a VETRO offering in order to define and regulate access to the service, without changing the service itself. The second approach has less impact on service dependencies and is more effective overall.
Only essential operations and parameters are defined and exposed in the service contract to service consumers in VETRO implementations, while enrichment, routing, and transformation functions are used to call services to simplify and abstract complex calls from service consumers.
The Service Abstraction principle dictates how the service documentation can be accessed by service consumers, which is enabled by the Oracle enterprise repository. This enterprise repository catalogs services and their information, which is provided only to authorized parties (Figure 14):
Figure 14 - A screenshot of Oracle's enterprise repository with a sample application is shown.
Extracting and encapsulating business rules that frequently change in new services help improve abstraction, since business rule implementation in services requires the internal rule structure to be known before the change-rule request can be sent to the TI area. Business rules that reside in the Oracle business rule component can be changed by the business rule owner over the Web, using natural language and Rete algorithmic fact tables.
Services are supplemented with communicative metadata that allows them to be effectively discovered and interpreted. The application of the Service Discoverability principle involves using a tool that queries all of the available services that can meet the business requirements of service consumers. For example, Account entity services can be found by service consumers in the OER (Figures 15 to 19):
Figure 15 - This screenshot depicts the search query for Account services in the OER.
Figure 16 - A screenshot of the various samples.
Figure 17 - The details on the service that is found in the OER are shown in this screenshot.
Figure 18 - This screenshot provides information on the service in the OER.
Figure 19 - A visual representation of service dependencies.
Queries in the OER can be executed from the Jdeveloper, VETRO tools, and Oracle BPEL. Another component that supports discoverability is the Oracle service registry, which implements a UDDI with all of its characteristics and benefits to promote manual or runtime queries of services so that consumers can use the right service.
The Service Reusability principle states that services contain and express agnostic logic, and can be positioned as reusable enterprise resources. Implementation of this principle requires the logic that performs the service tasks to be at a central access point and not directly accessible to other services, which can be achieved by applying the Logic Centralization design pattern.
The Oracle Jdeveloper is integrated with the Oracle service registry (UDDI implementation) for the discovery of services in design-time. Searching for services that have already been developed and deployed is enabled, and the OER can be used to make refined searches of services and their documentation.
Reusability is achieved when services from the OER in the Oracle service bus, mediator, or BPEL are consumed. Each of these tools allows the OER to be visually queried. The Oracle mediator, service bus, and BPEL increase reusability by exposing simpler contracts and using features to compose the services that were previously incompatible. Encapsulation of the business rules in separate services increases reusability, as does rule centralization by the Oracle business rules.
The Service Autonomy principle states that services are to exercise a high level of control over their underlying runtime execution environment. The autonomy of a service can be measured as the following (Table 3):
Table 3 - An overview summarizing the description and corresponding strategy to be implemented for service autonomies on different levels.
The Service Statelessness principle states that services are to minimize resource consumption by deferring the management of state information whenever necessary, which is most efficiently executed by the BPEL tool. This component encapsulates the business process or composition that needs to save the state of the data between service calls.
The BPEL component can execute both short and long-term service instances, including human tasks, to allow users to enter data into a service that is in a business process or service composition. Data entered by users are persisted by the BPEL in the workflow execution, meaning neither the human task tool nor the services needs to perform any persisting (Figure 20).
Figure 20 - The BPEL workflow logic is used to call the CCStatusService. The green human task labeled “ManualPOApproval” represents the user's decision to approve or reject the information after it visualizes the service results.
The results that are returned by the service to the BPEL component are automatically saved so that the service can resume execution. The BPEL engine provides the human task with the service results that were previously persisted, which the human task shows to the user in a GUI. The user is then required to approve or reject the credit to the client, after which both the CCStatusService and human task will process the data for the BPEL component to persist again when necessary.
The Oracle BPEL component can hydrate and dehydrate the data between service calls while saving all of the data in the internal repository.
Service composability is the ability of services to form compositions with one another that are independent of service size or complexity, in order to solve business requirements.
Three Oracle tools that can be used to create service compositions are as follows:
Oracle SOA Suite features and capabilities can be leveraged to directly apply and support each of the eight service-orientation principles, thereby perpetuating a sophisticated SOA environment that can optimize service reusability and integration. Additionally, the monitoring and reporting capabilities of the OEM and OSB can provide the information required to effectively evolve the service landscape and maintain alignment with business needs.
Special thanks to Peter Hughes of Estafet Limited for his valuable technical review and content contributions. Also, thanks to Juergen Kress and Bob Rubhart.
[REF-1] Getting Started With Oracle SOA Suite 11g R1: www.packtpub.com/getting-started-oracle-soa-suite-11g-r1-hands-tutorial/book
[REF-2] Prentice Hall Service Technology Series. SOA Principles of Service Design by Thomas Erl, www.servicetechbooks.com
[REF-3] Implementing the Enterprise Service Bus Pattern to Expose Database Backed Services: www.oracle.com/technetwork/articles/soa/jellema-esb-pattern-1385306.html
[REF-4] WS-BPEL 2.0 for SOA Composite Applications with Oracle SOA Suite 11g: www.packtpub.com/ws-bpel-2-0-for-soa-with-oracle-soa-suite-11g/book
[REF-5] Prentice Hall Service Technology Series. SOA Governance: Governing Shared Services On-Premise & in the Cloud by Stephen Bennett, Thomas Erl, Clive Gee, Robert Laird, Anne Thomas Manes, Robert Schneider, Leo Shuster, Andre Tost, Chris Venable , www.servicetechbooks.com