Lappeenranta University of Technology Faculty of Information Technology Department of Software Engineering
Service Oriented Communications CT30A8901 Seminar document, version 1.0 (03.12.2009)
http://www.jdjhosting.com/images/sun.jpg
&
SERVICE DESIGN
Prepared by:
name : Potyondi, Gyözö Tomppa, Jurvanen
Contents
1 INTRODUCTION TO SOA ...3
2 SUN AND SOA...6
2.1 Emergence of SOA ...6
2.2 SOA readiness ...9
2.3 Sun RQ methodology for SOA implementation...11
2.4 Sun portfolio services for SOA ...12
2.5 Java Composite Application Platform Suite ...14
2.6 Customer case ...17
3 SERVICE DESIGN ...18
3.1 Service-oriented analysis ...19
3.2 Service-oriented design ...19
3.3 Compose SOA ...21
3.3.1 Choose Service layers ...23
3.3.2 Position core standards...24
3.3.3 Choose SOA extensions ...25
4 CONCLUSION...26
1 INTRODUCTION TO SOA
Going back in IT history gives a basic understanding what is SOA and why has it emerged in the 21st century. Massive software systems on mainframes were the first large IT solutions for businesses. Most common applications were introduced for accounting, payroll or inventory purposes. While the software was mainly concentrated on the functions that it provided, the reuse of system elements was largely neglected and impossible. The end-users accessed the systems through terminals. [1]
A new era begun in the 1980ths with the client-server approach which put more emphasis on the needs of single user groups through applications like ERP (Enterprise Resource Planning). PCs replaced the old terminals and were used mostly for presentation purposes. The servers were integral parts of the systems and provided the necessary business functionality. Operating systems of both servers and clients became independent from the hardware and this made it possible to use server functionalities by multiple clients. [1]
Object oriented programming paved the way for multiple tier approaches in the 90ths. Large and complex systems could be divided into smaller parts (as components and objects) which in turn were able to communicate with each other. Object oriented programming approach made reuse of system parts and components possible. These system parts and components communicated with each other through middleware, which made it possible to build large and complex systems. However just like in client-server approach, all parts of the distributed system were tightly connected with each other through middleware, which in turn made integration of large systems cumbersome. [1] The emergence of large systems that need to be interconnected with each other has triggered a need for Service Oriented Architecture (SOA). While old enterprise architectures rarely added significant value to business, SOA provides a more business friendly approach for large enterprises. Rather than representing business logic in an application as in old enterprise architectures, SOA uses an approach where technology is expressed as a chunk of business. In this way businesspeople are able to call for a service without having an understanding how is the service implemented or in what programming
language is it written with. These services can be anything from “customer record” or “check inventory” and an large enterprise may need hundreds of services in its daily operations. Another approach is an event oriented enterprise architecture, which was developed mainly by telecommunication operators and financial services companies. An event contains information which can be vital for the business, such as a stock-out in a warehouse, an exceptionally large charge on a customer’s credit card or when a mobile phone customer has exceeded his or her monthly credit limit. These events are triggered by the enterprise architecture automatically so that the employees in the representative companies can take immediate actions. [2]
Figure 1. Service oriented computing. (Erl, 2007, pp. 41)
A recent Forrester report [6] included the following definition of SOA.
A style of design, deployment, and management of both applications and software infrastructure in which:
• Applications are organized into business units of work (business services) that are (typically) network accessible.
• Service interface definitions are first-class development artifacts, receiving the same degree of design attention (and more) as databases and applications.
• Quality of service (QoS) characteristics (security, transactions, performance, style of service interaction, and so on) are explicitly identified and specified for each service.
• Software infrastructure takes active responsibility for managing service access, execution, and QoS.
• Services and their metadata are catalogued in a repository and discoverable by development tools and management tools.
• Protocols within the architecture are predominantly, but not exclusively, based on industry standards (such as the emerging stack of standards around Simple Object Access Protocol or SOAP).
Forrester notes that, “SOA is as much about software infrastructure design as it is about application design. Beyond simply packaging business logic as services, SOA infrastructure takes on responsibility for running services, leaving application developers more free to focus on business logic. Also, SOAP-based Web services are only one manner of service access — a very important one, but only one nonetheless. Other access paths include message-oriented middleware (MOM), distributed object protocols (such as CORBA-IIOP), and even nontraditional application connection paths such as e-mail.”
2 SUN AND SOA
This document consists of two topics, both related to SOA. Chapter 2 focuses on Sun Microsystems Corporation and how the company is related to SOA through their ideas, concepts and products. We will introduce the company’s approaches in SOA design and implementation, as well as give a short description on what tools and services Sun Microsystems offers for the same purposes. Chapter 3 focuses on designing a service around the topic “group management solution”. We followed a service design process presented by Thomas Erl. The process consisted of six different steps, each described individually in each sub-chapter.
Sun sees SOA as an architectural approach where IT is used to integrate and manage data between new, legacy and packaged programs. Using SOA approach is a critical step to achieve the single customer view. It is a step that lets organization to preserve and reuse all benefits of legacy IT system and develop rapidly new functions and composite applications, which are formed from multiple services. [7]
The composite application platform that Sun developed for SOA is called Sun Java Composite Application Platform suite (Sun Java Caps). Along with application integration it can also be utilized with Web 2.0 projects. Java Caps was developed in september 2006 when Sun Java Enterprise System was merged with an integration applications, which Sun bought from SeeBeyond. [9]
2.1 Emergence of SOA
Now that we have the basic understanding about SOA and what is it about, it’s time to take a look how Sun saw enterprise architectures before and after the emergence of SOA. Keeping in mind that Sun’s view and visions on the matter can not differ fundamentally from the view given in the introduction, we will still go through on Suns views on issues raised in the pre-SOA era, as well on SOA solutions in the present.
The pre-SOA era is the same that was given in the introduction. Sun and it’s clients faced an issue where for example customer data was spread over several legacy systems, different operation systems and databases, storage sub-systems, file formats and the list
just goes on and on. This in turn resulted in strict IT policies and countless point to point integration between different systems. The need to share information has grown in the past decades and the IT infrastructure had difficulties to keep up with the growing challenges due to inadequate middleware structure, increased operational costs and rising customer expectations. [7]
As seen in figure 2, Sun among other enterprise architecture vendors identified phenomena that Sun calls a “silo problem”. The issue with the pre-SOA era IT approaches was that each department within an enterprise was concentrated only on the goals given within the department. This resulted in the situation explained in the previous paragraph. Departments had their own IT infrastructure which served to achieve the goals within the department, but from an enterprise point of view managing IT was an immense task. Let’s take the order status application as an example. Both order processing and account management had to implement the same application to fit it for their own needs within a department. Simply put same things were done multiple times within the enterprise and over time it became obvious that this approach was wasting both company resources and assets. [7]
SOA is not the first go to try to solve the issues raised by the “silo problem”. Data warehouses, portals and business-to-business (B2B) were created to come around these issues but all of them became with a handful of limitations. No general solution was found to simplify the IT architecture within an enterprise. Perhaps the best solution before SOA was Enterprise Application Integration (EAI) which made it possible to integrate different information systems. However the weakness of EAI is that the enterprise can not integrate business logic with EAI. This is where SOA stands out compared to the B2B, EAI, portal and other solutions, understanding business logic is fundamental in a SOA approach.
Figure 2. Enterprise architectures before SOA. (http://www.sun.com/products/soa/benefits.jsp)
The SOA approach takes into account both technological aspects of data integrating and the requirements for business processes, and it is a critical step towards a single customer view. A single customer view enables the enterprise to preserve existing IT assets while allowing to develop new functionality in composite applications. New application development is also accelerated by re-using already existing applications. Loosely coupled applications that rely on industry standards drive also flexibility, agility and re-usability. The development of these applications is process-centric based on SOA principles. It separates the business logic from the application logic, which makes it possible to make changes the either business or application logic so that the changes do not affect on the other. [7]
Let’s go back to our example with the order status application and look how it is done with SOA. In SOA the order status application is implemented only once in the whole enterprise. Departments that need to use the query are using the same application (service). In addition composite applications are possible by connecting several applications into one group then represent this group of applications as single application.
For example check order status application can consists of check credit and check inventory applications. Composite application approach is presented in figure 3. In this way only one application is called, rather than two separate applications like in the pre-SOA era. Naturally this makes business operations a lot easier for enterprise employees.
Figure 3. Enterprise architectures after SOA. (http://www.sun.com/products/soa/benefits.jsp)
2.2 SOA readiness
SOA readiness can be described as a process for achieving the best results in many areas. Figure 4 shows how SUN is approaching to determinate SOA readiness. Organizations have usually many different levels to SOA readiness in every of these areas below.
Figure 4. SOA readiness
People
To achieve the best results in SOA developing it is needed to have good expertise and knowledge. Therefore it is important to understand what kind of leadership, knowledge and skills are needed in SOA project. If a project team or IT-organization is not experienced with SOA projects, there is a risk of project delays, or the results achieved are not as good as they could have been.
Achieving all possible benefits of SOA, SUN recommends using SOA project experts outside from company and training the people in company to SOA, because often people don’t have the skills and knowledge of requirements for SOA project, like:
- designing SOA applications
- implementing service centric application components - building composite applications from components - integrating legacy applications to SOA environment Processes
The most important processes in SOA infrastructure are: - business process
- business services - infrastructure services - domain architecture
By evaluating the processes there can be pointed which IT service areas are not in line with business goals or in which business the processes performance is limited. Accurate evaluation of present situation helps to prioritize and design the enhancements of the processes with SOA solutions. Therefore evaluation can enhance every discipline and achieve better results in SOA project.
Practice readiness
Practice readiness means the best practices that are centered to implementing and designing SOA project, which will speed up SOA deployment. For being prepared of deploying SOA, the IT organization must focus to certain matters:
- adopting SOA strategy and methodology
- define how managing and developing SOA solutions is performed - make an initialization plan and strategy for SOA governance - is the project management staff skilled to SOA
SUN recommends using consults or other experts outside from company for achieving the greatest results with SOA project.
Platform
There are many different SOA platforms on the markets. Platform provides the infrastructure for developing, managing and deploying SOA solution. Platform includes for example software tools, efficiency optimizing, hardware implementation and tools for building composite applications.
After assessing the organizations SOA readiness in all four disciplines described in the previous chapter, the next step is to determine the methodology to implement SOA. Sun has developed the RQ methodology for building pragmatic and flexible SOA solutions for its customers. The RQ methodology takes an iterative and incremental approach to discover, enable and realize an SOA within the organization. In addition Sun has also created a set of Unified Modeling Language (UML) compliant artifacts and templates that accompany the methodology and also help to guide SOA implementation. The aim of RQ methodology is to unify the views on SOA between different departments in the organization through structured techniques and collaborative workshops. The aim is to identify, define and document SOA drivers in the organization and use a top-down business driven approach to SOA. The SOA reductive analysis uses broad use cases through which organizations can identify, define and design granular services. Once those fine-grained services are ready, those can be gathered into coarser-grained business services. [4] In this perspective, implementing SOA with Sun can be a lengthy and costly process. The iterative approach and top-down methodology leads to a process where a lot of emphasis is put on designing and understanding the business logic within the organization. Once complete, Suns approach gives the organization high quality service architecture with maximum reusability and adaptability. [7]
2.4 Sun portfolio services for SOA
Sun offers a wide portfolio of services illustrated in figure 5, which covers whole SOA project lifecycle from design to architecture and from integration to management.
Figure 5. Sun portfolio of services
Portfolio is designed to fulfil the needs of customers despite of what level they are in their SOA maturity. Customers may start from any stage, for example from evaluate or architecture. If customers have already implemented SOA projects, they can start with Sun SOA Enterprise HealthCheck what is used to survey their SOA implementions. [7]
• Evaluate stage - Sun offers their customers help and workmanship with designing their SOA processes and platform, and SOA readiness across people, process, practise and platform. Sun consults assist companys IT staff designing IT operations and guides them with SOA solutions. Sun also can perform the training for personnel to SOA products.
• Architect stage - Designing and architecturing SOA environment is one of the most critical steps in SOA projects, because it has a great effect in later phases. Sun offers help and consulting to their clients in deployment of SOA projects. Architect stage includes also SOA governance.
• Integrate stage - In integrate stage SOA solutions are implemented and fine-tuned for use. Auditing is also performed in this phase. Sun offers Sun Interim Operations Management services for helping customers in transition to the new solutions or o new production environment.
• Manage stage - This is the last stage of SOA implementation, where SOA solutions will be taken into use and under manage. Sun Managed Services helps customers onsite managing SOA services side by side with companys own IT staff. Sun Management Services combines ITIL based practises with standardized processes, tools, and with latest technology.
2.5 Java Composite Application Platform Suite
Sun has a complete range of both hardware and software products for enterprises SOA needs, such as Sun Fire servers, StorageTek storage solutions and the Solaris operation system. In addition, Sun also offers infrastructure software solutions which are part of the SOA infrastructure.
• Java Enterprise System – A set of subscription based services that combine software, support, professional services and educational services in a package for a fixed price.
• Java System Integrity Manager – Identity management solution including role-based access controls, automated provisioning of user profiles and auditing of user history.
• Java Composite Application Platform Suite (Java CAPS) – SOA software platform combined with business integration with a suite of composite application development tools.
The Java CAPS software offers everything an enterprise needs to develop, deploy, manage and monitor a SOA platform. It can combine the functionality of existing legacy applications with newly developed, reusable services, as well as extract the business logic from the same legacy applications to be modified by business owners. Based on standard collaboration and business process execution, it delivers end-to-end graphical tools that deliver optimized source code. The developers may either operate on the graphical interface or directly on the source code, depending on their own preferences.
The figure 6 illustrates the core functional areas of Java CAPS. We will give a short explanation of these core areas below.
• Service access - The presentation layer provides a transparent access to multiple device types and simplifies the task of integrating Web services to a enterprise portal environment.
• Service composition – Provides the necessary tools for composing web pages with user interface. Includes also a development environment for building reusable software components based on web services standards.
• Service orchestration – For assembling composite applications that can be used to create new services supporting business processes.
• Service integration – Legacy or packed applications are integrated to SOA by using service integration tools and pre-built adapters for most common enterprise applications.
• Enterprise service bus – Provides integration services for connectivity, transformation and routing.
Java CAPS comes with a lot of benefits for deploying, managing and monitoring a SOA platform. Java CAPS is integrated into a single software system which is released on a regular basis. It brings cost savings through increased interoperability between components and also reduced risk of incompatibilities due to irregular release schedules. Java CAPS promotes also zero coding. As mentioned earlier, the developer is free to choose between a graphical tool and the coding tool. All of the artifacts are automatically exposed as web services in a common registry. Java CAPS is based on a single IDE (like Netbeans) which makes it possible for both developers and business analysts to utilize the same IDE. [7] Being an open source project through Open ESB, Sun tries to take the the benefits of open collaboration between it’s own engineers and the open source community. [8]
Even though the Netbeans IDE is free, the Java CAPS is not a free tool. While there is no direct access to a trial version of Java CAPS, in case of obtaining a copy of Java CAPS one needs to contact Sun directly. Regarding this course, the Java CAPS tool would have been an interesting tool to try for SOA services development. In case of an free tool for future course purposes, one option would be using using Netbeans with Open ESB.
2.6 Customer case
Large rapidly growing media and entertainment providers IT solutions became overloaded and company asked Sun to design and provide SOA based high-performance solution, which is based on Sun’s Java CAPS. Their old IT system served customers through many cross working channels that made serving complicated. Solution became also quite hard to manage and was also underpowered for future needs. Furthermore their IT services were outsourced to third party company. Requirements for new SOA based solution were for example scalability, flexibility, handling several million transactions in a day and more in future, improving data visibility and quality of services.
Sun provided to customer Java CAPS based SOA system that fulfilled the needs of rapidly growing markets. Solution was implemented using Web service layers and many architectural layers. Total of 120 services was needed, including for example common service layer with reusable core services. Sun’s experts were involved in project from architectural stage to implementation stage and support. Sun didn’t only help building a quality SOA environment in short time, but also transferred knowledge and skills to company’s IT organization.
The customer chose Sun because of their skills and expertise on SOA environments and Java CAPS. By utilizing skills and knowledge from Sun reduced project risks and accelerated the schedule of project. As a result they gained many benefits, like highly flexible and scalable environment that will answer also to growing future needs.
3 SERVICE DESIGN
The service design pattern we followed to form our service was from Thomas Erl. In his book Service-Oriented Architecture – Concepts, Technology and Design he gives the following pattern to compose a preliminary SOA (as seen in figure 7). With this top-down approach, we composed a basic service for university purposes. In the following chapters we describe what we have done in each step in Erls service design pattern. At times, we went backwards from a step to re-design and further improve our service, just like it is meant to be done in the top-down approach. [5]
The topic given for the service design was “group management solution”. Also the following description was given on the course pages:
Seminar groups design a similar service based on the design process and analyze the solution based on service design principles (remember that this is NOT implementation but design exercise).
3.1 Service-oriented analysis
We began to gather ideas for a possible group management services. Since the university environment contains a lot of groups, both in courses offered by the university as well as in free time activities, we began to think about a service that benefits the everyday university life. We decided to orientate in groups (referred as workgroups from now on) that are formed within a university course. These groups are usually formed to write cases, assignments and carry out projects and exercises together. However, the tools that these workgroups can use to co-ordinate their schedules and data are rather limited. The tools that university offers for workgroups for these purposes are rather limited. Blackboard is used only by a few faculties for example. The IT department has its own wiki-pages, but it is rather cumbersome to use, especially for students that have limited IT skills. Some students have used services offered by Google, such as Google documents and Google calendar. However, not every student has a Gmail account to add and modify documents or calendar events. Services offered by Google aren’t connected to the university either, making it impossible to use it as an official tool in university courses
3.2 Service-oriented design
We decided to offer a wide range of services for groups that are attending to university course. The main idea of the services is help to gather groups for composing course for example practise works and assignments, and offer an easy-of-use platform where to store them. Basically the application could be described as a combination of Noppa portal, Blackboard Learning System, Tite learning Wiki and Google Docs. The application is called as “Shakespeare “ from this on.
The main services in the application are: - composing the groups from students - data storage
- course data management - calendar and notification
Composing a group goes as followed: One person (a student) is needed to form and create a group. The person who creates the group becomes a group leader, who is authorized to invite members to the group by sending an e-mail invitation via application. When someone receives an invitation, he has to accept it by clicking the link presented in e-mail. After accepting the membership he becomes a group member. If the group is wanted to be dismissed, it can be done by with majority decision, which is 65%. The “Shakespeare” administrator or the teacher of the course where the group is linked to, can also dismiss the group or manage group forming.
Data storage, a database, is used to store all the data that is involved to use of “Shakespeare” application. Information includes for example all course data and group information from course data management service. All the data is processed and stored in XML form.
Calendar service as well as course data management service works with co-operation of Noppa portal, where course timetables are stored and presented. All lecture and exam times are transferred to “Shakespeare’s” calendar. There is also a notification service integrated in calendar that informs students for upcoming events, like exams, by sending e-mail messages. It has also a special “watch-dog” function, which keeps track of members in groups and calculates their work loads. If it finds a member who does not seem to collaborate enough with other group members, it sends a supportive “WARNING –PLEASE PARTICIPATE OR BE DISMISSED FROM THE COURSE!” or similar friendly message to the person e-mailbox.
Secondary services are a bulleting board system and a chat application, where group members can be in contact with each other, other groups, and with teachers as well.
Teachers have also their own “administrative” tools, for example going through and evaluating group works within the application and print or store the results.
3.3 Compose SOA
We have considered to design following composite applications and reusable services that are illustrated in figure 8.
Figure 8. Diagram of composing SOA applications
For example the “User management” -application is used for adding users to group or deleting users from group and it uses “Shakespeare’s” database for storing data. Composed process tree for adding a user goes as accorded in figure 9. Other composite applications work with similar pattern and are based of using reusable services.
Figure 9. Process tree of adding a user
As illustrated earlier in figure 8 the “user management” application is used when for example a group manager is adding a new user to the group. It is performed by adding a user and group information to the application database.
“Shakespeare” application uses reusable services in the process. At first a database connection is opened with “DB connection” -service. Once the connection has been performed, the “add user” –service adds the new user with other necessary information to the database. After adding a user the “Shakespere” application will be synchronized with the updated database, and finally the database connection will be closed. If the process of adding user is unsuccessful for reason or other, there is no need to synchronize database and the “synchronize db” -service will be skipped with a possible error displayed.
The data that is shared between different data repositories is presented in XML form. Designing the data flows between “Shakespeare” application database and other databases is quite straightforward, because both Noppa portal and Oodi shares data in XML form. Data flows are illustrated in figure 10.
Figure 10. “Shakespeare” data flows
“Shakespeare” uses Noppa for gathering course content, lecture and practise events and other data. Oodi is used to gather the exact course timetables and the dates for exams.
3.3.1 Choose Service layers
We continued following Erl’s guidelines for composing a preliminary SOA as represented in chapter 3 introduction. At this stage, Erl recommends to take a look into these issues when choosing service layers [5]:
• Existing configurations • Required standards
• Service composition performance • Service versioning
Existing configurations means that new services should follow the already standardized services within the organization. In our case we found out that XML data representation is used between Noppa and Oodi. [OODI] Thus, we decided to represent all data flow within our service design as XML data as well. This also ensures that our services remain re-usable for future projects too. By choosing a XML data representation we also answer the second point in our list. Service composition performance addresses issues considering service robustness and usability performance. Since we are purely designing a service, we can not test ourselves the performance of our system. We also rely on the university to provide an environment with enterprise processors and accelerators. With service versioning it is important to ensure that future service requestors could possibly rely on our services. Upon deploying a service, further extensions may be required to complete service’s expected feature set. If these extensions result in changes to the initial interfaces we designed, then the versioning system needs to be up to date to accommodate our solution and any other possible requestors that are using our services. As we do not know if our services will be useful for other organizations or individuals, we decide to carry out a simple versioning for our services. At this point this is a decision that will come into practice when the actual implementation part is done, as currently we are only focusing on designing our system and services [5]
3.3.2 Position core standards
In the previous chapter we already mentioned one standard we planned to use, the use of XML for data representation. However the use of XML is not enough because SOA is associated with many other standards like WSDL, UDDI, SOAP and so on. To ease the workload on finding out what standards to use in which situation, we decided to rely on WS-I basic profile 1.1. The WS-I basic profile is a set of standards to ensure best practices for web services interoperability, for selected groups of web services standards, across platforms, operating systems and programming languages. [WS-I] In the WS-I basic profile 1.1 the following standards are included:
SOAP 1.1 UDDI 2.0 XML 1.0
XML Schema 1.0
WSDL is used to describe the services that our system offers. SOAP is used to execute messages within our system. UDDI promotes an industry standard for organizing service description pointers to accommodate the process of discovery through service registries. Since our system is focused on the local university and it’s students here in Lappeenranta, UDDI doesn’t represent a core standard in our system. XML Schema offers data integrity throughout our system.
3.3.3 Choose SOA extensions
At the last stage of our service design, we decided to include WS-BPEL standard. It is used to orchestrate the services in the right order, required by the application logic. For example in our case course data management application uses services like DB connection, DB synchronization, modify data and store data. WS-BPEL takes care that these services are synchronized and work according to the application logic defined for course data management.
4 CONCLUSION
This paper had two goals. First goal was to introduce Sun Microsystems products and views on SOA. We represented Suns ideology on designing and implementing SOA as well as different tools and ready tailored solutions that Sun offers to it's clients. The second goal was to describe and document a service design using Erls approach on the topic “group management solution”. Using top-down approach, we described all the steps taken in the design process.
Essential findings were found in both sections of this document. Along with lectures and Erls books, the part concerning Sun further deepened our understanding about SOA. Not only it gave basic knowledge in SOA, but also gave us useful hints how to design a service. In service design, the top-down approach made us to go back and forth between different steps in Erls SOA approach. The most time consuming step during the service design was coming up with a service within the topic given. In Erls approach this step is called service oriented analysis. We had to think hard how our service would further improve the options given for workgroups to organize and share data for university course purposes. The second most time consuming steps were drawing up applications and services that those applications use. No major issues were encountered during the service design. The only setback was lack of time given for service design.
REFERENCES
[1] Paoli, H. Holtmann, C. Stathel, S. Zeitnitz, O. Jakobi, M. SOA in the Financial Industry – Technology Impact in Companies’ Practice. p. 1 [e-document] Available at:
http://www.springerlink.com/content/q844784200575p43/fulltext.pdf [accessed 25.11.2009] [2] Minoli, D. Enterprise Architecture A to Z: Frameworks, Business Process Modeling, SOA, and Infrastructure Technology. p. 20. [e-document] Available at:
http://www.engnetbase.com//books/7120/AU8517_c001.pdf#xml=http://www.engnetbase.c
om/ejournals/search/searchquery.asp?cmd=pdfhits&DocId=23381&Index=\\usmia-fs01\SearchIndices\Applications\1&HitCount=12&hits=1428+1da8+1fef+209d+209e+26ed +2770+27b1+2f91+2fd3+31c4+32d7+&indexParentId=1&hc=2261&req=SOA [accessed 24.11.2009]
[3] Erl, T. SOA: Principles of Service Design. Prentice Hall, 2007. United States. [4] Sun Microsystems, white paper. Sun solutions and services for adopting a service-oriented architechture. [e-document] Available at:
http://www.sun.com/service/soa/soawhitepaper.pdf [accessed 03.12.2009]
[5] Erl, T. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall, 2005..
[6] Randy Heffner, ‘Your Strategic SOA Platform Vision,’ Forrester Report, March 29, 2005 [7] Sun Microsystems, white paper. Achieving a single customer view. [e-document]
Available at: http://www.sun.com/software/whitepapers/soa/soa_single_customer.pdf
[accessed 04.12.2009]
[8] Sun Microsystems, white paper. Sun Java Composite Application Platform Suite. [e-document] Available at:
http://www.sun.com/software/javaenterprisesystem/javacaps/caps_ds.pdf [accessed 05.12.2009]
[9] Digitoday.fi, Sun syöksyy SOA-kehitykseen. Available at:
http://m.digitoday.fi/?page=showSingleNews&newsID=20066668 [accessed 08.12.2009] [OODI] Hallantie, H. Noppa-portaalin esittely. Available at:
https://www.jyu.fi/erillis/thk/itpeda/foorumi/noppa/ [accessed 8.12.2009]
[WS-I] WS-I. About WS-I Available at: http://www.ws-i.org/about/Default.aspx [accessed 06.12.2009]
