Unit2

Business motivations for web services

Businesses are increasingly adopting web services due to a variety of compelling motivations. Here
are some key reasons:

1. **Cost Efficiency**:

- **Reduced Infrastructure Costs**: Utilizing web services can significantly cut down on the costs
associated with maintaining physical servers and other IT infrastructure.

- **Pay-as-you-go Pricing**: Many web services offer pricing models that allow businesses to pay
only for the resources they use, which can be more cost-effective than traditional methods.

2. **Scalability**:

- **Elastic Resources**: Web services can easily scale up or down based on demand, allowing
businesses to handle varying workloads without over-provisioning resources.

- **Global Reach**: Leveraging web services enables businesses to provide services to users
around the globe with minimal latency.

3. **Flexibility and Agility**:

- **Rapid Deployment**: Web services allow for quick deployment of applications and services,
enabling businesses to respond swiftly to market changes and opportunities.

- **Integration Capabilities**: Web services facilitate seamless integration with other systems and
services, both internal and external, enhancing overall business agility.

4. **Focus on Core Competencies**:

- **Outsourced Maintenance**: By using web services, businesses can offload the maintenance
and management of IT infrastructure to service providers, allowing them to focus on their core
business activities.

5. **Enhanced Collaboration**:

- **Interoperability**: Web services enable different systems and applications to communicate and
work together, improving collaboration across departments and with external partners.

- **Standardization**: Adoption of web services often involves using standard protocols and
formats, which simplifies integration and collaboration efforts.

6. **Innovation and Competitive Advantage**:

 - **Access to Advanced Technologies**: Web services provide access to cutting-edge technologies,
such as artificial intelligence, machine learning, and big data analytics, which can drive innovation.

- **Faster Time-to-Market**: The agility and rapid deployment capabilities of web services help
businesses bring new products and services to market more quickly, gaining a competitive edge.

7. **Security and Compliance**:

- **Advanced Security Features**: Many web service providers offer robust security measures and
compliance certifications, ensuring data protection and regulatory compliance.

- **Regular Updates**: Web services often include regular security updates and patches, reducing
the burden on businesses to manage these aspects themselves.

8. **Improved Customer Experience**:

- **Personalization**: Web services can enable businesses to deliver personalized experiences to

their customers, enhancing satisfaction and loyalty.

- **Availability and Reliability**: With web services, businesses can offer highly available and
reliable services, improving the overall customer experience.

These motivations highlight why businesses are increasingly turning to web services to drive
efficiency, innovation, and growth.

B2B

What Are B2B Services?

Business-to-business (B2B) web services represent a category of digital solutions and
platforms specifically engineered to facilitate interactions, transactions, and collaborations
between businesses operating within diverse industries. At their core, B2B web services
leverage internet-based technologies to enable seamless communication, data exchange, and
transactional activities among participating entities.

These services encompass a wide array of functionalities and capabilities, often tailored to
meet the complex requirements and operational intricacies inherent in B2B relationships.
They serve as virtual conduits through which businesses engage in various forms of
interaction, including procurement, sales, supply chain management, logistics coordination,
financial transactions, and collaborative ventures.
How Do B2B Services Work?
B2B services work by providing digital platforms, technologies, and frameworks that
facilitate interactions, transactions, and collaborations between businesses. Here's a
breakdown of how they typically function:

1. Platform provisioning. B2B service providers create and maintain digital platforms,
which serve as the infrastructure for enabling B2B interactions. These platforms take
various forms, including web-based portals, cloud-based applications, and integrated
software solutions.
2. Onboarding. Businesses interested in using B2B services typically go through an
onboarding process, during which they register, create accounts, and configure their
settings within the platform. This may involve providing information about their
company, business operations, products or services, and preferred communication
channels.
3. Data exchange. B2B services facilitate the exchange of data between participating
businesses. This includes various types of information such as product catalogs,
pricing details, inventory levels, order status, invoices, and shipping information. Data
exchange may occur through standardized formats such as EDI (Electronic Data
Interchange), APIs (Application Programming Interfaces), or proprietary
communication protocols.
4. Transaction processing. B2B services support the processing of transactions
between businesses. This includes activities such as placing orders, generating
invoices, making payments, and updating inventory records. Transactions may be
automated through predefined workflows and business rules.
5. Integration. B2B services often integrate with existing systems and applications used
by businesses, such as ERP (Enterprise Resource Planning), CRM (Customer
Relationship Management), and SCM (Supply Chain Management) systems.
Integration enables seamless data flow between different parts of the business
ecosystem, ensuring consistency and accuracy in information exchange.
 6. Collaboration tools. Many B2B services offer collaboration tools that facilitate
communication and teamwork among business partners. These tools include
messaging systems, document sharing platforms, project management tools, and
virtual meeting spaces.
7. Security and compliance. B2B services prioritize security and compliance to protect
sensitive business data and ensure regulatory adherence. They employ encryption,
access controls, authentication mechanisms, and auditing features to safeguard
information against unauthorized access, breaches, and data loss.
8. Analytics and insights. B2B services often include analytics and reporting
capabilities that provide businesses with valuable insights into their operations,
performance metrics, and market trends. By analyzing data generated through B2B
interactions, businesses can make informed decisions, optimize processes, and
identify opportunities for growth and improvement.

Why Are B2B Services Important?

B2B services play a crucial role in modern commerce for several reasons:

 Efficiency enhancement. B2B services streamline business processes by automating

tasks such as order processing, invoicing, and inventory management. This
automation reduces manual effort, minimizes errors, and accelerates transaction
cycles, leading to greater operational efficiency and cost savings.
 Global reach. B2B services enable businesses to expand their reach beyond
geographic boundaries and access a wider pool of potential partners, suppliers, and
customers. By leveraging digital platforms and technologies, companies can engage in
cross-border trade and collaboration more easily, opening up new growth
opportunities in international markets.
 Improved collaboration. B2B services facilitate collaboration and communication
between businesses, enabling them to work together on joint projects, initiatives, or
transactions. Collaboration tools such as messaging systems, document sharing
platforms, and virtual meeting spaces foster greater transparency, coordination, and
synergy among business partners.
 Enhanced customer experience. B2B services help businesses deliver a superior
