Results 1 to 1 of 1
  1. #1
    Java Exam is offline Member
    Join Date
    Dec 2011
    Rep Power

    Default Tutorial:Review of SOA and Web Services for the Web Service Developer Exam

    In this article, we will provide an overview of Service Oriented Architecture SOA. We will describe what is SOA and what part does web services play in the realization of SOA systems. This is part of a larger series of articles to help you prepare for the web service developer exam. You can review the first article, “Tutorial:Review of Building Web Services for the Web Service Developer Exam” in order to understand the concepts discussed here.

    The Fundamentals of SOA

    Service oriented architecture is a style of architecture where business logic is decomposed into smaller, distinct units of logic. These units collectively comprise a larger piece of business automation logic while individually the units are able to be distributed. Although the distribution of automation logic into separate units has been done before, the uniqueness of the service-oriented approach is the following:
    • Imposing overbearing dependencies can inhibit the potential of individual businesses. We want to allow business units to interact and leverage each other's services, while avoiding the formation of tight connections resulting in constrictive inter-dependencies. Through the ability of businesses to self-govern their individual services, they can easily evolve and grow relatively independent from each other.
    • While we encourage the independence of business units, it is critical to ensure that they agree to adhere to certain baseline standards. By standardizing key aspects of each business, the accrues tremendous benefits to consumers without imposing significant restraints on the individual business's ability to exercise self-governance.
    • Finally service-oriented architecture (SOA) facilitates the breakdown of business logic into individual units of logic that exist autonomously but are not isolated from each other. These units of logic are required to conform to a set of principles that allow them to evolve independently, while still maintaining a sufficient amount of commonality and standardization. In the world of SOA, these units of logic are known as services.

    How Services Encapsulate Logic

    In order to maintain independence, services encapsulate logic within a clearly distinct context that can be specific to a business task, a business entity, or some other logical grouping. The service can address small or large concerns depending on the scope of the logic represented by the service. Also service logic can encompass the logic provided by other services. In this situation, one or more services are composed into a collective.
    This typically happens in business automation solutions where they serve as implementations of a business process comprised of logic dictating the actions performed by the solution. The logic is broken down into a series of steps that execute in predefined sequences according to business rules and runtime conditions. The figure below shows an automation solution consisting of services that each can encapsulate a task performed by an individual step or a sub-process comprised of a set of step:

    Tutorial:Review of SOA and Web Services for the Web Service Developer Exam-b17-serviceencapsulation.jpg
    Figure:Service Encapsulating Entire Business Logic

    You can develop a service that encapsulates the entire process logic. In that case, the scope represented by the services can encompass the logic encapsulated by other services. In order for these services to use the logic encapsulated they participate in the execution of business activities by forming distinct relationships with those that want to use them.

    How Do Services Relate To Each Other?

    In Service Oriented Architecture, services are frequently used by other services or other programs. Irrespective of the relationship formed between services, they need to be aware of each in order to interact with each other. This awareness is achieved by the use of service descriptions.

    A service description establishes the name of the service and the data expected and returned by the service. Services descriptions are the basis for service to create loosely coupled relationships. This is shown in the figure below:

    figure below illustrates the formation of a relationship between service A and service B once service A is in possession of service B's service description.

    Because it has access to service B's service description, service A has all of the information it needs to communicate with service B.

    Tutorial:Review of SOA and Web Services for the Web Service Developer Exam-b17-servicedescription.jpg
    Figure: Service Description used to Form Relationship Between Service A and Service B

    Services must exchange information in order to interact and accomplish something meaningful. they must exchange information. An exchange of information can only be accomplished on top of a communications framework capable supporting the type of loosely coupled relationship that services requires. One communications framework capable of supporting this paradigm is messaging. Messages serves as independent units of communication. Similar to services, they should be autonomous and capable of self-governing their parts of the processing logic. This is shown in the figure below:

    Tutorial:Review of SOA and Web Services for the Web Service Developer Exam-b17-servicemessage.jpg
    Figure:Message as an Independent Unit of Communication

    The basic architecture for SOA is services that provide service descriptions and communicate via messages. This is similar to past distributed architectures that supported messaging and a separation of interface from processing logic. The key difference is in how the three core components (i.e. services, descriptions, and messages) are designed.

    The Design of Services

    Service-orientation design principle use in the development of system results in standardized service-oriented processing logic. What this means is that the solution will be comprised of units of service-oriented processing logic, it becomes what we refer to as a service-oriented solution. The key aspects of these principles are the following:
    • Loose coupling services is used to maintain the relationship between services while minimizing dependencies as well as only requiring that they retain an awareness of each other.
    • Service Contract Services is used to ensure both services adhere to a communications agreement defined collectively by one or more service descriptions and related documents.
    • Autonomy Services is used to ensure that each service has control over the logic they encapsulate.
    • Abstraction is used to provide a description in the service contract while hiding service logic from the outside world.
    • Reusability Logic is a means of dividing logic into services with the intention of promoting reuse.
    • Composability is a collections of services that can be coordinated and assembled to form composite services.
    • Statelessness Services minimize the retention of information specific to a particular activity.
    • Discoverability Services are designed to be outwardly descriptive in order that they can be located and assessed via available discovery mechanisms.

    The figure below demonstrates the Service-orientation principle design issues:

    Tutorial:Review of SOA and Web Services for the Web Service Developer Exam-b17-serviceorientedprinciples.jpg
    Figure:Service-orientation principles address design issues

    Now that we understand how components make up the basic architecture and also have a set of design principles that can be used to shape and standardize these components, the missing piece is an implementation platform that facilitates bringing all these pieces together to build service-oriented architecture styled systems. The implementation platform for SOA is Web services technologies.

    How Services are Built

    No other technology is as suitable for realizing SOA than Web services. All of the major vendor platforms support the creation of service-oriented solutions based on the use of Web services. This doesn’t mean that one cannot achieve SOA without Web services. Rather that Web services technology is at present best placed to use for SOA.

    From Baseline to Contemporary SOA

    Now that we have described the individual ingredients for the baseline for SOA, let’s go beyond this baseline and look at extensions that are available through advance design techniques and vendor support of already existing Web service specifications.

    Many of the major software vendors continue to conceive new Web services specifications and building increasingly powerful XML and Web services support into current technology platforms. This is primarily due to feedback from customers and the issues encountered by vendors while implementing SOA within their clients’ IT landscape. The result is an extended variation of service-oriented architecture that can be called contermporary SOA.
    Contemporary SOA is built upon the baseline SOA model that we previously outlined and leverages industry and technology advancements to further its original ideals. The required implementation technology can vary and the evolution of contemporary SOAs has reached a point where we can outline a set of common characteristics. These are outlined in the table below:

    Tutorial:Review of SOA and Web Services for the Web Service Developer Exam-b17-soacharacteristics.jpg
    Table:Characteristics of Contemporary SOA

    SOA benefits

    The are clear tangible benefits from adopting a SOA approach to building systems. There are on many levels throughout your organization. In terms of the tangible benefits to the organization, they are focused in two areas primarily:
    • how SOA leads to improvements in automated solution construction
    • how the proliferation of service-orientation ends up benefiting the enterprise as a whole

    This is a general observation and far from complete since each organization can benefit in different ways, depending on their respective goals and the realization of SOA through the various products and technologies. The list of benefits outlined are only to give an indication of the potential the architectural platform.

    Improved integration and interoperability
    The cost and effort of cross-application integration is significantly lowered when applications being integrated are SOA-compliant.

    Inherent reuse
    Building inherently reusable services results in a moderately increased development effort and requires the use of design standards. Subsequently leveraging reuse within services lowers the cost and effort of building service-oriented solutions.

    Streamlined architectures and solutions
    Realizing streamlined architectures and solutions requires adherence to design standards that govern allowable extensions within each application environment. The benefits of streamlined solutions and architectures include the potential for reduced processing overhead and reduced skill-set requirements since the technical resources require only the knowledge of a given application, service, or service extension.

    Leveraging your Legacy Investment
    The cost and effort of integrating legacy and contemporary solutions is lowered since the industry-wide acceptance of Web service technology has spawned a large adaptor market that allows for legacy environments to participate in service-oriented integration architectures. The need for legacy systems to be replaced is potentially lessened.

    Establishing Standardized XML Data Representation
    Fundamentally, SOA is built upon and driven by XML. In adopting of SOA, this results in the opportunity to fully leverage the XML data representation platform. Once a standardized data representation format is fully established, one can reduce the underlying complexity of all affected application environments. This helps to reduce the cost and effort of application development after a proliferation of standardized XML data representation is achieved.

    Focused investment on Communications Infrastructure
    Because Web services establish a common communications framework, SOA can centralize inter-application and intra-application communication as part of standard IT infrastructure. This allows organizations to evolve enterprise-wide infrastructure by investing in a single technology set responsible for communication thus reducing the cost of scaling communications infrastructure as only one communications technology is required to support the federated part of the enterprise.

    "Best-of-breed" Alternatives
    A key feature of service-oriented enterprise environments is the support of "best-of-breed" technology. Since SOA establishes a vendor-neutral communications framework, it frees IT departments from being chained to a single proprietary development and/or middleware platform. The potential scope of business requirement fulfillment increases, as does the quality of business automation.

    Organizational Agility
    Much of service-orientation is based on the assumption that what you build today will evolve over time. One of the primary benefits of a well-designed SOA is to protect organizations from the impact of this evolution. When accommodating change becomes the norm in distributed solution design, qualities such as reuse and interoperability become commonplace. The predictability of these qualities within the enterprise leads to a reliable level of organizational agility. However, all of this is only attainable through proper design and standardization. By abstracting business logic and technology into specialized service layers, SOA can establish a loosely coupled relationship between these two enterprise domains. This allows each domain to evolve independently and adapt to changes imposed by the other, as required. The cost and effort to respond and adapt to business or technology-related change is reduced.

    Fundamentals of Implementing an SOA

    We now possess a clear definition of SOA. The fundamentals of SOA are the following:
    • Service
    • Message
    • Dynamic discovery
    • Web service

    SOA fundamental consist of web services designed to as the decomposition of business into disparate services, each one being a distinct logical unit but also part of a distributed enterprise solution. These logical units are services.

    The business logic gets encapsulated in a service. A service can be either an independent logical unit or can contain in itself other set of services. This was shown in an earlier figure showing how a web service encapsulates business logic. In this case, in order for the calling service to refer to these other services, the other services must contain the service descriptions. They also adhere to certain sets of communication standards to enable information flow across the enterprise offerings in an understandable form. The information is being exchanged in the form of messages based on the interface designed within the system. The interface exposed by a service contains the service behavior and messaging pattern. One of the core reasons for SOA being platform-neutral is that messages are exchanged in XML formats thus adhering to the idea of platform neutrality.

    At a high level, SOA is formed out of three core components:
    • Service Provider (Service)
    • Service Consumer (Consumer)
    • Directory Services (enabled by Broker)

    This is shown in the figure below:

    Tutorial:Review of SOA and Web Services for the Web Service Developer Exam-b17-soacorecomponents.jpg
    Figure:SOA Core Components

    The figure show the following:
    • The service provider offers business processes in the form of services.
    • The services offered by the provider are called by the consumer to achieve certain sets of business goals.
    • The process of services being provided and consumed is achieved by using directory services that lie between the provider and the consumer, in the form of broker.

    The service is published to the directory services in the broker. It is then available to be discovered, bound and executed by the consumer to achieve the set of desired business goals. The design helps in realizing the objectives we mentioned earlier from using SOA by facilitating the following:
    • Loose coupling
    • Platform-neutrality
    • Standards
    • Reusability

    The last one, scalability we have not mentioned. In a SOA, business processes are decomposed into small units which can either be added as an extended unit of the existing service or it can be constructed as a new service. This is what is meant by scalability.

    Implementing SOA

    The first step in implementing SOA is to identify the business functions of which your applications are made. This involves the following:
    • Identifying - the ability to find and isolate the parts of the software that hold self-contained and atomic functionalities. This means the modularization of the business logic into small well defined call specifications. These boundaries need to be built for the software parts and contracts to use them, while not forgetting the value of designing the part in a manner that is re-usable in many contexts. Here we are abstracting the business rule via the use of the concept of interface.
    • Business functions - SOA refers to focusing on the model-and-business layer. A well-designed service should be agnostic about how the information will be presented.
    • Applications - as these consists of software layers. We are looking to build something whose lifecycle is beyond a single project and extends to several applications or projects over time.

    The next question is how does the service consumer expect to invoke the service and receive the requested objects?
    There are a number of common ways to do this:
    • Using platform native calls: In Java this means using Remote Method Invocation (RMI), Sockets, Servlets, or JMS.
    • Using a distributed object communication middleware: CORBA or DCOM are two examples.
    • Using a text-based communication protocol: This can be done by sending the request as a text stream and obtaining a textual response containing the data. This is the approach on which web services are based.

    Using platform native calls, would tie you to a common language shared between the consumer and service (i.e. Java, .NET) as well as tying you to the same versions of the technology.
    Using distributed object communication middleware has been successfully used for this type of communication for many years. CORBA is an example of this due to its cross-platform nature.
    The text-based approach requires a process of serialization (i.e. converting from object to a textual form) when the client sends the request, and a process of deserialization (i.e. conversion from text to object) when received by the server during the response. Although these processes appear to add complexity to the communication, they offer complete independence from technologies and loose coupling between parts. All of the textual approach is done in XML which as we mentioned previously is an independent data representation platform.

    Implementing SOA with Web Services

    Designing by SOA is, in the end, designing the high-level interfaces of the business rules of a given domain model.
    At some point, however, an implementation choice must be made. Therefore, in this paragraph we will explore some solutions, going from a simpler home-made approach, to a complete and widely accepted standard technology (SOAP).
    Before going ahead though, it is important to focus on a term that we will use very often in this book.
    The term is "protocol" and as we will discover soon, it can be used with different meanings depending on the context. One crucial distinction is between "Transportation (or layer) protocol" and "Communication protocol".
    The first refers to the network protocol that transports the information. It may be HTTP (a very common choice), but also may be SMTP (thus allowing asynchronous data exchange) or JMS.
    Communication protocol, instead, deals with the way we put and extract the message into and from an XML document, and will be the main subject of this section.

    At first, we will see how to build a very basic system where XML requests and responses are exchanged through the HTTP protocol in a homemade manner. This will help understand some communication mechanisms from the ground up.
    Then, this approach will be standardized with the REST, getting to a still more basic SOA implementation, but with a clean and well designed communication protocol.
    Finally, with SOAP, we will go through a more complete and flexible solution with a wide range of features.

    Basic SOA With XML Over HTTP Protocol

    The process of designing services yields to a number of results. First it produces a list of service definitions that can be referred to as a “Catalog of Services”. This should be organized into sections known as “Functional Domains”. An example of this could be a breakdown done by Item, Order and Customer. The functional domains for the services would then look like the following:

    • insertItem
    • updateItem
    • deleteItemById
    • findItemById
    • findAllItems
    • findItemsByCriteria

    • createOrder
    • findOrderById
    • findAllOrdersByCustomer

    There will often be some overlap in the classification of methods. Often the services will share common mechanisms for transaction handling or control flow and are initially around common tasks that are performed on domain objects such as all of the Create Read Update and Delete (CRUD) operations. The CRUD operations for the item domain object are discussed below. Below is an example of the insertItem service:

    Tutorial:Review of SOA and Web Services for the Web Service Developer Exam-b17-insertitemservice.jpg
    Table: Interface for insertItem Service

    This defines the interface for this particular service. The client using this service to insert a new item must provide an XML message conforming with the input schema shown above. Note that the item id has a zero value, since it is assumed that the server will assign it and return to the client along with a return code. Next we show the findItemById service:
    Tutorial:Review of SOA and Web Services for the Web Service Developer Exam-b17-finditembyid.jpg
    Table: Interface for findItemById Service

    Then we show the updateItem service:
    Tutorial:Review of SOA and Web Services for the Web Service Developer Exam-b17-updateitem.jpg
    Table: Interface for updateItem Service

    Finally we show the deleteItem service:
    Tutorial:Review of SOA and Web Services for the Web Service Developer Exam-b17-deleteitem.jpg
    Table: Interface for deleteItem Service

    The services listed are just one means of expressing the communication protocols that can be adopted. We could have instead shown the input as a message with the service name embedded, along with the item object. The output is composed of a return code and the item object. The syntax for this is shown below for a generic CRUD action:
    Tutorial:Review of SOA and Web Services for the Web Service Developer Exam-b17-genericcrud.jpg
    Table: Interface for Generic CRUD Service

    The downside of this approach is that often there will be partially filled item object with only the id attribute while in the previous services, the findItemById and deleteItem methods would only require the item id attribute to function. In the other two methods, they would need to pass all of the item attributes.

    Other services that could be required would be related to retrieving a set of items based on some criteria. This is shown in the service below:

    Tutorial:Review of SOA and Web Services for the Web Service Developer Exam-b17-genericnoncrud.jpg
    Table: Interface for Generic Non-CRUD Service

    There are a couple of feasible paths for an SOA designer. You have the choice of the communication protocol. This can lead you to Plain Old Xml over HTTP (POX over HTTP), REST or SOAP over HTTP. For POX over HTTP, we need an XML translation library in order to transform the objects from the chosen programming language into XML documents and vice versa. This is all that is required for implementing the services we have outlined. We can also use different languages for implementing the client and the server-side as long as each layer adheres to the defined protocol. The XML document is the key to decoupling parts as shown in the following figure, where a possible scenario is depicted:

    Tutorial:Review of SOA and Web Services for the Web Service Developer Exam-b17-webservicecoupling.jpg
    Figure:Web Service Coupling

    Java Implementation of POX over HTTP

    Next we present an example of how to implement the findById service in the Java language. We use the JAXB library for automatic binding and we will make use of Java Annotations. On the server side service implementation, we used Tomcat 5.5 and the implementation is made from a simple Java Servlet. First, we show the classes that are exchanged between the client and the server: Item, ItemAction, and ItemActionResponse. The are all POJOs (Plain Old Java Object) with a Java annotation that has a key role in the process of XML serialization/deserialization.

    Java Code: XML Binding Annotations
    public class Item { 
       private int id; 
       private String code; 
       private String description; 
       getter/setter methods omitted 
    public class ItemAction{
       private String method; 
       private Item item; 
    public class ItemActionResponse {
       private String retCode 
       private Item item; 
    Next, we show the listing for the service implementation. It is implemented using the doPost() method of a Servlet that is mapped with the url-pattern /itemCrudService in the application descriptor web.xml.

    Java Code: ItemCrudService Server Implementation
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
       JAXBContext jaxbContext = JAXBContext.newInstance 
    			(ItemAction.class, ItemActionResponse.class);
       Unmarshaller unmarshaller = jaxbContext.createUnmarshaller();
       //Receiving the XML request and transform it into a Java object
       ItemAction itemAction = (ItemAction) 
       //Do some action depending on the request content 
       String method = itemAction.getMethod(); 
       //Prepare the response as a Java object 
       ItemActionResponse itemActionResponse = new ItemActionResponse(); 
          int id = itemAction.getItem().getId(); 
          //Retrieve item (e.g. from db)
          Item item = new Item(); 
          item.setCode("Item XYZ"); 
          item.setDescription("Description item XYZ"); 
          //Fill the response 
       Marshaller marshaller = jaxbContext.createMarshaller(); 
       marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE);
       //The following line is not required, it was inserted
       //just to see the content of the generated XML message 
       marshaller.marshal(itemActionResponse, System.out);
       //Send the XML message to the client
       marshaller.marshal( itemActionResponse, response.getOutputStream());
       } catch (JAXBException e){
             throw new ServletException(e);
    Now we have the basic web service, the flow is clear;
    • Deserialize the XML request
    • Do the processing
    • Prepare and serialize the response

    Note that the above service can be invoked using any language or technology that can support the process of XML serialization or deserialization and can use the communication protocol on the client side. Finally the listing for testing the service is below:

    Java Code: ItemCrudService Client Request
    //Prepare the request 
    ItemAction itemAction = new ItemAction(); 
    Item item = new Item(); 
    //Prepare and establish the connection with the service 
    URL url = new URL(""); 
    HttpURLConnection con = (HttpURLConnection) url.openConnection(); 
    //Set the HTTP request method 
    JAXBContext jaxbContext = JAXBContext.newInstance
    					(ItemAction.class, ItemActionResponse.class);
    Marshaller marshaller = jaxbContext.createMarshaller();
    marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE);
    //The following line is not required, it was inserted 
    //just to see the content of the generated XML message 
    marshaller.marshal(itemAction, System.out);
    //Send the XML request to the service
    marshaller.marshal(itemAction, con.getOutputStream());
    //Get the XML response from the service and deserialize it
    Unmarshaller unmarshaller = jaxbContext.createUnmarshaller(); 
    ItemActionResponse itemActionResponse = (ItemActionResponse)
    //Show the response content 
    System.out.println("retCode="+itemActionResponse.getRetCode()+ "\r" +
    	"id="+itemActionResponse.getItem().getId()+ "\r" + 
    The listing shows that on the client side, it is mandatory to have visibility of all the classes involved in the communication process (i.e. Item, ItemAction, and ItemActionResponse). In this case, as Java is being used on both the client and server side for implementation, the classes were copied from the server side into the client project. In general, the only requirement is having objects that fit the serialization or deserialization process.

    Next we use the same approach to implement the findAllItems service. We create another servlet that does not need any arguments and returns a list of items:

    Java Code: findAllItems Service Implementation
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
    try {
          JAXBContext jaxbContext = JAXBContext.newInstance (ItemList.class, Item.class);
          ItemList itemList = new ItemList(); 
          itemList.setList(new ArrayList());
          Item i1 = new Item();
           i1.set ... ; 
           ... populate itemList ...
           Marshaller marshaller = jaxbContext.createMarshaller(); 
           marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE);
           //Just to see the content of the generated XML message 
           marshaller.marshal(itemList, System.out);
           //Send the XML message to the client
           marshaller.marshal(itemList, response.getOutputStream());
       } catch (JAXBException e) {
             throw new ServletException(e);
    Next we also define the ItemList class:

    Java Code: ItemList Binding
    import java.util.List; 
    import javax.xml.bind.annotation.XmlRootElement;
    public class ItemList { 
       private List list; 
    Finally the client for this service will be the following:

    Java Code: findAllItems Service Client Request
       URL url = new URL(""); 
       HttpURLConnection con = (HttpURLConnection) url.openConnection();
       // Void Request
       // Get Response
       JAXBContext jaxbContext = JAXBContext.newInstance (ItemList.class, Item.class);
       Unmarshaller unmarshaller = jaxbContext.createUnmarshaller(); 
       ItemList itemList = (ItemList)unmarshaller.unmarshal(con.getInputStream());
       for (Iterator iterator = itemList.getList().iterator(); iterator.hasNext();)
          Item item = (Item); 
          System.out.println( item.getId()+" - "+ item.getCode()+" - "+
    If you are interested in the implementations using SOAP and REST, please review the articles, “Tutorial:Review of SOAP Web Services for the Web Service Developer Exam” and “Tutorial:Review of REST Web Services for Web Service Developer Exam”. In these articles we look at SOAP both with and without JAX-WS using both Document Literal and RPC as well as detailing the use of REST Web Services.


    We looked at both the guiding principles and characteristics of SOA and looked at the SOA methodology and the basics of web service implementation. We next looked at basic XML over HTTP implementations and detailed how web services can be done with different degrees of complexity and flexibility. OK. That is it for SOA and Web service design. The next article in the series will be on Endpoint Design and Architecture.
    Last edited by Java Exam; 03-21-2012 at 04:23 AM.

Similar Threads

  1. Replies: 0
    Last Post: 03-12-2012, 03:12 PM
  2. Replies: 0
    Last Post: 03-07-2012, 04:37 PM
  3. Replies: 0
    Last Post: 03-07-2012, 04:04 PM
  4. Replies: 0
    Last Post: 02-15-2012, 02:28 PM
  5. Replies: 0
    Last Post: 02-14-2012, 08:21 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts