Writing a simple Web service

Here is a procedure to write a sample web service. Please go through the steps given below.
Step 1:

The screen shot below shows the creation of new web service.

In the Web Services Properties box, give the new Web service a name -- we use TestService for this example -- and close the box.

Now you should have a screen that looks very much like one used for writing a LotusScript agent. Click (Declarations) in the Objects tab of LotusScript events, so you can write a class (classes must always be defined in the (Declarations) section). Enter this code into the IDE:

Class Test Public Function AlertMsg (txt As String) As String AlertMsg = txt End Function End Class

This code does the following:

• Creates a class called Test.
• Defines a method in the class called AlertMsg that accepts a string as a parameter and returns a string as a result (functions and subs in classes are referred to as methods).

This method accepts string as a input and returns the same string.

Open the Web Service Properties box and specify which class to use. Because there may be multiple classes defined in the Web service code, you must select only one of them as an interface to the Web service. The interface class is the one with Public methods that Web service clients can call.

In the Properties box, enter Test (the name of the class you just wrote) in the PortType class field on the first tab.

Here you have created a web service.

The further details working with complex functions, testing of web service, we will discuss in next posts.

What can we do with web services

While Web services allows all these dynamic features to combine multiple services into applications, you still have to build the services first. Programming languages in Computer science is continually evolving. We began decades ago with the idea of a function whereby you provide it some parameters, it executes some operation on those parameters, and it returns a value based on its calculations. Eventually, this first concept evolved into the object where each object had not just a number of functions it can perform but also its own private data variables, rather than relying on external system-wide data variables that previously made it more complex to develop applications. As applications began communicating with each other, the concept of defined universal interfaces for objects became important, allowing objects on other platforms to communicate even if they were written in other programming languages and ran on other operating systems.

At the most recent step, Web services has moved towards the concept of XML-defined interfaces and communications, finally uniting any kind of application with another, as well as providing the freedom to change and evolve over time, as long as they are designed to the appropriate interface. The versatility of XML is what makes Web services different from previous generation component technologies. It allows the separation of grammatical structure (syntax) and the grammatical meaning (semantics), and how that is processed and understood by each service and the environment it exists in. So now, objects can be defined as services, communicating with other services in XML-defined grammar, whereby each service then translates and analyzes the message according to its local implementation and environment. Thus a networked application can truly be composed of multiple entities of various makes and designs as long as they conform to the rules defined by their service oriented architecture.

Thus, with this in mind, Web services allow you to:

• Interact between services on any platform, written in any language.
• Conceptualize application functions into task, leading to task-oriented development and workflows. This allows a higher abstraction of software that can be employed by less software-technical users that work on business level analytics.
• Allow for loose-coupling, which means that interactions between service applications may not break each time there is a change in how one or more services are designed or implemented.
• Adapt existing applications to changing business conditions and customer needs.
• Provide existing or legacy software applications with service interfaces without changing the original applications, allowing them to fully operate in the service environment.
• Introduce other administrative or operations management functions such as reliability, accountability, security, etc., independent of the original function, thus increasing its versatility and usefulness in the business computing environment.

Web Services platform elements

Web Services have three basic platform elements.

These are called SOAP, WSDL and UDDI.

---

What is SOAP?

The basic Web services platform is XML plus HTTP.

• SOAP stands for Simple Object Access Protocol
• SOAP is a communication protocol
• SOAP is for communication between applications
• SOAP is a format for sending messages
• SOAP is designed to communicate via Internet
• SOAP is platform independent
• SOAP is language independent
• SOAP is based on XML
• SOAP is simple and extensible
• SOAP allows you to get around firewalls
• SOAP will be developed as a W3C standard

---

What is WSDL?

WSDL is an XML-based language for describing Web services and how to access them.

• WSDL stands for Web Services Description Language
• WSDL is written in XML
• WSDL is an XML document
• WSDL is used to describe Web services
• WSDL is also used to locate Web services
• WSDL is not yet a W3C standard

---

What is UDDI?

UDDI is a directory service where businesses can register and search for Web services.

• UDDI stands for Universal Description, Discovery and Integration
• UDDI is a directory for storing information about web services
• UDDI is a directory of web service interfaces described by WSDL
• UDDI communicates via SOAP
• UDDI is built into the Microsoft .NET platform

What is WSDL document?

As communications protocols and message formats are standardized in the web community, it becomes increasingly possible and important to be able to describe the communications in some structured way. WSDL addresses this need by defining an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details involved in applications communication.

A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following elements in the definition of network services:

• Types– a container for data type definitions using some type system (such as XSD).
• Message– an abstract, typed definition of the data being communicated.
• Operation– an abstract description of an action supported by the service.
• Port Type–an abstract set of operations supported by one or more endpoints.
• Binding– a concrete protocol and data format specification for a particular port type.
• Port– a single endpoint defined as a combination of a binding and a network address.
• Service– a collection of related endpoints.