customer experience by enabling faster response times, personalized interactions, and
seamless transactions. By integrating with CRM systems and leveraging customer
data, companies can better understand their clients' needs, preferences, and behaviors,
leading to more tailored products, services, and solutions.
 Supply chain optimization. B2B services optimize supply chain operations by
facilitating real-time visibility, tracking, and management of inventory, orders, and
shipments. Businesses achieve greater efficiency, resilience, and agility in their
supply chain processes by connecting suppliers, manufacturers, distributors, and
retailers through digital networks.

What Is B2B Service Example?

Electronic Data Interchange (EDI)
Enterprise Resource Planning (ERP) Systems
Customer Relationship Management (CRM) Software
Supply Chain Management (SCM) Platforms

B2C:

What Is Business-to-Consumer (B2C)?

The term business-to-consumer (B2C) refers to the process of selling products and services
directly between a business and consumers who are the end-users of its products or services.
Most companies that sell directly to consumers can be referred to as B2C companies.

B2C became immensely popular during the dotcom boom of the late 1990s when it was
mainly used to refer to online retailers who sold products and services to consumers through
the internet.

As a business model, business-to-consumer differs significantly from the business-to-

business (B2B) model, which refers to commerce between two or more businesses.

Key Takeaways

 Business-to-consumer refers to the process of businesses selling products and services

directly to consumers, with no middle person.
 B2C typically refers to online retailers who sell products and services to consumers through
the internet.
 Online B2C became a threat to traditional retailers, who profited from adding a markup to
the price.
 However, companies like Amazon, eBay, and Priceline have thrived, ultimately becoming
industry disruptors.

B2C in the Digital World

There are typically five types of online B2C business models that most companies use online
to target consumers.

1. Direct sellers. This is the most common model in which people buy goods from online
retailers. These may include manufacturers or small businesses or simply online versions of
department stores that sell products from different manufacturers.

2. Online intermediaries. These are liaisons or go-betweens who don't actually own
products or services that put buyers and sellers together. Sites like Expedia, trivago, and Etsy
fall into this category.

3. Advertising-based B2C. This model uses free content to get visitors to a website. Those
visitors, in turn, come across digital or online ads. Large volumes of web traffic are used to
sell advertising, which sells goods and services. One example is media sites like HuffPost, a
high-traffic site that mixes advertising with its native content.

4. Community-based. Sites like Meta (formerly Facebook), which build online communities
based on shared interests, help marketers and advertisers promote their products directly to
consumers. Websites typically target ads based on users' demographics and geographical
location.

5. Fee-based. Direct-to-consumer sites like Netflix charge a fee so consumers can access
their content. The site may also offer free but limited content while charging for most of it.
The New York Times and other large newspapers often use a fee-based B2C business model.

What Are the 5 Types of Business-to-Consumer Models?

Typically, B2C models fall into the following five categories: direct sellers, online intermediaries,
advertising-based B2C, community-based, and fee-based. The most frequently occurring is the direct
seller model, where goods are purchased directly from online retailers. By contrast, an online
intermediary model would include companies like Expedia, which connect buyers and sellers.
Meanwhile, a fee-based model includes services such as Disney+, which charges a subscription to
stream their video-on-demand content.
Technical Motivations

Web services are an integral part of modern software architecture, enabling applications to
communicate over a network. The technical motivations for using web services include:

1. **Interoperability**:

- Web services allow different applications from various sources to communicate with each other
without time-consuming custom coding. They are platform-independent, meaning that a web service
written in one programming language can be used by an application written in a different language.

2. **Reusability**:

- Web services allow the reuse of services in different applications. This modular approach enables
developers to use existing services to build new applications or enhance existing ones.

3. **Scalability**:

- Web services can be designed to scale easily, accommodating an increasing number of users or
requests. By distributing the load across multiple servers, web services ensure high availability and
performance.
4. **Standardization**:

- Web services use standard protocols and formats such as HTTP, XML, JSON, SOAP, and REST. This
standardization simplifies integration and communication between different systems.

5. **Loose Coupling**:

- Web services promote loose coupling between client and server components. This means that
changes in one component do not necessarily require changes in the other, making maintenance and
updates easier.

6. **Accessibility**:

- Web services can be accessed over the internet using standard web protocols. This makes it easy
to expose functionality to a wide range of clients, including web browsers, mobile apps, and other
services.

7. **Security**:

- Web services can implement robust security measures, such as encryption, authentication, and
authorization, to ensure secure communication and data exchange.

8. **Integration**:

- They facilitate the integration of heterogeneous and distributed systems within and across
organizational boundaries. This is particularly useful for integrating legacy systems with new
applications.

9. **Flexibility**:

- Web services can be composed to form more complex services, allowing businesses to quickly
adapt to changing requirements and market conditions.

10. **Cost Efficiency**:

- By reusing existing services and reducing the need for custom integration code, web services can
help lower development and maintenance costs.

These motivations highlight why web services are a critical component in building flexible, scalable,
and interoperable systems in today’s interconnected digital landscape.

Unit3

Transport protocols for web services:

Transport protocols are essential for the operation of web services as they define how data is
transmitted over the network. Here are some of the primary transport protocols used in web
services:

1. HTTP/HTTPS:
o Hypertext Transfer Protocol (HTTP) is the most commonly used protocol
for web services, especially for RESTful services. It provides a simple
request-response model that is well-suited for web applications.
o HTTPS is HTTP over SSL/TLS, providing a secure communication channel
by encrypting the data transmitted between the client and the server.
2. SOAP over HTTP/HTTPS:
o Simple Object Access Protocol (SOAP) is a protocol for exchanging
structured information in the implementation of web services. SOAP can be
transported over various protocols, but HTTP/HTTPS is the most common
transport layer due to its widespread use and compatibility with firewalls and
proxies.
3. SMTP:
o Simple Mail Transfer Protocol (SMTP) is primarily used for sending emails
but can also be used as a transport protocol for web services, especially when
dealing with asynchronous communication. SOAP messages can be sent as
email attachments.
4. JMS:
o Java Message Service (JMS) is a messaging standard that allows application
components to create, send, receive, and read messages. JMS is often used for
asynchronous communication in enterprise environments and can be used as a
transport layer for web services.
5. AMQP:
o Advanced Message Queuing Protocol (AMQP) is an open standard for
passing messages between applications or organizations. It is designed to
support messaging for various business applications and can be used for
reliable, asynchronous communication in web services.
6. MQTT:
o Message Queuing Telemetry Transport (MQTT) is a lightweight
messaging protocol designed for low-bandwidth, high-latency, or unreliable
networks. It is often used in IoT applications and can be employed as a
transport protocol for web services requiring efficient, real-time
communication.
7. WebSocket:
o WebSocket is a protocol providing full-duplex communication channels over
a single TCP connection. It is suitable for applications requiring real-time data
exchange, such as live chat applications, gaming, and real-time notifications.
8. REST over HTTP/HTTPS:
o Representational State Transfer (REST) is an architectural style that uses
standard HTTP/HTTPS methods (GET, POST, PUT, DELETE) for
communication. RESTful services are stateless, and each request from a client
contains all the information the server needs to fulfill that request.

