Journal of Convergence Information Technology Vol. 3 No 1, March 2008
Service-Oriented Architecture – A New Alternative to Traditional Integration Methods in B2B Applications A. M. Riad, Q. F. Hassan Head of Information Systems Department Mansoura University, Egypt Fax: 0502223754 Department of Information Systems, Faculty of Computers and Information Systems Mansoura University, Egypt
[email protected],
[email protected]
Abstract Nowadays, Business-to-Business (B2B) has become one the most important forms for e-commerce implementations that allows organizations (both partners and competitors) to cooperate in terms of building virtual corporations to satisfy customer and market needs. Almost all B2B applications have special requirements regarding to ability to be changed dynamically and flexibly due to market ever-changing needs. Traditional methods for implementing and integrating B2B applications have faced many problems that lead to failure in fulfilling these needs effectively. Serviceoriented architecture (SOA) is an emerging architecture methodology that comes with set of concepts, standards, and technologies that make it the endeavor for fulfilling these needs. This paper introduces a B2B case study to show how SOA allows integration between different systems not by rebuilding them from scratch, rather, by leveraging current assets in a way to make them more dynamic, and easy to be changed according to business needs and market circumstances.
Keywords SOA, Integration, Web Services, SOAD, Service Registry.
1. Introduction Nowadays, e-commerce has become one of the most important implementations of computer applications and systems, as it tends to enable manufacturing and trading companies varying from small to enterprise scale to accomplish most of business processes (like buying, making, selling, etc.) over the Internet [1]. The advent of e-commerce has forced manufacturers and
distributors to become more responsive to their customers. One way to achieve this goal is by integrating information systems residing at different business units. The used integration methods should promote dynamicity and flexibility in order to meet continuous changes in business needs and market circumstances to allow companies and enterprises to compete and stay in market. In fact, traditional integration methods that mainly depend on point-to-point interfaces have proved that they are not the best solutions for these needs because they always require high costs and long implementation time to build proprietary interfaces between different systems. The limitations of traditional point-to-point integration methods have forced software people to look for better ways that could bring IT and business in a closer alignment in order to catch business chances effectively. Service-orientation has emerged as a way for providing business functionalities as set of reachable and accessible services by modularizing different IT resources (like components, applications, and systems) used by trading partners to be easily accessed using different access forms, for example, accessing them through LANs, WANs, internet, or mobile devices. The remaining part of this paper is organized as the following. Section 2 provides an introduction to services and SOA. Section 3 presents a business scenario (case-study) for B2B systems that use traditional integration methods in order to show how SOA could alleviate common integration problems and difficulties. Section 4 presents the proposed architecture for illustrated business scenario with reasons for selecting SOA as a way for re-architecting this scenario. Section 5 outlines implementation concepts and mechanism for illustrated scenario. Section 6 gives a brief discussion about the service registry and its role in SOA. Finally, Section 7 concludes.
31
Service-Oriented Architecture – A New Alternative to Traditional Integration Methods in B2B Applications A. M. Riad, Q. F. Hassan
2. Service-Oriented Architecture (SOA) Technically, service could be considered as a set of software operations and components built in a way that allows them to be flexibly and dynamically integrated to cover both business and IT needs. Services are expected to receive requests from requestors, process them, and then return result sets back. Typically, different services can do different tasks in different complexity levels, starting from simple calculations (like calculating loan interests according to factors related to customer) to complex business processes (like processing complete loan cycle). Generally, services have various characteristics that differentiate them from other software terms listed briefly in the following: • Abstraction: One of services’ core features is abstraction that enables services to act as black boxes. This abstraction allows service requestor to simply send requests to be processed without knowing or caring about services’ internals including underlying programming languages, platforms, or even implementation mechanisms used to produce them. This feature comes from separating service implementation from service interfaces that allows service provider to change internal implementation logic from time to time according to continuous changes in business needs without affecting service requestor (as long as service interfaces have no changes) [2, 4]. In this way, the service requestor only sees the public interfaces that are responsible for mediating requests to internal implementation logic to process them, and finally return expected results. • Accessibility: Services should be accessible from anywhere to anyone (while authorized) to send his request to be processed and to get the returned results. • Transparency: This transparency might come in two forms: o Path Transparency: The service requestor has access to services through published URLs with no idea about their physical paths, thus, changing physical paths should not affect requestors at all. o Technology Transparency: The service requestor should have no idea about underlying components used to produce services, thus, services could be built over either modern or legacy components.
32
•
Loose Coupling: Changes occurred to one service should not affect either service consumers or any other services. This feature could play a great role in integration process between business partners as it decouples point-to-point integration between service consumers and service providers. • Granularity: Services should be built in a granular form to allow reusing of them over and over in different applications. Often services could be defined as fine-grained (small) that could handle simple tasks or coarsegrained (large) that could handle complex tasks. • Autonomy: Services should have full control over underlying logic, in other words, services should eliminate or at least minimize dependency on other services in order to ease deployment, governance, and maintenance tasks. • Standards-Based: Services should be built with widely accepted standards and technologies to allow them to be flexibly and efficiently deployed on different platforms, and to allow easier access for different consumers. According to IT specialists, SOA can be considered as an enterprise-wide architecture that utilizes services as building blocks for promoting reusability and interoperability between different systems (both homogenous and heterogeneous) in a flexible and dynamic manner [3].
2.1 Structure and Types of Services: As shown in figure 1, services cannot exist in a standalone form; rather, they are always built in a layered architecture over set of other computer resources including databases, object-oriented applications, legacy systems, packaged applications (like ERP, and CRM), software components, etc. These resources are responsible for providing entire functionalities, logic, and any needed processing for these services. Technically, services could come in one of the following flavors [5, 6]: • Simple Services: They directly expose functionalities provided by underlying system components. Technically, this type of services may be treated as adapters or wrappers built around legacy applications and components in order to allow IT specialists in enterprise to turn them into reusable assets. • Composite Services: They could be considered as micro-flows that are needed when there is no single service could satisfy complex requirements and the only way to provide
Journal of Convergence Information Technology Vol. 3 No 1, March 2008
this logic is by aggregating functionalities provided by simpler ones. For example, when a manufacturer issues a purchase order for some items from a supplier, services provided manufacturer, supplier, shipping company, and credit card agency are composed in a collaborative mode to satisfy this purchase order. Technically, composite services could be constructed using different implementation methods listed briefly as follows: o Programmatic Implementation: Using general purpose programming languages (like c#, java, etc) to hard-code the composition of different services together. Indeed, this method is not preferred at all because it is time consuming and cumbersome, as it forces IT team to revisit composition code for each change in composition logic. o Orchestration Engines: These engines always come with set of powerful capabilities such as transaction and context management, compensation support, asynchronous execution, etc. that are really needed for building and executing composite services. They also come with orchestration languages that are specialized in creating composite services through visual editors to ease development tasks. Many orchestration tools are available in market such as Microsoft BizTalk Server. • Business Processes: In fact, we could consider business processes as a special type of services which are responsible for representing business workflows (macro-flows). They reside in a separate layer in order to allow consumers to flexibly and dynamically define and change their workflows without effecting or allowing direct access to logic provided by underlying services. Business processes could be built by orchestrating and composing system services. Technically, changing business processes should not demand inherent changes in logic provided by underlying services; rather, this should be dynamically done by changing execution order of underlying services, thus, service consumer always could define and change business processes according to his needs without impacts on service provider side whereas needed functionalities is provided by services layer. Many standards do support business processes in software market such as Business Process Execution Language for Web Services (BPEL4WS) that enables building business processes in a flexible and portable form.
Figure 1. SOA layers
2.2 The basic Service-Oriented Architecture The basic SOA represents a relationship between three important constituents listed in the following [7]: • Service Consumer: It represents a service client who looks for specific service that could meet his business needs. This client may come in form of software component, application, or even another service that bind to (consume) service in order to use provided functionalities. • Service Provider: It is a network addressable entity that provides set of services that cover functionalities related to specific business domain. The service provider is the only one responsible for modifying implementation logic for published services in order to meet market needs, thus, it frees service consumers from implementation, deployment, maintenance, and governance headaches. • Service Registry: It is a special kind of databases that works as a repository for enabling service provider to publish its own services with optionally any required metadata and instructions that could enable service consumer to find and use them.
2.3 SOA Operations The aforementioned roles perform set of operations listed in the following: • Publish: Service provider publishes services attached with needed descriptions to enable consumers to find and use them.
33
Service-Oriented Architecture – A New Alternative to Traditional Integration Methods in B2B Applications A. M. Riad, Q. F. Hassan
• •
Find: Service consumer queries service registry for a service with specified criteria. Bind and Invoke: After locating the needed service, consumer can use it according to instructions and information provided by service description.
3. Problem Definition Assume that we have the depicted architecture in figure 2 for a supply chain management (SCM) system for a manufacturing company with two plants; Figure 3 depicts the business process at this company which dictates that when one plant runs out of a particular item, then its enterprise resource planning (ERP) systems starts to send a notification message to headquarter (HQ) system which in turn starts to query other plant ERP system. If the other plant does not have the requested item, then the HQ starts to issue purchase order (PO) to supplier’s ERP system. Assume that the mentioned systems are hosted on different operating systems and platforms, for example, figure 2 depicts that the first plant is hosted on a mainframe that is connected to windows-based server on HQ site, which in turn is connected to a machine hosted on IBM AS/400 at the other plant, and Sun Box at the supplier. To complicate our scenario, assume that our manufacturing company wants to expand to have one more plant, and assume that it wants to allow new suppliers to be integrated with them to provide needed materials in order to speed up the manufacturing process. To connect these different systems, point-to-point integration methods could connect them using many proprietary interfaces -- one proprietary interface between each two systems to work as a wrapper for different data formats being transmitted between those points. These proprietary interfaces represent a tightly coupled and inflexible way for integrating systems; therefore, this integration method suffers from high costs and effort, and long implementation time either in case of adding new plants, or suppliers, or in case of modifying existing ones according to changes in business processes, as this requires building or modifying interfaces between partners’ systems. These forms of tight coupling could prevent enterprise from restructuring the architecture either by adding new partners or by modifying current partners’ systems to fulfill new business requirements which in turn could prevent enterprise from hunting new business chances. Generally, e-Business should be dynamic and flexible to satisfy customer needs which in turn could allow gaining higher return of investment (ROI) and increased revenues.
34
Figure 2. Enterprise architecture
Figure 3. Business process
4. Proposed Architecture Proposed solution is aiming to allow integration and interoperation between different (homogeneous, heterogeneous) systems provided by participating partners and suppliers. To fulfill this need effectively we intend to convert traditional integration methods that mainly depend on point-to-point interfaces to service-oriented integration (SOI) methods by turning existing systems into services (also known as servicetization process). Simply, service-orientation means keeping existing software assets and investments to act as core systems, and building set of wrappers around them to provide entire functionalities in form of standardized services that promotes loose coupling between service providers and service consumers. Furthermore, service hubs will be used by manufacturer HQ in order to simplify services’ management and provisioning, and to allow
Journal of Convergence Information Technology Vol. 3 No 1, March 2008
integration with new suppliers easily. Typically, a hub could be considered as a central point through which distributed services could be monitored, managed, and secured [8, 9]. Figure 4 illustrates proposed solution that simply builds a new service layer above existing applications and systems at each participating node, and a central service hub to enable new participants to easily plug into the system.
In this step, we try to analyze and understand business domain in order to identify its functional areas, use cases, and business process. Table 1. Functional areas of demonstrated scenario Functional Area Name Manufacturer HQ
Plant
Supplier Shipping Companies
Banking Services
Figure 4. Proposed enterprise architecture
5. Approaching SOA As mentioned, SOA-based design intends to rely on current assets including legacy systems and components while building a service layer above them to expose their functionalities in a standardized form that allows easy integration and interoperation with partners’ and suppliers’ systems. In subsequent sections we will try to highlight some of methodologies that could help us to leverage current assets besides building some other new in order to allow easy and more effective integration between different systems apparent in our scenario.
Acts as both service provider and service requestor. Service provider for its plants that require items that below predefined threshold, and service requestor for other plants that have demanded items, or for suppliers who will supply its plants with needed row material. Acts as both service providers and service requestors. Service providers for other plants that have low inventory level for some items, and as service requestors for HQ in case that they are in need for items that below a threshold. Acts as service providers for HQ allowing it to issue purchase orders for some raw materials. They are third-party partners who act as service providers for both suppliers and manufacturer, enabling them to transmit both issued and returned items respectively. They are third-party partners who act as service provider for both suppliers and manufacturer, enabling them to transmit needed funds and fees from one account to another.
Table 2. Use cases yielded after domain decomposition phase Use Case Name UC1: Alert HQ
UC2: Query Plants UC3: Move Items
UC4: Find Suppliers
5.1 SOA Analysis and Design methods In order to turn our scenario to an SOA-base system, we should leverage Service-Oriented Analysis and Design (SOAD) methods to be able to determine functional areas that need to be transformed to services, size of them, and how they will interact with each other [10, 11].
Description
UC5: Sign Contract UC6: Order Items
Invoker
Implemente d by
When one plant runs out of some items, it sends notification messages to HQ to start querying other plants’ stocks. It is an internal use case that allows HQ to look for needed items at all other plants. When HQ finds needed items at one of its plants, it sends message to that plant to start transferring items to the requesting one. It is an internal use case that allows HQ to look for suppliers who could provide needed items from. This is an optional use case that may be executed between HQ and new suppliers.
Plant
HQ
HQ
Plant
HQ
Plant
HQ
HQ
HQ
Supplier
If HQ does not find the needed items at its plants, it starts to place orders at one or more of its row material suppliers.
HQ
Supplier
Description
5.1.1 Domain Decomposition
35
Service-Oriented Architecture – A New Alternative to Traditional Integration Methods in B2B Applications A. M. Riad, Q. F. Hassan
UC7: Prepare Items
UC8: Cancel Orders UC9: Reject Items UC10: Receive Items UC11: Transfer Funds
UC12: Transfer Items
UC13: Receive Returned Items UC14: Trace Items
It is an internal use case that is implemented and invoked by suppliers to allow them to prepare issued items by making, assembling, packaging, and finally delivering them to shipping company (third-party partner) which will be responsible for transmitting items to their destinations. Enables manufacturer HQ to cancel issued orders for specific items. Enables manufacturer HQ to reject items that may be damaged or do not conform to standards. Enables manufacturer HQ to notify supplier that needed items are received successfully.
Supplier
Enables manufacturer to pay needed fees to their suppliers by transferring money from its bank accounts to suppliers’ accounts. It is also will be responsible for allowing suppliers to pay for shipping companies that will transfer items to the manufacturer. Enables supplier to deliver items to shipping company that will be responsible for delivering issued items. It is also may be used by manufacturer to return rejected items. Enables shipping company to deliver rejected items to suppliers. Enables both manufacturer and suppliers to trace items moving between them via shipping companies.
HQ
Supplier
HQ
Supplier
HQ
Supplier
HQ/S upplier
Bank Services
Supplier/ HQ
Shipping Company
Shipping Company HQ/S upplier
Supplier
Figure 5. Use case model
36
Supplier
Table 3. Processes yielded after domain decomposition phase Process Nam e P1: Demand Items
Description
Included Use Cases
Allows plants to get needed items when they fall under certain threshold. This process should encapsulate the following logic: • When one plant runs out of some items, it notifies HQ to take appropriate actions. • HQ queries all other plants in order to get needed items (if available). • If needed items are found at one of queried plants, that plant transfers it to the target one. • If items are not found, HQ gets ready to issue purchase orders for them from one or more of available suppliers.
• UC1: Alert HQ. • UC2: Query Plants. • UC3: Move Items.
P2: Issue Purchase Orders
Allows HQ to buy needed items from raw material suppliers. This process should encapsulate the following logic: • HQ searches for suppliers who can provide plants with needed items from list of registered suppliers. • After locating suppliers, HQ makes orders for needed items. • Then HQ transfer needed funds to supplier via accepted banking services and forms. • After paying orders’ fees, the supplier ship items to HQ via shipping company which provide a facility to trace shipped items. • After arrival of issued items, HQ starts to check them, and if everything is ok it receives them and notifies supplier that items are received successfully. • If items have some problems, the HQ has the right to return them to supplier. • If items arrived too late, the HQ has the right to reject items and notify the supplier that the deal is failed.
• UC4: Find Suppliers. • UC6: Order Items. • UC11: Transfer Funds. • UC14: Trace Items. • UC10: Receive Items. • UC9: Reject Items.
P3: Supply Items
Allow suppliers to meet manufacturers’ orders. This process should encapsulate the following logic: • When a supplier gets a purchase order from a manufacturer it start preparation phase for issued items. • After preparing items, the supplier delivers them to shipping company in order to deliver them to manufacturer. • After delivering items to shipping company, the supplier transfer needed funds to it. • The shipping company gives its suppliers a facility to trace delivered items.
• UC7: Prepare Items. • UC12: Transfer Items. • UC11: Transfer Funds. • UC14: Trace Items.
Shipping Company
Journal of Convergence Information Technology Vol. 3 No 1, March 2008
P4: Return Items
Allows manufacturer to return issued items to suppliers. This process should encapsulate the following logic: • If the issued items have some problems, the manufacturer HQ rejects receiving them from shipping company and notifies supplier about that rejection in order to take appropriate actions. • The rejection action forces the shipping company to return back those items to supplier again. • After transferring rejected items, the supplier receives them.
• UC9: Reject Items. • UC12: Transfer Items. • UC13: Receive Returned Items.
Figure 6 illustrates the relationships between different processes included in our scenario, and how they could be implemented using use cases yielded during domain decomposition phase.
Figure 6. Relationships between processes and use cases
After completing subsystem analysis, we end up with set of large-grained components to be implemented as services. Table 4 illustrates subsystems included in demonstrated scenario attached with set of public functions provided by each one. Table 4. Subsystems included in demonstrated scenario Service Name
Description
Exposed Functions
S1: Plant
Handles plants’ transactions such as allowing them to look for needed items, moving some items from one plant to another, and receiving issued items.
S2: Manufacturer
It is a key service that manages most of tasks at manufacturer side such as looking for needed items at available plants, looking for available suppliers who could provide needed items, registering new suppliers, and deleting some suppliers.
S3: Supplier
It is a key service that manages almost all important tasks at supplier side such as viewing available products to their
• Look_For_Items: Allows manufacturer HQ and other plants to query plants for specified items with set of predefined conditions. • View_Items: Provides list of all available items. • Search_Results_Callback: Receives detailed notifications from HQ with query results. • Receive_Items: Updates plants stock levels after receiving new items either from other plants or from suppliers. • Move_Items: Allows manufacturer HQ to transfer needed items from one plant to another which in turn updates related information about their stock levels. • Summerize_Plants_Information: Allows manufacturer to generate different reports about plants’ status including available items, transactions occurred on them within quarter, etc. • Notify_HQ_Callback: Receives alert notifications from any plant when it runs out of specified item in order to allow it to take appropriate actions. • Find_Suppliers: Allows manufacturer to select one or more of available suppliers in order to get needed raw materials. • Register_Suppliers: Allows new suppliers to join manufacturer in order to provide him with needed row materials. • Update_Suppliers_Profile: Allows existing suppliers to update their profiles, for example, business activities, addresses, fax numbers, phone numbers, etc. • Deactivate_Suppliers: Internal method that allows manufacturer to deactivate some suppliers in order to stop dealing with them. • Sign_Contract: Allow suppliers to sign contracts with new manufacturers, shipping companies, and other suppliers. • View_Products: Lists available items and raw materials to enable manufacturers to easily find, and order needed ones.
5.1.2 Subsystem Analysis Technically, this phase is responsible for doing two main things, first, turning defined use cases into services in order to publish them, second, identifying subsystems and components which will be responsible for realizing defined services. To accomplish this phase effectively we should know the participants (actors) representing available subsystems, and the interrelationships between them in order to identify functionalities provided by each one without missing or duplicating any of them. In our scenario the three main subsystems identified are Plants, Manufacturer HQ, and Suppliers, beside two more optional (third-party), Banking Services, and Shipping companies. Each of these subsystems must implement and realize business (functional) use cases that have been identified during domain decomposition phase, plus technical (non-functional) services such as security, performance, audit-trail, etc.
37
Service-Oriented Architecture – A New Alternative to Traditional Integration Methods in B2B Applications A. M. Riad, Q. F. Hassan
customers (manufacturers), accepting new purchase orders, preparing issued items, and receiving returned items.
S4: Shipment
S5: Banking
Provides needed functionalities related to shipment services such as transferring items from one location to another, and allowing their customers to trace items being shipped. Covers payment services that allow customers to pay needed fees for their service providers.
• Accept_POs: Accepts manufacturers issued POs to start its preparation phase. • Prepare_Items: Allow suppliers to enter preparation phase for issued items which includes making items, packaging them, contacting shipping company that will be responsible for transmitting them, etc. This function should be automatically called after accepting POs from manufacturer. • Notify_Suppliers_Callback: Receives notification from a manufacturer that a PO has been processed successfully or not. • Cancel_POs: Allows manufacturers to cancel issued purchase orders. • Return_Items: Allows manufacturers to return issued items. • Transfer_Items: Accepts orders to transfer items from one location to another. It could allow suppliers to move issued items to manufacturer or another supplier, or it could allow manufacturer to return issued items to source supplier(s). • Trace_Items: Enables suppliers and manufacturers to trace items being transmitted between them.
vided by underlying services, components, and systems (legacy, and packaged solutions in our scenario).
• Debit_Account: Allows banks clients (suppliers, and shipping companies) to debit some money from specified accounts. • Credit_Account: Allows banks clients (manufacturer) to credit some money to specified accounts.
Also, they could improve reusability level as they may be used to compose more complicated composite services, for example, if the manufacturer wants to create a new service that could handle the whole process for providing needed items for one plant either by moving items from other plants or by issuing purchase orders from available suppliers, a new composite service could be composed using Demand Items, and Issue PO services.
After designing and building the services mentioned above, they could act as infrastructure (elementary) services that could be easily used by IT specialists to implement business processes identified during domain decomposition phase. IT specialists can build a composite services layer above those services in order to provide needed logic in a loosely-coupled manner. Composite services could be physically constructed using standards like BPEL4WS or using different orchestration tools available in the market. Figure 7 illustrates set of composite services dynamically composed to satisfy business process needs. These composite services intends to improve dynamicity and flexibility on processes level as they enable IT specialists to change their logic easily by changing their orchestration (composition structure and execution order) without the need to modify logic pro-
Figure 7. Composite services needed for yielded business processes
5.1.3 Service Categorization This process starts after knowing and specifying services to be used, and it aims to categorize generated services according to different criteria, for example, type of customers (internal service, customer service, or partner service), provided functionalities (function service, validation service, or process service), type (technical service, or business service), and size (finegrained service, or coarse-grained service), thus, it helps to assign different services to different layers appropriately. 5.1.4 Service Specification Each service should contain a formal interface contract defining the necessary pre-conditions, post-
38
Journal of Convergence Information Technology Vol. 3 No 1, March 2008
conditions, invocation syntax, semantics, and quality of service (QoS) terms in order to allow consumers to use it effectively. 5.1.5 Service Realization This step specifies technologies and tools to be used to realize given services. It also determines the realization strategies for those services; realization strategies may include building services in-house, outsourcing, leasing, or buying them.
5.2 Services Technology There are many tools and technologies could be leveraged to construct services in SOA including message queuing technologies such as Microsoft Message Queues (MSMQ), Java Message System (JMS); technologies that allow access to distributed objects such as Remote Method Invocation (RMI), Remote Procedure Call (RPC); Common Object Request Broker Architecture (CORBA); and Web Services. Identified services in our scenario will be created using web service technology which represents a standard form for interoperating different systems. Typically, web services can be considered as the major implementation technology for most of contemporary service-oriented applications. What makes web services the best choice for implementing SOA is the great support it has gained from different software vendors since it has emerged in software market, this support is because web services technology relies on set of standards [12] including extensible markup language (XML) which is responsible for structuring data passed between participating nodes [13], simple object access protocol (SOAP) which acts as the messaging framework for transferring data requests and responses between service consumers and providers [14], and web service description language (WSDL) which is responsible for providing needed description and metadata about exposed services to allow service consumers to easily bound to them [15]. Figure 8 illustrates requests from service consumers and responses from service providers. Service providers will be responsible for serializing data provided by their core systems to be able to transmit them over network, and on other side, the service consumers should be able to de-serialize them in expected formats for their systems.
Figure 8. Dataflow between Web Service Provider and Consumer
5.3 Development Framework In fact, there are many development frameworks that provide great support for SOA. .NET (pronounced as dot net) is a Microsoft framework that was presented in year 2000 specially to sustain SOA implementations. It has come with set of programming languages including C#, Visual C++, Visual Basic [16] which could be used to build and deploy objects, wrapper components and web services needed for integrating different systems in our scenario [17]. Moreover, .NET has released two new versions (2.0 and 3.0) that include set of new technologies and tools that can effectively implement our scenario including web services enhancements (WSE) [18] that cover second generation of web services known as WS-* standards [19]; windows communication foundation (WCF) [20] that allows integrating different SOA-enabled systems that have been built with different Microsoft technologies such as COM+, .NET Remoting, and web services; and windows workflow foundation (WWF) that enables easy way for constructing business processes and workflows depending on created services [21].
6. Service Registry Simply, service registry is used to register services in order to allow existing and new business partners to discover and use them. Service registration process is responsible for extracting and storing all metadata information attached with each new service including technical information that gives consumers needed guidelines in order to consume them; quality of service (QoS) terms such as when they are available, down times, and estimated response time for each request; and general information about business domain such as business type.
39
Service-Oriented Architecture – A New Alternative to Traditional Integration Methods in B2B Applications A. M. Riad, Q. F. Hassan
Service registry can play a great role in our scenario; for example, assume that our manufacturer intends to deal with more suppliers to get needed materials quickly in order to speed up production cycle to meet urgent customer needs. To do so, the IT team at manufacturer side can publish the services responsible for monitoring and managing their warehouses in a way that allows new suppliers to detect items that fall under certain threshold to cover them. Furthermore, service registry enables SOA to scale rapidly, for example, assume that the manufacturer wants to institute an electronic competitive bidding system for its orders. The suppliers who want to bid to win business from the manufacturer can simply search for offered services, extract attached metadata, and connect to the bidding system. UDDI is a good example for service registry which provides great search tools that enable easy discovery for services, for example, someone can find all services provided by a given business entity. Information documents provided by UDDI can be retrieved either manually using URLs or programmatically using APIs that provided by UDDI registries [22].
7. System Efficiency Proposed solution for integrating different partner systems provides many advantages over traditional methods including: • Reusability: Services constructed during implementation phases could be used over and over for different purposes and in different projects, for example, services provided by suppliers could be used by different manufacturers who may want them to provide needed row material items. Figure 9 illustrates more examples for reuse of constructed services. • Efficient Development: Reusability of constructed services allows easier and faster development for new business requirements including orders for new items or change requests which in turn could save development time and cost. • Avoiding Redundant Functionalities: Building services and storing them into service registry with good documentation allows IT specialists to make sure that they do not have really the required functionality before starting its development. • Centralized Monitoring: Connecting different services to a centralized services hub enables easier traceability for services usage and better monitoring for their key performance indicators (KPIs).
40
•
•
•
Easy to Build Business Process: Constructed Services could act as building blocks for enterprise business processes and workflows, for example, services could allow business analysts and domain experts to build business processes easily by orchestrating different services together, or modifying existing processes by changing execution order/structure of used services. Better Project Management: SOA solution could allow project managers to divide development team to sub teams each of which is responsible for building, supporting, and maintaining one or more of designed services. This facility could enable better resources’ utilization by allowing development of different services to be done in parallel. Better Alignment for Business Requirements: It is easier for business experts to define their requirements in terms of services which in turn could be easily mapped to existing functionalities (services) to know if they already exist or not. For example, one manufacturer may ask his supplier for a facility that allows him to trace ordered items; the supplier could simply reply that his shipping partner has a public service that allows customers to monitor items’ movements.
Figure 9. Reusability for constructed services
8. Conclusion This paper has introduced main concepts and methodologies related to SOA to prove that it is a good way for integrating different systems both homogeneous
Journal of Convergence Information Technology Vol. 3 No 1, March 2008
and heterogeneous, and how it could enable enterprises to increase productivity of IT specialists in order to meet market and business ever-changing needs. This productivity comes mainly from the ability to ruse existing assets, and from avoiding proprietary point-topoint interfaces between different systems that always being used by traditional integration methods, thus, enabling companies and enterprises to catch business chances quickly and effectively. Shortly, SOA could be considered as the endeavor for implementing and integrating almost all B2B applications that require continuous changes and modifications in order to allow enterprises to face fierce competition in market which in turn allows them to stay in market and to gain higher ROI
9. References [1] Turban, E., King, D., Lee, J., Warkentin, M., & Chung, H.M. (2002). Electronic Commerce 2002: A Mana-gerial Perspective. Prentice Hall, 2002.
[11] Zimmermann, P. Krogdahl, C. Gee. Elements of Service-Oriented Analysis and Design: An interdisciplinary modeling approach for SOA projects. http://www128.ibm.com/developerworks/webservices/library/ws-soad1/. June, 2004. [12] Web Services Architecture. World Wide Web Consortium (W3C), http://www.w3.org/TR/ws-arch, 2004. [13] Extensible Markup Language (XML) Specification Version 1.0. World Wide Web Consortium (W3C), http://www.w3.org/tr/rec-xml/, 2004. [14] Simple Object Access Protocol (SOAP) Specification Version 1.2. World Wide Web Consortium (W3C), http://www.w3.org/tr/soap/, 2003. [15] Web Services Description Language (WSDL) version 2.0 Part1, 2: Core Language. World Wide Web Consortium (W3C), http://www.w3.org/TR/wsdl20 , 2006. [16] J.Liberty, “Programming C#”, O’REILLY, 2005.
[2] “ABCs of SOA”, CIO Magazine, http://www.cio.com/article/40941 , 2007.
[17] P.Shodjai, “Web Services and the Microsoft Plat-form”, Microsoft Developers Network (MSDN), 2006, http://msdn2.microsoft.com/en-us/library/aa480728.aspx.
[3] N. Bieberstein, S. Bose, M. Fiammante, K. Jones, R. Shah, Service-Oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap, IBM Press, Chapter 1, 2005.
[18] Web Service Extensions Overview, MSDN, http://msdn2.microsoft.com/enus/webservices/aa740663.aspx.
[4] Learn about Service Oriented Architecture (SOA), December 1, 2006, www.microsoft.com/biztalk/solutions/soa/overview.mspx. [5] Arsanjani, “How to Identify, Specify, and Realize Services for your SOA (Part 1, 2)”, ebizQ journal, http://www.ebizq.net, 2005. [6] D.Krafzig, K.Banke, D.Slama, “Enterprise SOA: ServiceOriented Architecture Best Practices”, Prentice Hall, 2004, Chapter 4. [7] M. P. Papazoglou, “Service-Oriented Computing: Concepts, Characteristics, and Directions”, Proceedings of the fourth IEEE international conference on web information systems engineering (WISE’03), 2003.
[19] WS-* Specifications. http://www.ws-standards.com/. [20] “What Is Windows Communication Foundation?”, MSDN, http://msdn2.microsoft.com/enus/webservices/aa740663.aspx [21] D. Chappell, “Introducing Microsoft Windows Workflow Foundation: An Early Look”, http://msdn2.microsoft.com/en-us/library/aa480215.aspx, MSDN, 2005. [22] Universal Description, Discovery and Integration Specification Version 3.0.2. OASIS UDDI Technical Committee. http://uddi.org/pubs/uddi_v3.htm, 2004.
[8] E. Pulier, H. Taylor, “SOA for B2B commerce: Implement more flexible and dynamic IT connections”, http://www.javaworld.com/javaworld/jw-11-2005, 2005. [9] E. Pulier, H.Taylor,“Understanding Enterprise SOA”, Manning Publications, 2005, Chapter 6. [10] M. Endrei, J. Ang, A. Arsanjani, S. Chua, P. Comte, P. Krogdahl, M. Luo, T. Newling,. Service-Oriented Architecture and Web Services, IBM Redbooks. pp. 83-102. April 2004.
41
