Web Service Project role

Web Service Project role

Author/OLAF Zimmermann, Frank Mueller

This article describes the different roles involved in Web service development projects, including their respective goals, tasks, and how they work together. This article does not discuss in detail the actual tasks executed (such as creating a document/text style service from WSDL); instead, we try to provide comprehensive guidance to IT personnel with any background, let them know how to think about preparing a web service project. The goal is to help the IT department understand how to better organize their own projects and develop the entire project blueprint.

Web services have been used by a few enthusiasts. At that time, they used immature but highly praised technologies, they strive to achieve everything-or even a simple and insecure exchange of basic data structures. In the last two years, this technology proved its maturity in a large number of practical projects. Therefore, many technical directors now believe that Web services are another powerful component of the enterprise application and software integration toolbox and can be used in large projects in the future. In this way, when the use of web services extends to the "common" enterprise application project in your organization, you may find that you have become a member of the web service project team, even if you have never considered yourself a fan of the above. So what role are you playing now? Let's take a look at what is feasible!

Reason for reading
There are many reasons for you to consider reading this article: if you are a project manager, chief architect, or another technical director in the Organization, you can get some suggestions to guide you how to construct your first web service project and assign people to the project. Our roles and responsibilities can be used in your work breakdown structure ). If you are a Web Service developer, you can learn about the tasks and tools that exist and what important words should be added to your resume, so that your name can appear in the Project Plan of the next web service project closely related to you.
Please note that this is not a common article about group development. Our focus is on specific aspects of Web services. For example, tools and information sources that you cannot find in common J2EE projects and that are assigned to one or more roles.
You may not understand why we decided to write such an article. It seems boring at first glance. To be honest, we also agree to apply technology to solve real business problems, which is very interesting for any project. However, a good structure and method are the key to success, and an unsuccessful project will never have fun, even if it uses the world's most popular technology. Therefore, we believe that your efforts are worthwhile!

Overview: Web Services
Web service solutions and Service-Oriented Architecture (SOA) include service requestor (client) and service provider (server) Implementation, which communicate through soap (XML message transmission. The Web Service Description Language (WSDL) provides the connection between the requester and the provider. Optional service proxies (such as unified description, discovery and integration protocols, univesal description, discovery and integration, and UDDI) may also be required by the Registration Center. Service Description and interaction must be modeled, as is XML schema. In addition, you must design, develop, deploy, and test the implementation. So far, everything is fine. If you have visited the developerworks SOA & Web Services area before, you may say that this is nothing special. The question is: how can the project team achieve these goals?

Project Stage and role
Any development project must go through different stages, and different skills and collaboration are required in its lifecycle. Web services are no exception in this regard. Depending on the methods used in your environment, you may have encountered the following general terms:
L demand Engineering
L Business Domain Analysis
L solution architecture outline
L overview design and detailed design
L Object-Oriented Analysis and Design (OOAD)
L various test phases (such as unit test, integration test, and system)
System testing and acceptance testing)
L Implementation
L Maintenance
L Management

Selection and organization of interoperability tests in some aspects (such as service modeling (such as coarse or fine-grained interfaces), SOAP engine (IBM WebSphere soap, Apache axis, or Apache SOAP 2.3) this is the first consideration of Web Services. The nature of these problems varies. For example, a prerequisite for service modeling is to have different skills and ways of thinking, rather than interoperability testing.
The role metaphor has proved to be very useful in this context, and it makes chaos orderly. The role is related to the project stage. It defines an abstraction layer that separates the job description and execution resources. All project team members have one or more roles. The role model is a common structure in the project management and design methods. The role concept creates a word that is easy to understand and has proved to be a very powerful tool at project startup.
Therefore, let's take a look at this role model in the Web Service Development Project. We divide roles in the model into three categories for representation. Since Web service projects are just another type of development projects, we can see many well-known roles here. We have defined a category for them called existing roles. However, some existing roles assume additional responsibilities related to Web Services, and we classify these roles under extended roles. Finally, some new roles have special responsibilities related to Web services. We classify these roles under additional roles.

Existing roles
Let's start with four roles that you have viewed (or assumed) in the project:
Project Administrator
Responsible for the overall management and leadership of the project team. Define and track the project plan and work breakdown structure.
Business Analyst
Obtain the functional requirements of commercial users and provide the project team with knowledge in related fields. Must understand the business language and have skills in related industries and fields.
Architect
Technical Director of the project. Develop the logic and physical layout (structure) of the entire solution and its components ).
Developers
It is also called the encoding personnel. This role is not required here.
Security Expert
Defines security guidelines (policies) and implements security measures following these security guidelines.
System and database administrators
Install and maintain hardware, operating systems, database systems, and middleware.
Please note that this list is definitely not unique. We could have listed all roles without specific aspects of Web Services, because they are applicable to this category. However, we restrict the list to the most common roles that appear in Web service projects-this article is not a general project method tutorial.