Messaging with web services

What is a Message-based WebService
Answer from ServiceStack's interview on InfoQ:

In essence, a message-based service is one that passes messages to facilitate its

communication. A good metaphor for illustrating the differences between a RPC method and
a message-based API can be seen in Smalltalk or Objective-C's message dispatch mechanism
vs a normal static C method call. Method invocations are coupled to instance they are
invoked on, in a message-based system the request is captured in the message and sent to a
receiver. The receiver doesn't have to handle the message as it can optionally delegate the
request to an alternative receiver to process instead.

Message-based design in ServiceStack

Message-based design is enabled in ServiceStack by capturing the Services Request Query

into a Request DTO that's completely de-coupled from any one implementation. You can
think of making a ServiceStack request as a Smalltalk runtime method dispatch at a Macro
scale, where the ServiceStack host is the Receiver, the HTTP Verb is the selector and
Request DTO is the message.

It doesn't matter on which of the endpoints the Request is sent to as the request can be
populated with any combination of PathInfo, QueryString and Request Body. After the
Request binding, the request travels through all user-defined filters and pre-processors for
inspection where it can optionally be handled before it is able to reach the service
implementation. Once the request reaches the service it invokes the best matching selector,
by default it will look for a method with the same name as a HTTP Verb, if it doesn't exist it
falls back to using a catch-all 'Any' method that can be used to handle the request on any
endpoint or route in any format. Even when inside the Service implementation it is able to
further delegate the request to an alternative service or easily proxy the request to a remote
sharded instance if it needs to.

Conceptually in ServiceStack you're just sending a message to a ServiceStack instance, the

client is not concerned with what ultimately handles it, only that a response is returned for
reply requests or that the request is successfully accepted for oneway messages. In a RPC
API you're conceptually invoking a remote method which has the request tightly coupled to
its remote implementation method signature.

Benefits of adopting a Message-based design

There are many natural benefits gained when adopting a message-based design they offer better
resilience, flexibility, versionability than their RPC cousins. An example of one of the benefits possible
is when you send a request to its one-way endpoint, if the ServiceStack instance has a MQ Host
configured, the request is automatically deferred to the configured MQ Broker and processed in the
background. So even if the ServiceStack Host goes down none of the pending messages are lost and
are automatically processed the next time the Host starts up. This is the type of behavior that is
enabled for free in ServiceStack. When no MQ host is enabled the request is just processed normally,
i.e. synchronously by a HTTP web worker.

Adopted by most leading distributed frameworks

Benefits of message-based designs are already well-known to developers of leading
distributed frameworks who have adopted message-based designs in leading platforms, e.g:
Google's Protocol Buffers, Amazon's Web Services platform, Erlang processes, F#
mailboxes, Scala's Actors, Go's Channels, Dart's Isolates and Clojure's agents, etc.

Message-based Services in ServiceStack

Message-based Services in AWS

Concurrency in F# - Erlang Style Message Passing

Google Protobuf Messages

Scala Actors
Describing Web services

What are Web Services?

Last Updated : 14 Jul, 2021





The Internet is the worldwide connectivity of hundreds of thousands of computers of various

types that belong to multiple networks. On the World Wide Web, a web service is a
standardized method for propagating messages between client and server applications. A web
service is a software module that is intended to carry out a specific set of functions. Web
services in cloud computing can be found and invoked over the network.
The web service would be able to deliver functionality to the client that invoked the web
service.
A web service is a set of open protocols and standards that allow data to be exchanged
between different applications or systems. Web services can be used by software programs
written in a variety of programming languages and running on a variety of platforms to
exchange data via computer networks such as the Internet in a similar way to inter-process
communication on a singleFunctions of Web Services

 It’s possible to access it via the internet or intranet networks.

 XML messaging protocol that is standardized.
 Operating system or programming language independent.
 Using the XML standard, it is self-describing.
 A simple location approach can be used to locate it.

Components of Web Service

XML and HTTP is the most fundamental web services platform. The following components
are used by all typical web services:

computer.

SOAP (Simple Object Access Protocol)

UDDI (Universal Description, Discovery, and Integration)

WSDL (Web Services Description Language) (Draw all diagrams)

WS-Policy

About WS-Policy
WS-Policy is a model and syntax you can use to communicate the policies associated with a
web service. Policies describe the requirements, preferences, or capabilities of a web service.
You attach a policy to a policy subject, for example, a service, endpoint, operation, or
message. After attaching a policy to a policy subject, the policy subject becomes governed by
that policy.
A policy is made up of one or more policy assertions. Each policy assertion conveys a
requirement, preference, or capability of a given policy subject. You specify policy assertions
using XML-based policy expressions.
webMethods Integration Server provides support for Web Services Policy Framework (WS-
Policy) Version 1.2.
In Integration Server, a policy is specified using policy expressions in an XML file called a
WS-Policy file (more simply called policy file). For more information, see WS-Policy Files
and Guidelines for Creating WS-Policy Files.
To have a web service governed by the policy in policy file, you attach the policy to the web
service descriptor. You can attach WS-Policies at the binding operation message type level,
such as input, output, and fault, in a web service descriptor.

Web Services Policy (WS-Policy)

Web Services Policy Framework (WS-Policy) provides a general purpose model and
corresponding syntax to describe and communicate the policies of a Web Service. WS-Policy
defines a base set of constructs that can be used and extended by other Web Services
specifications to describe a broad range of service requirements, preferences, and
capabilities.

 WS-PolicyAssertions specifies a set of common message policy assertions that can be