These elements are described in detail in Section 2. It is important to observe that WSDL does not introduce a new type definition language. WSDL recognizes the need for rich type systems for describing message formats, and supports the XML Schemas specification (XSD) [11] as its canonical type system. However, since it is unreasonable to expect a single type system grammar to be used to describe all message formats present and future, WSDL allows using other type definition languages via extensibility.

In addition, WSDL defines a common binding mechanism. This is used to attach a specific protocol or data format or structure to an abstract message, operation, or endpoint. It allows the reuse of abstract definitions.

In addition to the core service definition framework, this specification introduces specific binding extensions for the following protocols and message formats:

• SOAP 1.1
• HTTP GET / POST
• MIME

Although defined within this document, the above language extensions are layered on top of the core service definition framework. Nothing precludes the use of other binding extensions with WSDL.

What is WSDL document?

As communications protocols and message formats are standardized in the web community, it becomes increasingly possible and important to be able to describe the communications in some structured way. WSDL addresses this need by defining an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details involved in applications communication.

A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following elements in the definition of network services:

• Types– a container for data type definitions using some type system (such as XSD).
• Message– an abstract, typed definition of the data being communicated.
• Operation– an abstract description of an action supported by the service.
• Port Type–an abstract set of operations supported by one or more endpoints.
• Binding– a concrete protocol and data format specification for a particular port type.
• Port– a single endpoint defined as a combination of a binding and a network address.
• Service– a collection of related endpoints.

These elements are described in detail in Section 2. It is important to observe that WSDL does not introduce a new type definition language. WSDL recognizes the need for rich type systems for describing message formats, and supports the XML Schemas specification (XSD) [11] as its canonical type system. However, since it is unreasonable to expect a single type system grammar to be used to describe all message formats present and future, WSDL allows using other type definition languages via extensibility.

In addition, WSDL defines a common binding mechanism. This is used to attach a specific protocol or data format or structure to an abstract message, operation, or endpoint. It allows the reuse of abstract definitions.

In addition to the core service definition framework, this specification introduces specific binding extensions for the following protocols and message formats:

• SOAP 1.1 (see Section 3)
• HTTP GET / POST (see Section 4)
• MIME (see Section 5)

Although defined within this document, the above language extensions are layered on top of the core service definition framework. Nothing precludes the use of other binding extensions with WSDL.

Web Services in Lotus Notes

There are new things added, and most of us are not came across those special changes. Web services in Lotus notes is one of such changes. With the release of Lotus Notes 7, they have added the facility to create and access the web services with the Lotus Notes.

A Web service is an archive of remote operations that can be called by sending messages over the Internet. A Web service provider publishes a Web service for query and use, and a Web service consumer calls operations from the service. A Web service provider makes available a WSDL (Web Services Description Language) document that defines the service interface. The WSDL document is in XML format. What happens behind the interface is up to the provider, but most providers map the interface to procedure calls in a supported programming language. Incoming requests from a consumer are passed through to the underlying code, and results are passed back to the consumer.
Lotus Domino maps the WSDL interface to an agent-like Web service design element that can be coded in LotusScript or Java. To be used, the Web service must be on a Domino server with HTTP enabled. (We can test the Web service through an HTTP session in the Notes client preview.)

Access is through one of the following Domino URL commands:

?OpenWebService invokes the Web service in response to a SOAP-encoded message sent through an HTTP POST. An HTTP GET (for example, a browser query) returns the name of the service and its operations.

?WSDL returns the WSDL document in response to an HTTP GET.

Several approaches are possible for creating a Web service design element in Domino Designer. We can code it entirely in LotusScript or Java. In these cases, saving the design element generates a WSDL document that reflects the LotusScript or Java code. Or we can import an existing WSDL document. In this case, LotusScript or Java is generated that reflects the operations in the imported WSDL. The Web service design element saves the WSDL document as well as the code. If the public interface has not changed, the WSDL document stays as is. If, in our coding, we change anything that affects the public interface, a new WSDL is generated.

In Domino Designer, the Web service design element resides below Agents under Shared code. The Web service design window looks a lot like the agent design window. Click the New Web Service button to create a new Web service. Double-click an existing Web service to edit it.

Hello My Friends,

This is a blog which I have created, to share your experience, problems and thoughts, about the Lotus Notes and Family.

Here we will post the information about the Lotus Notes, the presentations about Lotus Notes. Here you will also get the information about the different certifications, different happenings in the world of Lotus notes and a lot of more stuff related to Lotus Notes.

Wish you All the Best!!

Pramod Kininge