Software-Oriented Architecture - Term Paper Example

Project Number SOA ANALYSIS SOA is an architectural model that focuses on enhancing efficiency, agility and productivity in an enterprise. This is achieved by prioritizing services as the primary means of representing solution logic to aid in the realization of strategic goals regarding service-oriented computing. SOA implementation in the form of technology architecture entails a combination of technologies, products, APIs support infrastructure extensions among others. Each enterprise desire a unique SOA characterized by the introduction of new technologies and platforms that allow the creation, deployment and evolution of service oriented solutions (Dirk Krafzig, 2005). Therefore a technical architecture is sought that is capable of hosting a service-oriented automation logic. BPM is a divided discipline with many different styles, notations and assets. An example is the UML which extends from the application level to the BPM level. All existing BPM approaches can be utilized as a starting point for Subject- Oriented Architecture and Design. SERVICE MODELING The primary goal of a service-oriented analysis is to determine the necessary parameters for subsequent design and building of a project. In this process abstract candidates are only modeled to be considered in the final design process (Erl, 2006). The process is important in that the relevant candidates considered are subjected to the technical architecture for the design and are expected to be sustained. This stage thus involves the creation of service candidates and the proposition of operation candidates. The service modeling process describes some 12 steps comprising of applications, business, and orchestration service layers. Blockbooster automation systems comprise of the following applications; A customer management system stores the customer profile and related information. It consist of database with a Web-based data entry and user reporting interface. They are contact-centric database that offers tracking approach to all the information and activities linked to customers. It allows several people in the company to share information in the database. It has an advantage of tracking sales and a centralized repository of contact information. The second automation system is a two-tier client-server system that controls the accounting and inventory transactions. Information is fed into incoming and outgoing standard transaction documents. A receipt of a purchase order initiates the invoicing and start of a delivery process of the selected movies from the Blockbooster website. The proposed business process is broken into smaller process steps. Our case study concerns an alliance between Blockbooster and Reddish Box $1 to salvage the Blockbooster from an imminent collapse. Due to stiff competition from a major competitor (NetFlicks) the alliance implemented by an SOA Web service will enable customers to order movies unavailable at Reddish Box from the Blockbooster website and get them delivered to their doorstep. Reddish Box had lost some of its customers to NetFlick due to home delivery service and in order to regain them they merged with Blockbooster to provide the service. Blockbooster is anticipating an SOA web service that would facilitate multiple clients (Sweeney, 2010). The two main business services are; Order Fulfillment Invoice Submission There is a need for Blockbooster to develop a service-oriented analysis that divide its business process logic into series of service candidates. Thus the following potential services and layers are adopted; (Hurwitz, 2009) A business service layer with two tasks-centric business service A task-centric service layer with four application services Blockbooster is on the verge of collapsing and thus do not have the resources to invest in middleware that can provide orchestration. The orchestration service layer is therefore not necessary for this process. The fundamental entities of relevance include; Invoice Purchase order Other additional entities encountered in the process are; Customer Order The first process involves the decomposition of the Order fulfillment Process. Receive movie Order document Validate Order document if movie available If movie unavailable Order document is invalid, terminate Transform Order XML document into an Electronic Order format Import Electronic Order into accounting system Send Order to the accounting officer to work on it. Confirm delivery details Deliver The Invoice Submission Process can be decomposed as follows. Draft electronic invoice Issue electronic invoice Export electronic mail to network folder Poll network folder Retrieve electronic invoice. Transform electronic invoice to the XML document Validate invoice if not terminate the process. Verify Reddish Box metadata check. If it fails to end process. A review is done to filter the processes that do not form part of our service-oriented solution. The remaining processes are supported by a comment to explain the motive of retaining them (Dirk Krafzig, 2005). Invoice Submission Process Draft electronic invoice. ( Accounting officer performs it manually) Issue electronic invoice. (Accounting officer performs it , manually) Export electronic invoice to network folder Poll network folder Retrieve electronic invoice Transform electronic invoice to XML Validate electronic invoice if not terminate The following are the modified decomposed Order Fulfillment Process; Receive movie Order document (No need to change it since its performed by the existing department.) If movie unavailable Order document is invalid, terminate. Otherwise Transform Order XML document into an Electronic Order format (service candidate) Import Electronic Order into accounting system (generic service candidate) Send Order to the accounting officer to work on it. Confirm delivery details Deliver ( done manually by courier services) It is realized that even though the process review has eliminated some steps, the grouping is not in a logical context. An entity-centric business model equivalent to the one we are building should be grouped in such a way to show the relation with previous entities. The grouping can be decomposed as follows; Invoicing service Export electronic invoice to network Retrieve electronic invoice Poll network folder Transform electronic invoice to XML Validate electronic invoice if not terminate Vendor Profile Service Confirm delivery details Delivery Purchase Order service Receive movie Order document Validate Order document if movie available Transform Order XML document into an Electronic Order format Import Electronic Order into accounting system Legacy system services Import Electronic Order into accounting system Export electronic mail to network folder Send Order to the accounting officer to work on it. Service candidates The service orientation principles are refined and added in this stage. Service orientation entails the logic that guides an organization to cope with the internal and the external environmental changes. In defining logic we classify it into two; application and business (Erl, 2006). Business logic comprises the necessities that result from an organizations business area while application logic refers to the implementation techniques of the business logic organized into various technological solutions. The use of web services serves to attain reusability and autonomy (Dirk Krafzig, 2005). It is evident that the “sent orders to accounting officer” is only possible after importing an electronic invoice thus it would be prudent to combine the two operations into one. Furthermore, “we can combine the “retrieve electronic invoice”, “transform electronic invoice into XML documents” and “validate” into one parameter. There is a common relationship between the “transform order XML document” and the “retrieve and transform invoice document “. These operations involve accounting practices and thus there is be a need to create a new candidate that caters for this (Dirk Krafzig, 2005). The invoicing process can be refined into an operation candidate that gives updates for different kinds of movies at the Box. Incidentally it can be made a service candidate to notify customers of new release and restocking. The purchase order services can be manipulated to come up with only one operation. “Validate movie order if available” since “receive order” is a natural service. The revised metadata services have come up with an additional clause to issue notification upon its check. The results of service orientation can be summarized as follows; Legacy System Polling Notification Invoice processing Transform a/c Documents Purchase order processing Metadata check Import and sent to a/c officer Poll available movies - Transform to XML Validate movie order if available Check metadata Notify available orders Transform from XML Issue notification or terminate The table above represents generic, reusable, and business-agnostic group of service candidates logic. The PO processing and Invoice Processing represent the business service layer and comprise of all the process logic necessary to make up the application service candidates. Revised business service grouping Invoice Processing service PPO processing service A series of re-analysis steps follow where complex business processes are studied to abstract further technology-centric service candidates. In the case of Blackboost, no more than one application is required to complete the service action. The application service candidates can be grouped according to a certain criteria favored by the organization. The relationship can be based on a number of factors; (Sweeney, 2010) The relation between components Association with a specific legacy A comparison is made between the original scenario and the new application service. The resulting mapping defines the success of the service candidates and determine whether new service operation candidates can be added or not. We have been able to create two new distinct service layers for Blockbooster each layer having its own well defined service candidates. Blockbooster desired a business environment that can provide customers a list of movies available on the Reddish Boxes on their location and order at their website if they are unable to get what they are looking for. SERVICE DESIGN SOA has the following components XML architecture Web services Hosting platform In order to compose an SOA the first consideration is a design configuration for the various service layers. This is achieved by analyzing the candidate service layers discussed in the previous section and should be implemented to leverage the requirements and the solution. Lastly the contemporary SOA extensions should be determined to access the available WS characteristics that form our service-oriented environment. SERVICE DESIGN PROCESS DIAGRAM The aim of a service design is to come up with a web service that encapsulate some logic and adhere to the service-orientation principles. In doing so it meets the requirements of the our business. Blockbooster aims at serving customers who do not find their preferred movies at Reddish Box by incorporating up to date systems that relay real time information on their Smartphones. In the case of Blockbooster the following web services can be derived; Invoice processing service PO processing service Polling service Transform accounting service Legacy system services Customer profile service Royalty and Tax service A web service architecture incorporates the XML language. An XML document can be hierarchically defined by an XSD schema created. XML Schema is the most widely agreed standard for describing web service messages. (Hurwitz, 2009) Blockbooster is going to design a task-centric business service to control the invoicing process in the accounting system. Thus the Invoice Processing Service is invoked. Since it contains no operation it is termed as a controller service. For a single invoice, there are three service operations involve which include, legacy system, polling service, and transform service. The steps followed for an invoice issue involve the transform mechanism between the Invoice Processing Service and the Transform service. A message error indicates a terminated process due to a technicality on the part of the customer or the system due to an invalid entry. An initial service interface can be built following these steps; Generate a set of operations using the application service operation. The input and output values for processing each operation are documented and the assigned the types containing the XSD schema. A WSDL containing portType area is created with an operation construct followed by message constructs The process proceeds as follows; The Blockbooster Invoice Processsing Receives notification sent from Polling Service. The transform Service converts the invoice document into XML form. The Invoice Processing forwards the invoice document to the customer who is prompted of a delivery status and requested to confirm the mailing address. These actions are referred as the service business logic. (Erl, 2006) The Polling Notification service initiates the invoice submission service to be effected thus Invoice Submission Service qualifies to be a service provider. A different naming criteria have been adopted to suit the service interface design needed to interact with the Polling Notification service. This specifies the location path of the invoice document. The Polling Notification Service only invokes the Invoicing service but do not physically retrieve and forward the documents. A preliminary types is created with complexType to give the following; The operation and the associated message are generated inside the portType and the resultant Outcome is as follows; < input message="tns:receiveSubmitInvoiceMessage" /> The schema is replicated in the types construct to eliminate the risk of creating redundant markups.An original extension of the complexType is included to represent the root element of the invoice document given by invoice.xsd file. A process that standardizes and refine the service interface is adopted by incorporating design standards and guideline. An SOA characteristic that support service interface design is taken in addition to a WS-I profile standards. An adjustment to the schema arrangement in the types construct (Dirk Krafzig, 2005). The transform service is responsible for the validation and transformation tasks in the original logic. We need to make the service optional and define a new conditional logic that encapsulate the Invoice Processing Service. Thus a final version of Invoice Processing Service is given below (Dirk Krafzig, 2005). Initiates the Invoice Submission Process. Requires either the invoice document location or the document. ... APPLICATION SERVICE DESIGN An application service is defined as a public interface that provide accessibility to a function.It is possible through a programmable interface called upon by the service consumer.Application services are distributable and message-oriented and thus can be described by Web Service Description Language (WSDL) while its operations are initiated using XML message schemas. Interoperability is aimed at when designing services to enable components understand message and interface definition. Process description A proposed service design for application interface is made up of six steps as shown in the following flow chart. There is similarity between the entity-centric business service process and the application service process due to the fact that both of them utilize the reusable service logic thus depend on the main controllers to compose them into business process tasks. However there are notable differences between the two of them. The process requirement stage is not defined because the application processes the business logic of the parent enterprise. Considering the Transform accounting document of the Blockbooster enterprise, a document in the transformed form of native to XML format and vice versa defines the two operation candidates. A review of the existing services is carried out to determine some applications that might be similar to the designed services in the organization. Blockbooster anticipates to design Web services that provide maximum reusability in the business. The only available application possessed by Blockbooster The second stage involves the re-evaluation of operation candidates to compare with existing application designs. This process distinguishes the applications that belong to other services. The transform Accounting services is valid for the case of Blockbooster. An initial service interface can be derived by considering the following; Application service candidates should produce generic and reusable operation candidates. The input and output values for each operation candidate should be documented and message structures defined using XSD schema. The portType area and the message constructs are added to the appropriate schema types. Blockbooster has two applications that transform a document to two formats.It uses WSDL 1 specification to design service interface. Example of transforming operations is; ; Principle of service orientation. Reusability and service autonomy are the main principles applied.Reuse potential is applied to TransformtoNative and TransformToXML.The two operations can be changed in future thus no need to alter them .Additional metadata can only be outfitted. < documentation > Retrieves an XML document and converts it into the native accounting document format. < documentation > Retrieves a native accounting document and converts it into an XML document. Standardizing and refining the service interface is achieved through applying existing standard relevant to service interface and the contemporary SOA characteristics.Also the WS-1 practices can be applied. Due to the fact that Blockbooster wants to expand its services in the future it considers reviewing and adjusting their service names. Finally Blockbooster has succeeded in building a reusable and generic application service.Transform Service can be utilized in the invoice submission and order fulfillment processes. It can thus be concluded that the primary design task of a business service has been successfully implemented. The essay had dealt with the need to have an innovative, meet-in-the-middle approach that bridges the IT and business gap in the analysis and design of an SOA. References Dirk Krafzig, K. B. (2005). Enterprise Soa: Service-oriented architecture best practices. Dirk Krafzig, Karl Banke, Dirk Slama. Erl, T. (2006). Service-oriented architecture: Concepts, technology, and desing. Pearson Education. Hurwitz, R. B. (2009). Service oriented architecture (SOA). John Wiley & Sons. Sweeney, R. (2010). Achieving service-oriented architecture: Applying an enterprise architecture approach. John Wiley & Sons. Read More