specified within a policy.
 WS-PolicyAttachment specifies three specific attachment mechanisms for using policy
expressions with existing XML Web Service technologies. Specifically, they define how to
associate policy expressions with WSDL type definitions and UDDI entities. They also define
how to associate implementation-specific policy with all or part of a WSDL portType when
exposed from a specific implementation.

Manipulating Web services

Modifying a WSDL File

1. Adding a New Operation:

o Add new messages, portType operations, binding operations, and service ports for
the new operation.
o Ensure consistency across the WSDL by updating all relevant sections.

2. Changing Data Types:

o Update the <types> section to reflect new or modified data structures.
o Ensure that the messages and operations using these types are also updated.

3. Updating Endpoints:
o Modify the <service> section to change the URL in the <soap:address>
element.
 o This is often necessary when moving a service to a different server or changing the
endpoint path.

Validating WSDL

1. XML Schema Validation:

o Use XML schema validation tools to ensure the WSDL file is well-formed and adheres
to the WSDL schema.

2. **Tools and

Utilities**:

 Use tools like wsdl.exe, WSDL2Java, or online WSDL validators to check the correctness of
the WSDL file.
 IDEs like Eclipse or IntelliJ IDEA offer built-in tools for WSDL validation and manipulation.

Example of Modifying a WSDL File

Here’s a simple example of adding a new operation called NewOperation to an existing

WSDL file:

1. Add New Messages:

xml
Copy code
<message name="NewOperationRequestMessage">
<part name="parameters" element="tns:NewOperationRequest"/>
</message>
<message name="NewOperationResponseMessage">
<part name="parameters" element="tns:NewOperationResponse"/>
</message>

2. Define New Types:

xml
Copy code
<types>
<xsd:schema>
<xsd:element name="NewOperationRequest" type="xsd:string"/>
<xsd:element name="NewOperationResponse" type="xsd:string"/>
</xsd:schema>
</types>

3. Add New Operation to PortType:

xml
Copy code
<portType name="ExamplePortType">
<operation name="NewOperation">
<input message="tns:NewOperationRequestMessage"/>
<output message="tns:NewOperationResponseMessage"/>
</operation>
</portType>
Tools for Manipulating WSDL

1. SOAPUI:
o A popular tool for testing and analyzing web services. It can import WSDL files,
generate requests, and provide a visual interface for examining the service.

2. Apache CXF:
o A framework for developing web services that supports WSDL manipulation. It
provides tools to generate code from WSDL and vice versa.

3. Visual Studio:
o Allows developers to generate client-side code from WSDL files and provides a WSDL
editor.

Eclipse: Best Practices for WSDL Manipulation

1. Keep WSDLs Simple and Modular:

o Avoid overly complex WSDL files. Break down services into smaller, manageable
WSDL files if needed.

2. Consistent Naming Conventions:

o Use clear and consistent naming conventions for operations, messages, and data
types to avoid confusion.

3. Versioning:
o Implement a versioning strategy for WSDL files to manage changes and backward
compatibility.

4.
o Offers plugins for WSDL creation and editing, including WSDL validation and web
service client generation.

Web services discovery:

Web Services Discovery provides access to software systems over the Internet using
standard protocols. In the most basic scenario there is a Web Service Provider that publishes a
service and a Web Service Consumer that uses this service. Web Service Discovery is the
process of finding suitable web services for a given task.[1]

Publishing a web service involves creating a software artifact and making it accessible to
potential consumers. Web service providers augment a service endpoint interface with an
interface description using the Web Services Description Language (WSDL) so that a
consumer can use the service.

Also write about UDDI

Web services inspection

Web Services Inspection Language

(WS-Inspection)

Distributed Web Service Discovery Using WS-Inspection

Documents
Service discovery defines a process for locating service providers and retrieving service description
documents, and is a key component of the overall Web services model. Service discovery is a very
broad concept, which means that it is unlikely to have one solution that addresses all of its
requirements. The Universal Description, Discovery and Integration (UDDI) specification addresses a
subset of the overall requirements by using a centralized service discovery model. This article will
provide an overview of the Web Services Inspection Language (WS-Inspection), which is another
related service discovery mechanism, but addresses a different subset of requirements using a
distributed usage model. The WS-Inspection is designed around an XML-based model for building an
aggregation of references to existing Web service descriptions, which are exposed using standard
Web server technology.

The Web Services architecture is based upon the interactions between three primary roles:
service provider, service registry, and service requestor. These roles interact using publish,
find and bind operations. The service provider is the business that provides access to the Web
service and publishes the service description in a service registry. The service requestor finds
the service description in a service registry and uses the information in the description to bind
to a service. A logical view of the Web Services architecture is shown in Figure 1. In this
view of the Web Services architecture, the service registry provides a centralized location for
storing service descriptions. A UDDI registry is an example of this type of service registry.

Figure 1: Web Services Architecture

Although it is important, the centralized service registry is not the only model for Web
service discovery. The simplest form of service discovery is to request a copy of the service
description from the service provider. After receiving the request, the service provider can
simply email the service description as an attachment or provide it to the service requestor on
a transferable media, such as a diskette. Although this type of service discovery is simple, it
is not a very efficient since it requires prior knowledge of the Web service, as well as the
contact information for the service provider.

Between these two extremes, there is a need for a distributed service discovery method that
provides references to service descriptions at the service provider's point-of-offering. The
Web Services Inspection Language provides this type of distributed discovery method, by
specifying how to inspect a web site for available Web services. The WS-Inspection
specification defines the locations on a Web site where you could look for Web service
descriptions.

Since the Web Services Inspection Language focuses on distributed service discovery, the
WS-Inspection specification complements UDDI by facilitating the discovery of services
available on Web sites, but which may not yet be listed in a UDDI registry. Additional
information on the relationship between the Web Services Inspection Language and UDDI
can be found in The WS-Inspection and UDDI Relationship (see Resources).

