Skip to main content

How to develop,test and maintain SOA based solutions?

As I have discussed earlier, analysis and design part of SOA centers around three approaches SOAD,SOMA and BDD.If you want to recap these concepts then read my blog 'Constituents of SOA'.

In this post, my focus will be to develop SOA using web services.I will talk about webservices in its underlying technologies and in next post, how Apache Axis works to create web services over SOAP and several tools to test webservices.I will take a step-by-step approach for creating one simple web service using Apache Axis meant for Java. Apache Axis also supports C++.The web service example mentioned in this blog requires fair knowledge of Java for its audiences to put this knowledge into practise.



Web services are network based collection of business logic which can be accessed over several protocols like HTTP,SMTP etc.A web service is requested over a network via an XML based SOAP envelope and response is also sent via an XML over the same mechanism.The interoperability of web services is tremendous as it is using XML for communicating and makes it loosely coupled.A Webserivce is consisted of following technologies:

SOAP(Simple Object Access Protocol)


From the draft W3C specification:


SOAP is a lightweight protocol for exchanging structured information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses.


An example of SOAP envelope:












Sample code to create SOAP Envelope using API provided by Apache –AXIS and call a Web Service


Service service = new Service();
Call call = (Call) service.createCall();
call.setTargetEndpointAddress(url);
SOAPEnvelope req = new SOAPEnvelope();
SOAPBodyElement soapBodyElement = new SOAPBodyElement();
soapBodyElement.setName("EVENT");
soapBodyElement.setNamespaceURI("http://api.ws.ps.com/");
SOAPElement eventIdElement =soapBodyElement.addChildElement("EventInstanceId");
SOAPElement authTokenElement = soapBodyElement.addChildElement("AuthToken");
eventIdElement.addTextNode(eventInstanceId);
authTokenElement.addTextNode(authToken);
req.addBodyElement(soapBodyElement);
call.invoke(req);

SOAP Envelope generated by this code:1010101 3270878406854E12







WSDL(Web services Definition Language):


An XML based technology to define a standardized interface for a webservice.WSDL standardizes how a web service represents the input and output parameters of an invocation externally, the function's structure, the nature of the invocation (in only, in/out, etc.), and the service's protocol binding. WSDL allows disparate clients to automatically understand how to interact with a web service.

UDDI(Universal Description,Discovery Interface):


UDDI provides a worldwide registry of web services for advertisement, discovery, and integration purposes. Business analysts and technologists use UDDI to discover available web services by searching for names, identifiers, categories, or the specifications implemented by the web service.


UDDI provides a structure for


representing businesses


business relationships


web services


specification metadata


web service access points.


UDDI has several different uses, based on the perspective of who is using it.From a business analyst's perspective, UDDI is similar to an Internet search engine for business processes. A business analyst can browse one or more UDDI registries to view the different businesses that expose webservices and the specifications of those services.

Prior to the UDDI project, no industry-wide approach was available for businesses to reach their customers and partners with information about their products and web services. Nor was there a uniform method that detailed how to integrate the systems and processes that are already in place at and between business partners.


Conceptually, a business can register three types of information into a UDDI registry. The specification does not call out these types specifically, but they provide a good summary of what UDDI can store for a business:


White pages : Basic contact information and identifiers about a company, including business name, address, contact information, and unique identifiers such as D-U-N-S numbers or tax IDs. This information allows others to discover your web service based upon your business identification.


Yellow pages :Information that describes a web service using different categorizations (taxonomies). This information allows others to discover your web service based upon its categorization (such as being in the manufacturing or car sales business).


Green pages :Technical information that describes the behaviors and supported functions of a web service hosted by your business. This information includes pointers to the grouping information of web services and where the web services are located.


Some Basic Info for Service Registration:


1. Business Entity,Business Entity Name,Business Entity Description


2. Business Service,Business Service Name,Business Service Description


3. Binding Template,Binding Template Description,Access Point Information


4. TModel,TModel Name,TModel Description


Overview URL (path of the WSDL file)


Business Entity

includes information about the actual business e.g. the business name, description, contact information.

Business Service

includes information about a single web service or a group related with web services.

Binding Template


includes information about how and where to access a specific web service.


TModel

includes descriptions and pointers to external technical specifications.


Tools Used for UDDI:

jUDDI : To create a private registry


UDDI4j : API that helps in communicating with a UDDI registry server

Most of the IDEs provide UDDI browser to search and access Web Services


Web Service Browser in RAD


You have to


Switch to J2EE perspective


Goto : Run > Launch the Web Service Explorer

Here I have shown how you can go on implementing Web Service using RAD but Eclipse with WTP support can also support this.






Comments

Popular posts from this blog

Asynchronous Vs. Synchronous Communications

Synchronous (One thread):   1 thread -> |<---A---->||<----B---------->||<------C----->| Synchronous (multi-threaded):   thread A -> |<---A---->| \ thread B ------------> ->|<----B---------->| \ thread C ----------------------------------> ->|<------C----->|

WebSphere MQ Interview Questions

What is MQ and what does it do? Ans. MQ stands for MESSAGE QUEUEING. WebSphere MQ allows application programs to use message queuing to participate in message-driven processing. Application programs can communicate across different platforms by using the appropriate message queuing software products. What is Message driven process? Ans . When messages arrive on a queue, they can automatically start an application using triggering. If necessary, the applications can be stopped when the message (or messages) have been processed. What are advantages of the MQ? Ans. 1. Integration. 2. Asynchrony 3. Assured Delivery 4. Scalability. How does it support the Integration? Ans. Because the MQ is independent of the Operating System you use i.e. it may be Windows, Solaris,AIX.It is independent of the protocol (i.e. TCP/IP, LU6.2, SNA, NetBIOS, UDP).It is not required that both the sender and receiver should be running on the same platform What is Asynchrony? Ans. With messag...

Advantages & Disadvantages of Synchronous / Asynchronous Communications?

  Asynchronous Communication Advantages: Requests need not be targeted to specific server. Service need not be available when request is made. No blocking, so resources could be freed.  Could use connectionless protocol Disadvantages: Response times are unpredictable. Error handling usually more complex.  Usually requires connection-oriented protocol.  Harder to design apps Synchronous Communication Advantages: Easy to program Outcome is known immediately  Error recovery easier (usually)  Better real-time response (usually) Disadvantages: Service must be up and ready. Requestor blocks, held resources are “tied up”.  Usually requires connection-oriented protocol