There are two common  techniques to develop a web service:

1. Code-first
2. Contract-first

Most developers start by writing the service implementation in code and then have a toolkit to produce the WSDL. This approach is called code-first development. Code-first is more common today. This is because working directly with WSDL is extremely difficult. We lack proper tool support to work directly with WSDL and hence code-first is more pleasant. In this technique the developer first codes the logic of how the data is treated within his service. Then he produces the WSDL in an automated way using a toolkit. The WSDL thus produced contains language-specific types. When the business partner wants to interact with the service contract, he realizes that his application doesn’t map nicely to the service contract coded by the developer as it contains language-specific types and he starts looking elsewhere for the service. The key principle of Service Oriented Architecture is to ensure ease-to-consume a contract. The Code-first approach is technology independent and lacks ease-of use.

 The fundamental goal of the Contract-first model is to facilitate interoperability. The reach of a web service is unlimited. Embracing this new model of contract-first ensures happier partners. In this approach, the developer first codes the standard contracts that will be shared with the partners. Here the developer focuses on how the data is moved across service boundaries rather than within the service. He invests a lot of time and energy in contract design. He first codes the XML Schema and WSDL definitions. After everyone agrees on WSDL he implements the code. This approach embraces service orientation and is disconnected from how you treat data within a service. It is focused on connecting the dots within a distributed system as a whole. Ease-of use of the service is under the control of contract definition. The Contract definition is a shared language which is the primary focus of this model. This approach ensures that the service designed is interoperable across a wide range of platforms, operating systems and programming languages. It helps partner collaboration and meets the enterprise goals.

Web services can be created using two methods: top-down development and bottom-up development. Top-down web services development involves creating a web service from a WSDL file. By creating the WSDL file first you will ultimately have more control over the web service. When creating a web service using a top-down approach, first you design the implementation of the web service by creating a WSDL file.When creating a web service using a bottom-up approach, first you create a Java bean or EJB bean and then use the web services wizard to create the WSDL file and Web service.

Should a top-down, business-centric approach be employed or a bottom-up approach, in which the Business Unit (BU) is more reactive and sensitive to the realities of IT?

The Model-Driven Architecture (MDA) provides an approach aimed at achieving technology independency through full top-down development. In top-down approach the WSDL is designed from a business point of view and is not driven by a service consumer or an existing application. The “WSDL to Java” tool generates java code according to JAX-RPC or JAX-WS. These classes can then adapt the existing business logic.

Although bottom-up Web service development may be faster and easier, especially if you are new to Web services, the top-down approach is the recommended way of creating a Web service. The bottom up approach does generate web services which design is driven from an application point of view (developer driven) and will not address the need for other consumers.

Heterogeneous Namespace Design

1. Give each schema a different targetNamespace
2. If required to re-use another schema in the current schema we need to import it

Benefits
1. Maximise the re-use of the types with separate namespaces
2. Namespace mapped to domain specific service
3. It would be easier to model all the domain-specific types in separate files with individual namespaces
4. Easier to understand
Drawbacks
1. There will be a large number of namespaces to manage
2. There will be a large number of namespaces to import
3. The granularity of the types in import would depend on the types defined and exposed in a particular domain-specific XSD

Homogenous Namespace Design

1. Give all schemas the same targetNamespace
2. As the schemas have the same targetNamespace, the method of accessing components is “include”.

Benefits
1. No need to either import a service or schemas
Drawbacks
1. Need to handle Name collisions
2. Generate code in a single Java package, for a service
3. chances for redundant types
4. does not allow for domain-specific namespaces

Chameleon Namespace Design

Give the main schema a targetNamespace and give no targetNamespace to the supporting schemas. The no-namespace schemas will take-on the targetNamepspace of the main schema.

Benefits
1. In this scheme, schemas are able to blend in with the main schemas that use them
2. Ability to provide application-specific namespace to the schema
Drawbacks
If the schema <include>s multiple no-namespace schemas then there will be a chance of name collisions. In fact, the schema may end up not being able to use some of the no-namespace schemas because their use results in name collisions with other Chameleon components

The most widely used schema design approach is heterogeneous schema design approach. Let me illustrate this with an example.

Step1: Create a schema file named Books.xsd to store book information with targetNamespace declared as tns:Books as shown in the below code snippet:

Step2: Create another schema file Sales.xsd to store the sales information with targetNamespace declared as tns:Sales as shown in the below code snippet:

Step3: Import the two schema files in Catalog.xsd file using the Heterogeneous namespace design approach as shown in the below code snippet:

Web services are units of programmable application logic located on web servers that can be accessed remotely using standard internet protocols and data formats such as XML, HTTP and SOAP.

Web services are platform-independent and language-independent, since they use standard XML languages. This means that my client program can be programmed in C++ and running under Windows, while the Web Service is programmed in Java and running under Linux.

Web Services are published, found, and used through the Web. The basic Web services platform is XML + HTTP.

Web services platform elements are:

• SOAP (Simple Object Access Protocol)
• UDDI (Universal Description, Discovery and Integration)
• WSDL (Web Services Description Language)

Introduction to XML

XML is the universal format for data interchange.  It is supported by all major operating systems, programming languages and development platforms.  It is the standard platform for building interoperable distributed applications. 

The ability to invoke cross platform communications makes the reach of XML Technology unlimited and its use in Web Services compelling.