WS-Inspection Overview
The WS-Inspection specification (see Resources) does not define a service description
language. WS-Inspection documents provide a method for aggregating different types of
service descriptions. Within a WS-Inspection document, a single service can have more than
one reference to a service description. For example, a single Web service might be described
with both a WSDL file and within UDDI. References to these two service descriptions should
be put into a WS-Inspection document. If multiple references are available, it is beneficial to
put all of them in the WS-Inspection document so that the document consumer can select the
type of service description that they are capable of understanding and want to use. Figure 2
provides an overview of how WS-Inspection documents are used.

Figure 2: WS-Inspection Overview

The WS-Inspection specification contains two primary functions, which are discussed in
more detail in the next two sections.

 It defines an XML format for listing references to existing service descriptions.

 It defines a set of conventions so that it is easy to locate WS-Inspection documents

Unit4

Different types of b2b interactions

Business-to-Business (B2B) interactions refer to the various types of transactions and relationships
that occur between businesses. These interactions can be classified into different types based on
their nature and the purpose they serve. Here are some of the main types of B2B interactions:

### 1. **Supplier and Manufacturer**

 - **Description**: This type of interaction involves a supplier providing raw materials, components,
or services to a manufacturer.

- **Example**: A steel supplier providing materials to an automobile manufacturer.

### 2. **Manufacturer and Distributor**

- **Description**: Here, manufacturers sell their finished products to distributors who then resell
them to retailers or other businesses.

- **Example**: An electronics manufacturer selling products to a wholesaler.

### 3. **Distributor and Retailer**

- **Description**: Distributors supply products to retailers, who then sell them directly to
consumers.

- **Example**: A food distributor supplying grocery stores.

### 4. **Service Provider and Business Client**

- **Description**: Service providers offer various services to other businesses to support their
operations.

- **Example**: An IT consulting firm providing technology solutions to a financial services

company.

### 5. **Manufacturer and End Business User**

- **Description**: Manufacturers may sell products directly to the business end-users, bypassing
distributors and retailers.

- **Example**: A software company selling enterprise software directly to large corporations.

### 6. **Franchisor and Franchisee**

- **Description**: A franchisor grants a franchisee the rights to operate a business under its brand
and sell its products or services.

- **Example**: A fast-food chain allowing an individual to open and operate a franchise location.
### 7. **Joint Ventures and Strategic Alliances**

- **Description**: Businesses may form partnerships to leverage each other's strengths and
capabilities to achieve mutual goals.

- **Example**: Two tech companies collaborating on the development of new technology.

### 8. **Procurement and Sourcing**

- **Description**: Businesses interact to procure goods and services needed for their operations,
often through procurement platforms or sourcing agreements.

- **Example**: A company sourcing office supplies from a B2B online marketplace.

### 9. **B2B Marketplaces and Platforms**

- **Description**: Online platforms facilitate B2B transactions by bringing buyers and sellers
together in a digital marketplace.

- **Example**: Alibaba.com connecting international buyers with manufacturers and suppliers.

### 10. **Reseller Programs**

- **Description**: Companies allow other businesses to sell their products, often with value-added
services.

- **Example**: A software company allowing IT service providers to resell its software with
additional support services.

### 11. **Outsourcing**

- **Description**: Businesses contract out certain functions or processes to specialized external

providers.

- **Example**: A company outsourcing its customer service operations to a call center.

### 12. **B2B Financial Transactions**

 - **Description**: Financial interactions such as loans, credit agreements, and investment activities
between businesses and financial institutions.

- **Example**: A business securing a loan from a bank to expand its operations.

### 13. **Technology Integration and Support**

- **Description**: Businesses interact to integrate and support technological solutions to enhance

their operations.

- **Example**: A cloud service provider offering infrastructure solutions to a software

development company.

### 14. **Consulting and Professional Services**

- **Description**: Professional service firms offer expertise and advice to other businesses to help
them improve operations and strategy.

- **Example**: A management consulting firm advising a manufacturing company on process

optimization.

### 15. **Logistics and Supply Chain Management**

- **Description**: Interactions involving the planning, implementation, and control of the flow of
goods and services.

- **Example**: A logistics company providing warehousing and transportation services to a retail

chain.

These various types of B2B interactions illustrate the complex and interconnected nature of modern
business ecosystems, where businesses rely on each other to create value, enhance efficiency, and
achieve competitive advantage.

Rosetta net

RosettaNet
Named after the famed Rosetta Stone that helped in the understanding of
ancient languages, RosettaNet not only seeks to standardize the grammar and
language for Information Technology (IT) vendors to participate in e-business
transactions but also to specify the business processes in which they take place.
RosettaNet has gained much attention from the heavyweights and over 400
participants in the IT industry, many of which are also members of ebXML and
other efforts. RosettaNet was formed in 1998 as an independent IT and
electronic components–focused industry consortium formed by leading
manufacturers, suppliers, distributors, and resellers. Its main goal is to produce
an e-business specification for the industry that optimizes supply chain
interactions. The result is a comprehensive set of standards and guidelines for
an automated, Internetbased exchange of business information and transactions
between trading partners. RosettaNet was an early proponent of defining B2B
process standards in addition to simplifying business data formats, and perhaps
their work has influenced the direction that other formats such as ebXML are
headed. In essence, the group is focused on enabling businesses to conduct
dynamic trade by means of providing flexible trading networks, improving
operational efficiency, and presenting new business opportunities. An
illustration of RosettaNet’s role in e-business is shown in Figure 20.7, which
references the eCo Framework as well.
The main components of the RosettaNet e-business architecture consist of the
following:

Data dictionaries

Partner Interface Processes (PIPs)

The RosettaNet Implementation Framework (RNIF)

Business process modeling and analysis

Future of RosettaNet

A key element in this vision is a shift in strategy from being focused on

providing a cer-tain number of business process definition documents known as
Partner Interface Processes (PIPs) to an e-business “ecosystem” that focuses
more on proof-of-concept implementations, small subsets of existing PIPs, and
implementation with a limited set of trading partners. Ten production
milestones have been created that are meant to reflect real-world
implementations and full-fledged tests of the capabilities of the RosettaNet
specifications. Each of these milestones consists of a small ecosystem of
companies committed to implementing a particular business process scenario, in
a production or nontest capacity, by a certain date. Each milestone deals with
different, specific problems within a supply chain. For example, in the
Electronic Components industry, 15 compa-nies are committed to implementing
a closed-loop “Design Win Management” process by December 2001. Cisco’s
iHub project is committed to implementing 24 PIPs that provide greater supply
and demand chain visibility by the third quarter of 2001. Each of these
milestones is committed to tackling different business process scenarios and
con-sists of three phases of implementation with a steadily increasing number of
trading part-ners at each phase. Some of these processes will result in
implementation of RosettaNet PIPs, whereas others will result in the creation of
new processes to be defined by RosettaNet.
Applied xml in vertical industries

