The traditional supply chain often includes more than one company in a series of supplier-customer relationships. It is often defined as the series of links and shared processes that involve all activities from the acquisition of raw materials to the delivery of finished goods to the end consumer. Raw materials enter into a manufacturing organization via a supply system and are transformed into finished goods. The finished goods are then supplied to customers through a distribution system. Generally several companies are linked together in this process, each adding value to the product as it moves through the supply chain.
Effective supply chain management is the act of optimizing all activities throughout the supply chain, and it is the key to a competitive business advantage. Consequently, an organization’s ability to gain a competitive advantage is heavily dependent on coordination and collaboration with its supply chain partners. Yet, even today, a typical supply chain is too often a sequence of disconnected activities, both within and outside of the organization. To remedy this situation, it is important that an organization and its suppliers, manufacturers, customers, and other third-party providers engage in joint strategic planning and operational execution with an eye to minimizing cost and maximizing value across the entire supply chain.
Advances in information system technology have had a huge impact on the evolution of supply chain management. As a result of such technological advances, supply chain partners can now work in tight coordination to optimize the chain-wide performance, and the realized return may be shared among the partners. The underlying enabler of supply chain integration is the fast and timely exchange of information between supply chain partners. This information may take the form of transactional documents such as purchase orders, ship notices, and invoices, as well as planning-related documents like demand forecasts, production plans and inventory reports. It is this sharing and coordination of information and planning activities that can enable cost reduction, value enhancement, and the execution of advanced collaborative planning activities.
In the past, the cost and complexity of executing electronic data interchange (EDI) transactions made this type of information exchange suitable for only the largest corporations. The ubiquity of Internet-based communication tools now makes it possible for organizations of all sizes to exchange information. However, challenges still exist and being able to successfully deal with all the new technologies is one of these challenges. The good news is that this data exchange challenge can be overcome; and the opportunities become endless once companies are able to exchange information efficiently with their suppliers, customers, and partners.
Vendor Managed Inventory (VMI) is a supply chain practice where the inventory is monitored, planned and managed by the vendor on behalf of the consuming organization, based on the expected demand and on previously agreed minimum and maximum inventory levels. Traditionally, success in supply chain management derives from understanding and managing the tradeoff between inventory cost and the service level. Types of information that can be shared between supply chain partners in a VMI partnership include inventory levels and position, sales data and forecasts, order status, production and delivery schedules and capacity, and performance metrics. Sharing information yields many benefits to supply chain members.
A service-oriented architecture (SOA) is a style of design that guides all aspects of creating and using business services throughout their lifecycle (from conception to retirement), as well as defining and provisioning the IT infrastructure that allows different applications to exchange data and participate in business processes regardless of the operating systems or programming languages underlying those applications. An important goal of an SOA is to help align IT capabilities with business goals. Another goal of an SOA is to provide an agile technical infrastructure that can be quickly and easily reconfigured as business requirements change. The key organizing concept of an SOA is a service. The processes, principles, and methods defined by the SOA are oriented toward services (sometimes called service-oriented development). The development tools selected by an SOA are oriented toward creating and deploying services.
For designing SOA UML is used, for the simulation of buyer and supplier scenario web services are used and for implementing business logic in multiple suppliers and multiple retailers case BPEL (Business Process Execution Language) is used. For performance testing of web services WAPT 3.0 (Web Application Load, Stress and Performance Testing) is used, WAPT can simulate multiple clients to invoke web services and test the performance of web services.
Composite Web Services
A composite Web Service (WS) provides higher-level functionality by utilizing one or more (composite or non-composite) individual WS that it invokes in a well-defined order. In general, each WS defines its own schema of its input as well as its output messages based on the data model of its underlying implementation. In consequence, a composite WS must be able to interpret every message definition schema of every WS it invokes and has to transform those into either its own messages or the messages of other WS it subsequently invokes to enable frictionless data flow between them. Since the message definitions of each WS follow in general a different data model based on a specific underlying ontology or data model, messages require transformation in order for the composite WS to be semantically meaningful.
A laboratory Scale Implementation
Following figure shows the complete structure of database tables required by the both the sides. For simulating customers at retailer side we decrease the StockLevel of table R1 in a random manner, this information is made available to the supplier through a web service, supplier access the information by using a client. Supplier updates the table S1 at a regular interval and when StockLevel becomes less than or equal to the ReorderLevel (shown in table S4), supplier sends the consignment stock to the retailer and updates the information in his consignment stock table S2. When retailer obtains this information he stores it in his consignment stock table R2 and when StockLevel in table R1 becomes zero retailer starts using the new consignment stock and changes the status in R2 table from unused to using. This status is made available to the supplier through a web service. Supplier updates the status in the S2 table. Every time when status changes from unused to using, he generates an invoice which is received by the retailer and stored in invoice table R3. On the payment by retailer an acknowledgement is received by the supplier.
Towards implementation of multiple retailer and multiple vendor case:
New architecture for multiple retailers and multiple suppliers’ case is given below. Which consists of three new components as comparing to the previous architecture adopted in case of single supplier and single retailer.
BPEL: This is used for implementing business logic for web services.
UDDI: It is used for web registry.
WS-Security: To secure web services.
Choreography and orchestration are used for combining web services and sequential execution of the web services. In orchestration, which is usually used in private business processes, a central process takes control of the involved Web services and coordinates the execution of different operations on the web services involved in the operation.
BPEL (Business Process Execution Language)
BPEL builds on the foundation of XML and Web services; it uses an XML-based language that supports the Web services technology stack, including SOAP, WSDL and UDDI. BPEL is mainly used for orchestrations and choreography among web services. For creating a composite web service we need a BPEL Engine. A BPEL Engine handles web services by three methods <receive>, <reply>, and <invoke>.
All three clients continuously check for the changes occurring at their respective web services. When client CSInfoClient requests for the consignment stock information from composite web service CWS0, CWS0 invokes StockInfo() web service to get the present stock information. If stock level becomes equal (or less) to reorder point composite web service CWS0 invokes CSInfo() web service and gets the consignment information and sends back to the CSInfoClient. In a similar manner InvoiceInfoClient sends a request to CWS1 composite web service to get the invoice information. CWS1 invokes the web service CSStatus() (which keeps track of the consignment stock usage begin information) and if the present quantity becomes equal to the consignment stock quantity than it invokes the InvoiceGen() web service (which generates the invoice) and gets the invoice information and sends the data to InvoiceInfoClient.
After getting invoice information retailer updates the invoice acknowledgement database. Client InvAckClient receives invoice acknowledge by sending a request and receiving a response from web service InvAck().
Performance Testing of the Proposed Architecture
Tests were performed on two web services hosted on retailer side. The tool used for this purpose was WAPT 3.0, which simulated a number of clients to access these services. Following are the results obtained from stress testing of two web services CSAck and TestInfo.
Performance of CSAckService
Performance of TestInfoService
From Figures shown above we can see that as number of clients increase the web transaction time increase. Transaction time also depends on the size of data received by a client. In case of CSAck service the data size is small as comparing to TestInfo service therefore the average Web Transaction time is smaller in case of CSAck, however it is also rising with as number of clients is increasing. Both the web services can bear a maximum of 176 simultaneous clients at a time, after that the web server shut down.