Extended role
The five standard roles receive additional responsibilities in the Web service project. These roles and their new responsibilities are:
Product suppliers
Provides Web service runtime containers that comply with the WS-I as well as optional service registries and soap gateway services.
Deployers
Obtain development components and install them in the target runtime environment. Generate the stubs and skeleton of the target environment from the WSDL and install them together with the Service implementation. Provides JAX-RPC ing and handler configuration through the specific deployment descriptor of the web service.
Tester
Responsible for various standard testing stages, such as unit testing, integration testing, loading testing and acceptance testing. In addition, it defines test cases for Web Service interoperability testing and consistency testing.
Developers
Design and implement specific scripts, generators, and other utilities for the project. Standard levels in the Web service field make it possible to develop custom tools such as understanding WSDL, JAX-RPC, or JSR-109.
Knowledge transfer service provider
Experts and technical guidance on related topics are provided, which will provide extensive knowledge on Web service concepts and implementation resources.

Additional roles
Finally, it is time to define the additional roles that you can see in the Web Service Project:
SOA architect
Design end-to-end service requestor and provider. Inquire and express requests for non-functional services.
Service Modeler
Apply the data and function modeling technology to define the service interface contract, including the schema of the exchanged message.
Process Flow designer
Research explicit and declarative service Orchestration (aggregation and combination) functions. This is an optional role.
Service developers
J2EE developers familiar with Web service concepts and XML. Develop service interfaces, implementation (provider side), and service call code (requester side ).
Interoperability Tester
Verify that developed requestor and provider implementations can be seamlessly interoperable and ensure compliance with Web Service interoperability (WS-I ).
UDDI Administrator
Defines how a common UDDI data model is customized and implanted. This is an optional role.
Please note that the division of extended roles and extra roles is arbitrary to some extent. Both the extended and attached roles come from existing roles (such as SOA architects and service developers ). However, we believe that it is reasonable to introduce a new name for an additional role. From now on, we will only focus on additional roles.
Specific roles of Web Services
Now, let's take a deeper look at the specific roles of Web Services. Figure 1 shows these roles and their tasks.
The following table shows how these roles interact with each other, the skills required for executing these roles, and the tools available to these execution experts:
For tool discussions, we have assumed that J2EE is the selected service implementation platform. If a platform such as Microsoft. NET is involved, you must add other skills and tools in the figure. In addition, we have been deliberately not mentioning the product name until now. As you can imagine, A complete set of tools and runtime support for Web Services can be obtained from IBM and the open source code community. Please refer to the open source project of eclipse and Apache Web services and do not forget to study the technical comments on IBM WebSphere Studio Application Developer and alphaWorks.

Personnel-to-role assignment
Each role is responsible for a different aspect of the entire project. As we have said before, a person can usually wear a few hats. In other words, he can assume multiple roles. If a variety of people with profound knowledge and multi-faceted skills work together, the risk of the project will be reduced. In some cases, only such a group of people with specific purposes will reveal the critical issues of the project and propose reasonable solutions. On the other hand, communication overhead increases with the addition of each new member. There is no single and simple answer to solve the problem of role-to-personnel ing. There are many different opinions and arguments about how to deal with this problem (even the two authors of this article have not reached an agreement !).
We will not continue with these arguments. Now let's look at a small example. Consider the following scenario: we create a company from the insurance industry, which decided to build a new set of mid-office business applications for risk and policy management, this inevitably involves two different backend systems. Both backend systems have been built as J2EE applications-one uses EJB and the other uses only servlet, JSP, and JDBC to connect to its customer and contract database.
In the initial phase of a started development project, the roles defined above are assigned to the team members. In addition to the specific activities of Web Services, you must also determine and assign standard project tasks and roles. Table 2 lists the results of this work breakdown training.
You can see that all the team members except the Project Administrator and Business Analyst are wearing multiple hats. In addition, there is no flow modeling personnel assigned to an additional role at all, because it is not required in this scenario.
At the same time, it should be noted that this example is quite simple; in actual projects, a larger project team is required. Based on our successful experience, we recommend that you set the core group size to 7 to 10. This depends entirely on your scenario. To avoid the complexity of your work breakdown structure, you can break down the project into several stages. In other words, ensure that the project is carried out step by step as planned. This gives the project team members the opportunity to learn this job and reduce project risks. In the flexible development field, this principle is called continuous integration ).
We will not further detail this fictitious insurance example here. In fact, it comes from the book perspectives on web services (see http://www.ibm.com/developerWorks/cn/webservices/ws-roles/#6), which is described as an end-to-end case study and a scenario that will reference implementation in the future. If you want to, you can think of this article as an extension of the book's small Learning Guide-engag-ement perspective.

Conclusion
In all practical application development projects, only the technology can not be successful. Conditions such as a reasonable work breakdown structure, a correct combination of skills, and good teamwork are all key to success. In many cases, they are even more critical than the factors of technical solutions. As Web services are a relatively new technology, there is a lack of recorded experience in this field for reference. Some specific roles of Web Services and other well-known roles from standard development projects assume additional responsibilities.
You may need some additional skills and many appropriate tools to help you. It is necessary to coordinate the allocation of roles to resources, and weigh the advantages and disadvantages between high specialization and related communication overhead. Under no doubt, the "independent action" method does not play any role in important projects. Generally, project management technology must be applied to Web service projects, it is the same as applying it to any other project.
As a member of the IBM Service Organization, over the past two years, we have the opportunity to fully participate in a large number of web service projects. We hope to share our personal experience in these projects with you through this small article.