IN THIS CHAPTER

• The Vertical Industries

• Professional Services Standards

• Manufacturing 977

• Scientific and Engineering 984

• Print, Media, and Entertainment 989

A Final Note: XML Standards Adoption 992The majority of this book

has dealt with what XML is, the various technologies that enrich the language,
and how to implement XML in a variety of application scenarios. However, we
have not yet talked about the myriad of ways that XML is actually being used
and applied in different business scenarios. The actual, real-world
implementation of XML is where the “rubber meets the road.” Without
widespread usage and adoption of XML, it is merely an abstract technology
with lots of promise but little delivery. The “proof is in the pudding” when
many businesses in different industries make use of XML in their day-to-day
operations or in other business-critical capacities.

You may even be reading this book to gain a better understanding of how XML
can ben-efit and improve the operations of your particular business or industry.
As such, the vast majority of this book has addressed the technologies necessary
for these implementa-tions, but what remains are specific examples and advice
for industry-specific implemen-tations of XML technologies. This chapter will
get you well on your way towards under-standing how XML has benefited and
impacted a variety of industries, ranging from manufacturing and health care to
government and entertainment industries. In addition, for those readers who are
now becoming familiar with XML from a technical viewpoint, this chapter
provides real-world implementations of XML so that you can apply your
technical skills to “nontechnical” industries and provide a quick return-on-
investment (ROI) for your skills. In general, this chapter turns XML “promise”
into XML “reality.”

The Vertical Industries

Before we can launch into a discussion of the different vertical industries, we
must answer the question, What exactly is a vertical industry? The term vertical
is used to define any user community that has a specific and focused set of
needs that differ from other “parallel” industries. Horizontal technologies (or
industries) are those that span all industries and don’t apply to any particular
industry specifically. In the context of our discussion, a vertical industry is a
separately identifiable user community that bases its vocabularies on the
horizontal technologies represented by XML. Figure 22.1 illustrates

According to research conducted by ZapThink, an XML industry analyst firm,

there are over 450 XML vocabularies publicly announced in various registries
and reference sources as of October 2001. This number has grown from around
120 in February 2000 and 250 in August 2000. It seems as though the pace of
new XML schema development is certainly not slowing. Approximately 70
percent of these vocabularies are vertical industry applications, with the
remainder split between horizontal applications and general XML technologies
and frameworks.
Unit5

Role of metadata in web content

The Role of Metadata (RDF and
PRISM) in Web Content
Management

A problem that everyone experiences, whether on the job or in one’s personal

life, is information overload. Let’s just consider your daily mail. If you are like
me, each day that you go to the mailbox, you cannot believe the amount of mail
you receive. Usually I pick up the mail after a hard day at work. I don’t have
time to deal with each item that I have received right at that time. So what do I
do? I carefully place the mail on top of my dining room table. By the weekend, I
am suffering from information overload. There are bills to pay, important items
such as insurance policies to file, magazines that I should read, and lots of junk
mail to throw away. Fortunately, with just a few file folders, I can divide my
mail into these four categories and quickly be able to find what I want.

Now imagine the problems facing those whose job it is to create content. It
might be a magazine publisher or it might be a bank, an insurance company, or
an electronics manu-facturer. Very quickly these organizations discover the
problems that information over-load can bring. So don’t they do what I do with
my mail? Simply divide the content into neat categories and store it?

Well, the answer is, of course, that most content is far more complex than my
mail. There may be several different schemes that people could use to find the
content they need. Each piece of content has characteristics that are critical to its
use and reuse. If I am storing images, for example, I need to know not only the
subject matter but also the format and whether I have rights to use the images.

What Is Metadata?
Metadata is frequently described as “data about other data.” Whether detailing the contents of
a web page, the technical details of an image, or information about an asset's usage rights,
metadata provides additional information that facilitates data management so assets can be
located and used more efficiently. In fact, metadata is mainly designed to be machine-
readable — for example, metadata for a web page helps search engines understand and
categorize pages — and is invisible to the casual site visitor. Likewise, the metadata in a
photograph allows an image to be properly categorized and easily found in a digital asset
management (DAM) system. Metadata also has major implications in the universes of
information-sharing, usage rights and content reuse.

How Does Metadata Work?

Metadata performs a variety of functions. For instance, metadata that's captured with a digital
image helps searchers locate images in a digital asset management system that meet or
exceed certain dimensions. Similarly, metadata for an article in a content management system
provides information such as the writer and copyright information so that the piece can be
properly credited.

In addition, meta tags provide organizations with some control over what people see when
content is delivered via search engines, social media and other collaboration tools, such as
Slack and Messenger. There are three key pieces of metadata that help control what people
see:

 Title: The title of the page (<title>).

 Description: A brief description of the page. (<meta name="description"
content="...">).
 Image: The URL for an image (<meta name="og:image" content="...">).

For any piece of content, web search engines generally deliver a headline, a description (or
“snippet”) of the content and a link to the page. Search engines typically use the contents of
the title tag as the headline in search results and the contents of the description meta tag as the
snippet. (For a variety of algorithmically related reasons, search engines often rewrite
description tags and, sometimes, title tags.) For example, a search for "ERP software" yields:

Types of Metadata
There are three distinct types of metadata: descriptive, structural and administrative. Each one
plays a different role in data and document management, whether those meta tags are web-
facing or are used within other applications.
Descriptive metadata:
Structural metadata:
Administrative metadata:

Architecture of semantic web

Semantic Web Architecture