Web Services are the building blocks for constructing distributed Web-based applications. They are units of programmable application logic located on web servers that can be accessed remotely using standard internet protocols and data formats such as XML, HTTP and SOAP. Web services use XML-based messaging to send and receive data, which enables heterogeneous applications to interoperate with each other.

Basic concepts of XML

 XML represents structured content rather than visual display. A well-formed XML document contains an end tag for every begin tag. Well-formed XML documents can be modeled as trees. The tree has a single root node containing one or more child nodes. A node without a child is called leaf node. XML Document Object Model (XML DOM) is required to work with XML data.

Document Object Model (DOM) 

Document Object Model (DOM) is a representation of the XML document in memory.  It is used to read, write, and manipulate an XML document. DOM loads the entire XML document into memory.

Simple API for XML (SAX) 

Simple API for XML (SAX) is used to read data from XML documents. SAX parser reads the contents sequentially and generates events as it reads the XML document.  It does not load the entire XML document into memory. SAX is good for reading large XML Documents.

Limitations of SAX:  SAX does not maintain any data structures that are required to perform complex searches. They cannot be used to modify the XML document.

Document Type Definition (DTD)

Document Type Definitions (DTD) outlines elements, attributes & relationships allowed in an XML document. DTDs are written in their own syntax rather than XML syntax.

XML Schema Document (XSD)

XML Schema Documents describe and validate the structure of XML documents.  They restrict the value of elements and attributes in an XML document. They are written in XML syntax. An XML document that adheres to XML schema is called Valid XML document. The XML Schema documents have suffix xsd.

xs:unique and xs:ID

The xs:unique element and the xs:ID datatype ensure that the pieces of data in an XML document are unique

XML Schema Exercise:

1. Create a Cart element. Each Cart element must have multiple instances of child Category element

2. Category element can have multiple instances of child Book and Sales element n

3. Each Book element must have a BookNumber attribute whose value is unique within Category.

4. Each Sales must have an ID attribute whose value matches one of these unique BookNumbers

xs:selector and xs:field

The identity constraint “keyBookNumber” does not allow the incoming xml files to have duplicate values for book number.

xs:selector: The context in which the primary key constraint should be applied

xs:field: The field that uniquely identifies the record

After applying the primary key constraint xs:key the XML Schema Document will look like this:

Now lets see the relationship between the book and sales records. As per the exercise  ” each Sales must have an ID attribute whose value matches one of these unique BookNumbers”

Sales ID attribute must match anyone of the unique BookNumber attribute of Book. Use xs:keyref to create this relationship.

OPM3 considers that project management consists of 3 layers; wherein maturity should be improved continuously throughout the stages of standardization, measurement, control and improvement. OPM3 provides organizations with an assessment tool to evaluate their maturity in each of these 3 layers and to develop improvement plans aligned with the best practices and organizational strategy. OPM3 provides an objective basis upon which organizations can assess their maturity on a continuous scale of 0 to 100%, based on a standard developed and accepted globally by the Project Management community.

OPM3 Model

Credit:Rubrik Wissen

Some techniques to develop improvement plans:

1. Metrics reveal the health of a project. The devil is in the details. Tracking metrics can help identify process gaps and develop improvement plans. Some examples of metrics that can be tracked in a project are as below:

• Effort variance: tasks planned versus actual and hours planned versus actual
• Defect Backlog: Shows new and open defects by severity, functionality group and release
• Customer weighted requirements prioritization matrix
• Bugs triage: Prioritize bugs according to customer impact and complexity of the fix

2. Enable communication between the Project team and Auditors where cross-pollination of ideas can take place.

3. Document best practices and lessons learned

Hard indicators are facts that can be measured directly, whereas soft indicators are less tangible conditions that must be measured indirectly. The time it takes to execute a task or how much it costs are typical hard indicators. Quality, expressed as customer satisfaction of needs, is one example of typical soft indicator. Hard indicators are by far more widely used; soft indicators are seen by many as being so inaccurate that they are rarely useful. As Deming (1986) stated, the most important numbers are often unknown. Management by numbers is one of the deadly diseases that have ruined many enterprises. Planning for the unknown or the importance of a detailed upfront scoping process is one of the major critical success factors for a project.

The success of any software project largely depends on effective estimation of project effort, time, and cost. Estimation helps in setting realistic targets for completing a project. The most important estimation that is required to be fairly accurate is that of effort and schedule. This enables you to obtain a reasonable idea of the project cost. If the team starts fully aware of the likely reasons schedules fall apart and takes some actions to minimize those risks, the schedule can become a more useful and accurate tool in the DEV process.

Schedules are a kind of prediction.  Good schedules come only from a team that relentlessly pursues and achieves good judgment. There is no magic formula or science for creating perfect schedules. Schedules don’t have to be perfect. Schedules need to be good enough for the team to believe in, provide a basis for tracking and making adjustments, and have a probability of success that satisfies the client, the business or the overall project sponsor. Good work estimates have a high probability of being accurate.

Good estimates come from good designs

Good engineering estimates are possible only if you have two things: good information and good engineers. If the spec are crap, and a programmer is asked to conjure up a number based on an incomprehensible whiteboard scribbling, everyone should know exactly what they are getting – a fuzzy scribble of an estimate.

There are known techniques for making better estimates. The most well-known technique is PERT, which tries to minimize risks by averaging out high, medium and low estimates. This is good for two reasons. First, it forces everyone to realize estimates are predictions, and that there is a range of possible outcomes. Second, it gives project management a chance to throttle how aggressive or conservative the schedules are.