The architecture of semantic web is illustrated in the figure below. The first layer, URI and
Unicode, follows the important features of the existing WWW. Unicode is a standard of
encoding international character sets and it allows that all human languages can be used
(written and read) on the web using one standardized form. Uniform Resource Identifier
(URI) is a string of a standardized form that allows to uniquely identify resources (e.g.,
documents). A subset of URI is Uniform Resource Locator (URL), which contains access
mechanism and a (network) location of a document - such as http://www.example.org/.
Another subset of URI is URN that allows to identify a resource without implying its location
and means of dereferencing it - an example is urn:isbn:0-123-45678-9. The usage of URI
is important for a distributed internet system as it provides understandable identification of all
resources. An international variant to URI is Internationalized Resource Identifier (IRI) that
allows usage of Unicode characters in identifier and for which a mapping to URI is defined.
In the rest of this text, whenever URI is used, IRI can be used as well as a more general
concept.
Semantic web architecture in layers

Extensible Markup Language (XML) layer with XML namespace and XML schema
definitions makes sure that there is a common syntax used in the semantic web. XML is a
general purpose markup language for documents containing structured information. A XML
document contains elements that can be nested and that may have attributes and content.
XML namespaces allow to specify different markup vocabularies in one XML document.
XML schema serves for expressing schema of a particular set of XML documents.

A core data representation format for semantic web is Resource Description Framework
(RDF). RDF is a framework for representing information about resources in a graph form. It
was primarily intended for representing metadata about WWW resources, such as the title,
author, and modification date of a Web page, but it can be used for storing any other data. It
is based on triples subject-predicate-object that form graph of data. All data in the semantic
web use RDF as the primary representation language. The normative syntax for serializing
RDF is XML in the RDF/XML form. Formal semantics of RDF is defined as well.
Content management workflow

What is a content management workflow?

A content management workflow is a set of tasks a team (most probably your content team)
carries out in order to complete a piece of content on time (for your own brand or a client)
and ensure its publication. In the book Content Strategy For the Web, content strategist and
author Kristina Halvorson states that a content workflow determines "how content is
requested, sourced, created, reviewed, approved, and delivered". A content management
workflow can be simple or complex and will usually be determined by the type of content
you're creating, your budget, your objectives and the scope of your project. The usual steps in
a content production workflow look something like this:

1. Research/Outline and deciding on the type of content you want to create.

2. Planning and defining roles and responsibilities.
3. Set clear deadlines.
4. Decide on a trusted resource to oversee the different stages in the content creation
process.
5. Choose software to keep track of your content workflow.

Step 1: Decide on Type of Content You Want to Create

Step 2: Define individual roles and responsibilities

Step 3: Set Clear Deadlines

Step 4: Have a Trusted Employee Oversee Each Stage of
Your Content Production Process
Step 5: Choose Software to Keep Track of Your Project
Securing web services
Unit1:
Xml processing:
XML Processing
All modern browsers have a built-in XML parser and
their JavaScript implementations support an in-
memory XML DOM API.
You can use the already familiar DOM functions such
as
• getElementById(),
• getElementsByTagName()
• createElement()
to access and manipulate the data

The figure below illustrates transforming the contents of files,

messages, or data from one format to another. Note that the
input and output options are the same. This is meant to
illustrate that the transformation can be from some non-XML
format to XML, from XML to some non-XML format, from
some non-XML format to another non-XML format, or from
one XML vocabulary to another XML vocabulary.
Nevertheless, since this website emphasizes the use of XML
in service-oriented architectures, some XML format or
message that uses XML will most likely be on one end fo the
transformation or the other. This is why it is called "XML
processing."
There are many ways to accomplish the transformation. You could use custom programming,
a tool that generates code, or a specialized scripting language. More information on some
options can be found in the XML resources under the related content heading below.

The basic process is to acquire the input, transform the input, and then render the output in
the desired format.
Unit-2
Limitations of CORBA and DCOM
### CORBA Limitations

1. **Complexity**: CORBA's specification is extensive and

complex, making it difficult to learn, implement, and debug.
2. **Performance**: CORBA's general-purpose nature and
the overhead of its ORB (Object Request Broker) can lead to
performance issues, especially in high-throughput systems.
3. **Interoperability Issues**: Although CORBA aims to be
language-agnostic, practical interoperability issues between
different CORBA implementations can arise.
4. **Firewall Traversal**: CORBA often has difficulty
operating across firewalls due to the dynamic port usage and
complex network interactions.
5. **Legacy Support**: As newer technologies have
emerged, support and updates for CORBA have diminished,
leading to compatibility issues with modern systems.
6. **Complex Deployment**: Deploying CORBA
applications can be cumbersome due to the need for an ORB
and related infrastructure components.
7. **Limited Support for Web Integration**: CORBA was
not designed with the web in mind, making integration with
web-based applications more challenging.
8. **Versioning Issues**: Managing different versions of
CORBA components and ensuring compatibility can be
difficult.
9. **Limited Documentation and Community Support**: As
CORBA has declined in popularity, finding up-to-date
documentation and community support has become harder.
10. **Vendor Lock-in**: Different CORBA vendors may
have proprietary extensions, leading to potential vendor lock-
in issues.
### DCOM Limitations

1. **Platform Dependence**: DCOM is tightly integrated

with Windows, making it less suitable for cross-platform
applications.
2. **Security**: DCOM's security model can be difficult to
configure correctly, and it may pose vulnerabilities if not
managed properly.
3. **Firewall Issues**: Similar to CORBA, DCOM can
struggle with communication across firewalls due to dynamic
port allocation and complex protocols.
4. **Scalability**: DCOM is not well-suited for large-scale,
internet-based applications due to its reliance on Windows
and the complexity of managing distributed components.
5. **Complexity**: Managing and configuring DCOM can be
challenging, especially in large and complex environments.
6. **Interoperability**: DCOM is less flexible in terms of
interoperability with non-Windows platforms compared to
more modern technologies.
7. **Network Latency**: DCOM can suffer from high
network latency, especially in distributed environments where
components are spread across different locations.
8. **Limited Mobile Support**: DCOM was not designed
with mobile applications in mind, making it unsuitable for
mobile-first solutions.
9. **Maintenance Overhead**: Keeping DCOM-based
systems up-to-date and maintained requires significant effort,
particularly in large organizations.
10. **Complex Object Lifecycle Management**: Managing
the lifecycle of distributed objects in DCOM can be complex
and error-prone, leading to potential resource leaks and
stability issues.

Both CORBA and DCOM have seen their use diminish due to
these limitations, as more flexible, scalable, and user-friendly
technologies have emerged.
 SOA
Service-Oriented Architecture (SOA) is a stage in the evolution of application development and/or integration.
It defines a way to make software components reusable using the interfaces.
Formally, SOA is an architectural approach in which applications make use of services available in the
network. In this architecture, services are provided to form applications, through a network call over the
internet. It uses common communication standards to speed up and streamline the service integrations in
applications.
 SOA allows users to combine a large number of facilities from existing services to form applications.
 SOA encompasses a set of design principles that structure system development and provide means for
integrating components into a coherent and decentralized system.
 SOA-based computing packages functionalities into a set of interoperable services, which can be integrated
into different software systems belonging to separate business domains.
The different characteristics of SOA are as follows :
o Provides interoperability between the services.
o Provides methods for service encapsulation, service discovery, service composition,
service reusability and service integration.
o Facilitates QoS (Quality of Services) through service contract based on Service Level
Agreement (SLA).
o Provides loosely couples services.
o Provides location transparency with better scalability and availability. There are two major roles within
Service-oriented Architecture:

1. Service provider: The service provider is the maintainer of the service and the organization that makes
available one or more services for others to use. To advertise services, the provider can publish them in a
registry, together with a service contract that specifies the nature of the service, how to use it, the
requirements for the service, and the fees charged.
2. Service consumer: The service consumer can locate the service metadata in the registry and develop the
required client components to bind and use the service.

Services might aggregate information and data retrieved from other services or create workflows of services to
satisfy the request of a given service consumer. This practice is known as service orchestration Another
important interaction pattern is service choreography, which is the coordinated interaction of services without a
single point of control.
 Components of SOA:

Advantages of SOA:
 Service reusability: In SOA, applications are made from existing services. Thus, services can be reused to
make many applications.
 Easy maintenance: As services are independent of each other they can be updated and modified easily
without affecting other services.
 Platform independent: SOA allows making a complex application by combining services picked from
different sources, independent of the platform.
 Availability: SOA facilities are easily available to anyone on request.
 Reliability: SOA applications are more reliable because it is easy to debug small services rather than huge
codes
 Scalability: Services can run on different servers within an environment, this increases scalability
Disadvantages of SOA:
 High overhead: A validation of input parameters of services is done whenever services interact this
decreases performance as it increases load and response time.
 High investment: A huge initial investment is required for SOA.
 Complex service management: When services interact they exchange messages to tasks. the number of
messages may go in millions. It becomes a cumbersome task to handle a large number of messages.

Unit3
WSDL
WSDL stands for Web Services Description Language. It is the
standard format for describing a web service. WSDL was
developed jointly by Microsoft and IBM.

Features of WSDL
  WSDL is an XML-based protocol for information exchange in
decentralized and distributed environments.
 WSDL definitions describe how to access a web service and
what operations it will perform.
 WSDL is a language for describing how to interface with
XML-based services.
 WSDL is an integral part of Universal Description, Discovery,
and Integration (UDDI), an XML-based worldwide business
registry.
 WSDL is the language that UDDI uses.
 WSDL is pronounced as 'wiz-dull' and spelled out as 'W-S-D-
L'.

WSDL Usage
WSDL is often used in combination with SOAP and XML Schema
to provide web services over the Internet. A client program
connecting to a web service can read the WSDL to determine
what functions are available on the server. Any special datatypes
used are embedded in the WSDL file in the form of XML Schema.
The client can then use SOAP to actually call one of the functions
listed in the WSDL.

Structure of a WSDL Document

Below is the general structure of a WSDL file

 Definition
 TargetNamespace
 DataTypes
 Messages
 Porttype
 Bindings
 Service

example
<!-- WSDL definition structure -->
<definitions
name="Guru99Service"
targetNamespace=http://example.org/math/
xmlns=http://schemas.xmlsoap.org/wsdl/>
 <!-- abstract definitions -->
<types> ...
<message> ...
<portType> ...

<!-- concrete definitions -->

<binding> ...
<service> ...
</definition>

2)SOAP:

What is SOAP?
SOAP is an XML-based protocol for accessing web services over HTTP. It
has some specification which could be used across all applications.

SOAP is known as the Simple Object Access Protocol, but in later times
was just shortened to SOAP v1.2. SOAP is a protocol or in other words is
a definition of how web services talk to each other or talk to client
applications that invoke them.

SOAP was developed as an intermediate language so that applications

built on various programming languages could talk easily to each other
and avoid the extreme development effort.

SOAP Building Blocks

The SOAP specification defines something known as a “SOAP message”
which is what is sent to the web service and the client application.

The below diagram of SOAP architecture shows the various building

blocks of a SOAP Message.
The SOAP message is nothing but a mere XML document which has the
below components.

 An Envelope element that identifies the XML document as a SOAP

message – This is the containing part of the SOAP message and is
used to encapsulate all the details in the SOAP message. This is
the root element in the SOAP message.
 A Header element that contains header information – The header
element can contain information such as authentication
credentials which can be used by the calling application. It can
also contain the definition of complex types which could be used
in the SOAP message. By default, the SOAP message can contain
parameters which could be of simple types such as strings and
numbers, but can also be a complex object type.

Example program
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Tutorial Name" type="string"/>
<xsd:element name="Tutorial Description" type="string"/>
</xsd:sequence>
</xsd:complexType>
Advantages of SOAP

 When developing SOAP based Web services, you need to have

some of language which can be used for web services to talk with
client applications. SOAP is the perfect medium which was
developed in order to achieve this purpose. This protocol is also
recommended by the W3C consortium which is the governing
body for all web standards.
 SOAP is a light-weight protocol that is used for data interchange
between applications. Note the keyword ‘light.’ Since SOAP
programming is based on the XML language, which itself is a light
weight data interchange language, hence SOAP as a protocol that
also falls in the same category.
 SOAP is designed to be platform independent and is also designed
to be operating system independent. So the SOAP protocol can
work any programming language based applications on both
Windows and Linux platform.
 It works on the HTTP protocol –SOAP works on the HTTP protocol,
which is the default protocol used by all web applications. Hence,
there is no sort of customization which is required to run the web
services built on the SOAP protocol to work on the World Wide
Web.