Test and Analysis of Web Services

Product Description

The service-oriented approach has become more and more popular, now allowing highly integrated and yet heterogeneous applications. Web services are the natural evolution of conventional middleware technologies to support Web-based and enterprise-level integration.

The highly dynamic characteristics of service-oriented applications means their validation is a continuous process that often runs in parallel with execution. It is not possible to clearly distinguish between the predeployment validation of a system and its use, nor is it possible to guarantee that the checks passed at a certain time will be passed at a later time and in the actual execution environment as well.

Baresi and Di Nitto have put together the first reference on all aspects of testing and validating service-oriented architectures, taking into account these inherent intricacies. The contributions by leading academic and industrial research groups are structured into four parts on: static analysis to acquire insight into how the system is supposed to work; testing techniques to sample its actual behavior; monitoring to probe its operational performance; and nonfunctional requirements like reliability and trust.

This monograph is an initial source of knowledge for researchers in both academia and industry in the field of service-oriented architecture validation and verification approaches. They will find a comprehensive survey of state-of-the-art approaches as well as techniques and tools to improve the quality of service-oriented applications.

Test and Analysis of Web Services

Latest SOA Need: Assistance with JBI Application Integration

The methodology of Enterprise Integration has advanced to Service Oriented Architecture (SOA) because of its ability to weave disparate applications and services to produce a business structure where data can flow as a business process. Environments have been built over time with diverse layers of applications. The development time and maintenance cost to manage these layers is driven down when integration components are built on standards. The most compelling standard in the integration space is Java Business Integration (JBI) which allows for the creation of a Service Oriented Architecture with interchangeable components that are vendor-independent.

Isn’t all development easier with a standard?

Not really. Don’t confuse the ease of using the standardized run-time components with the creation of those run-times. The creation of JBI run-time components is a whole new technology, with layered naming conventions and rules for each binding and service engine components. As with any new technology, JBI brings with it a sizable learning curve.

Plan time to learn JBI technology

Developers interested in JBI will need to reserve some time to learn. This type of exposure is mostly reviewing code snippets from existing open source JBI applications, like ServiceMix, and supplementing that learn-as-you-explore strategy with the 228 page JBI specification document publicly available from the Java Community Process organization. SOA integration experts, like Scott Ganyo with Moongate Technologies, agree that it can take a long time to learn the rules of the JBI spec nomenclature and nuances to code within the standard. While it is not brain surgery, even an experienced integration developer will need to devote targeted time to get up to speed.

The Holy Grail of Simplified Integration

So here is the hitch. Everybody is focused on SOA, and the push-point of that statement is everybody is everybody, from code crunchers to web designers.

The use of standards, like JBI, simplifies the combining of components but it is the ability to make those high-learning-curve standards accessible to all levels of coders that is the Holy Grail enterprises will be striving to acquire.

Less sophisticated audiences, one proven method

It is an early adopter assumption to think everyone using your product knows what they are doing. The first implementers of any new technology will cater to the most sophisticated users. But the SOA audience is as varied as the many applications they are trying to integrate, so this market will need a splay of products to cover different levels of expertise. A graphical interface, as we have seen successfully implemented in workflow and business process applications, is a proven method to simplify the design and implementation process. Just as BPEL maps out high-level business processes as a workflow, an intuitive graphical interface for the lower level integrations has a definite market for a technical user that wants to keep their distance from the detail specifications and simply drag and drop functionality.

Graphical Interfaces hide mundane details from developers

If vendors create graphical interfaces that generate standards-based code under the covers, a developer can avoid understanding the intimate details of the specification while still enjoying the benefits of developing a standards-based integration. A robust graphical interface allows each SOA developer to visualize the integration path and then simply click to define the properties in a fill-in-the-blank format. This expands the standards-based playing field to include a broader base of developers. The true beauty of the interface is to ultimately create standards based code so that the resulting run-time components integrate easily with other internally and externally developed components.

Graphical Interfaces are not always a priority

It is a certainty that more organizations will eventually go the graphical direction. First vendors develop the functionality and then they make it easier to reuse. While a couple of vendors have already started down a user-centric graphical path, an across-the-board improvement to robust graphical interfaces for integration will take a year or more.

The Soa Iceage

‘Oh, no!’ you might think. ‘Another one who wants to shove SOA as a means for corporate agility down my throat …’.

Relax, nothing could be more wrong. In short, I am certain that SOA does not improve corporate agility, rather the opposite. The problem is that SOA represent a prevailing vision in the eloquent diction of Thomas Sowell’s book ‘The Vision of the Annointed’. A prevailing vision automatically provides a status of higher intelligence to its proponents without the need for empirical proof or more detailed analysis. Opponents simply have non-disclosed darker motives.

Service-Oriented Architecture (SOA) was first proposed by Gartner Group in 1996 in a SSA Research Document as a logical evolution of losely coupled, object-oriented messaging interfaces. But many paths lead to Rome. For example, in 2000 Papyrus WebRepository as enhanced with a freely definable service adapter for HTTP and FTP and in 2001 with MQ-Series. In the following years Papyrus’ adapters were provided to support the most common messaging formats including SOAP and WSDL. Because Papyrus WebRepository is by design a state/event driven process engine with definable user front end, and it therefore provides the SOA core function – to create agile business services linked to encapsulated external services – since 2000.

Ok, interfaces are an important IT subject, but is it enough to invest in SOA? I am asking: „What can SOA do for the user?“ The answer of the SOA visionaries: “Agile processes.” I say that this is an unfounded claim with no sensible proof whatsoever. Agility is a capability of a living being that a computer infrastructure cam never posess. Agile manager and employees create agile processes with or without SOA and not the other way around.

Processes became popular in 1911 when Frederick Taylor proposed them as a means to organize a business scientifically. Rummler and Brache wrote in 1990, that ”a business process is a series of steps designed to produce a product or service for a customer.” This is an oversimplification that will only apply to at most two percent of all business processes. In ‘Reeingineering the Corporation’ Hammer and Champy enlarged on that by saying: “Not the individual task or process is important but only the outcome.” That makes a lot more sense and leads to the question: “Is it even possible to analyze rigid processes to achieve a certain business goal?” I seriously propose that this is an illusion!

It is my experience that emplyoess are inerviewed for month just to figure out a few simple processes that still are not correct once he get used. I ask: ‚How are these processes then continuously improved to finally reach the desired outcome?“ I tend to get pitiful smiles: „Obviously we use monitoring.“ Hold it, folks. Process monitoring only measures the service criteria of the analyzed process but not if it achieves the goals, right? „But we got Dashboards to monitor busines goals.“ Another one claims. True, some BPM products do, but even then it shows some value that maybe good or bad depending on the quality of the data source, but it DOES NOT tell you which process has to be changed how to get closer to your goal. You are back to square one. On top of that, you will find out that users will resist any change and a simple change needs a complete retest of all relates workflows because of the unknown dependencies.

Current BPM and SOA do not thaw the iceage that has befallen our applications. Java code is mostly frozen and thus dead. Business processes however have to be alive – call them agile if you want – but that has very little to do with SOA or what kind of interfacing technique you use. The people using those processes have to accept that it is them to create and modify the processes, which will never happen with any modelling tool that uses simplistic 2D step-by-step graphs, because of the hidden complexity. Only very innovative technology such as the Papyrus User-Trained Agent that can learn processes from user interaction, will provide the power of process tuning to the user.

Let’s take a step back. How did we do dynamic agile processes before IT? Very simple … by usng documents! So what we need most from BPM is an overview of all the states of all the documents of a particular business process. No one needs rigid processes that are monitored for inhumane perfection. Let me add one more: I propose that there are no ‚document related processes’ but if a process does not require a document then the process is not needed! Yes, some dialogs in BPM systems replace those documents but that just proves my point. In my 35 years in IT I have learned that there are no fragmented process steps, but the propagation of a process is implicitly contained in the interdependent summary state of all its content (data, documents, controls). Because content is mostly irrelevant in process analysis so many process models are either wrong, incomplete or require substantial user input.

Another subject is even more controversial. When we interview those users, how does one model their decision making into simple IF-THEN-ELSE rules? One has to know WHY a user made a decision and encode that. I propose that this is actually not possible and my proposal is based on Antonio Damasio’s research documented in his book ‚Descartes Error.’ Humans are apparently incapable of being purely rational and need emotions to come to a sensible decision. (I know that this is true for me, but then I am an entrepreneur and don’t have to be reasonable.) Human rationality as well as analytical fact is an illusion. We never know for sure and that’s why a good feel about what is going on is much better than rational decisions. Now if that is true, each and every BPM system on the market today is a waste of time and money.

Conclusion: IT and its processes lack today because of fragmentation.

This is true for IT organization with analysis, development, test and production; missing change management for SOA interfaces, process steps, rules, documents, and GUIs; as well as the chance split of BPM, CRM and ECM. To solve the above the end-user departments have to be willing and agile enough to create and tune their own processes, but they won’t succeed with 2D-graphs and rule coding. Only the Papyrus WebRepository manages all the changes from analysis, definition, and test to production, transparently across all operating systems all those process elements, including the SOA parts. A typical SOA, Java and XML application has data models and logic hidden away in the database tables, in the processes, in the Java development tools as well as in XSL, XSLT, DTD, XPATH definitions und finally in the SOA interfaces with no common change management mechanism.

Papyrus WebRepository even goes a step further. In December 2007, the User-Trained Agent will be generally available and enable the training of business processes from user interaction. The logic is much more powerful than simple rule coding because all content of the business process is considered in the transductive pattern matching learning process. The transductive training concept is patented and thus an ISIS exclusive. Yes, patenting and proprietary is good because it is innovative and functional. The time it takes to standardize kills innovation and solution orientation as the dramatically lacking BPEL 2.0 clearly shows.

Visions can’t be proven (sic), but agility mostly means to have the mental flexibility to innovate.

„There are two key areas where IT has to focus: Strategic change – including architecture, business process management and change management – and innovation.”

Barbara Gomolski, VP Gartner Group – Computerworld Opinion, October 2006

You can’t lead following in someones footsteps. IT benchmarks pull everyone down to the same low level and have no other purpose than to be a pseudo-proof for the prevailing vision.

Innovation – to do something new – always bears some risk. Be brave!

Bibliography and References:

Damasio, Antonio (2005) Descartes’ Error: Emotion, Reason, and the Human Brain, ISBN 0-380-72647-5

Draheim, D. & Weber, G. (2006) Trends in Enterprise Application Architecture, ISBN-13: 978-3540327349

Hammer, M. ; Champy, J. (1993), Reengineering the Corporation: A Manifesto … ISBN-13: 978-1863735056

Rummler & Brache (1990), Improving Performance: How to manage the white space … ISBN-13: 978-1555422141

Sowell, Thomas, (1996) The Vision of the Anointed ISBN-13: 978-0465089956

Taylor F. W. (1911) The Principles of Scientific Management, ISBN-13: 978-1434638205

Gartner Group SSA Research Note SPA-401-068, 12 April 1996, “‘Service Oriented’ Architectures, Part 1″

Gartner Group SSA Research Note SPA-401-069, 12 April 1996, “‘Service Oriented’ Architectures, Part 2″

E. Christensen et al., Web Services Description Language (WSDL) 1.1, (W3C) note, Mar. 2001; www.w3.org/TRwsdl

SOAP Version 1.2, World Wide Web Consortium (W3C) recommendation, June 2003; www.w3.org/TRsoap

Gomolski, B. (2006) Computerworld Opinion, Oct. 2006

SOA and WS-BPEL: Composing Service-Oriented Architecture Solutions with PHP and Open-Source ActiveBPEL

Product Description

Composing Service-Oriented Architecture Solutions with PHP and Open-Source ActiveBPEL

• Build Web Services with PHP
• Combine PHP Web Services into orchestrations with WS-BPEL
• Use better WS-BPEL to enable parallel processing and asynchronous communication
• Simplify WS-BPEL development with free graphical tool ActiveBPEL Designer

In Detail

When utilized within a Service-oriented Architecture (SOA), Web Services are part of a business process determining the logical order of service activities – logical units of work performed by one or more services. Today, the most popular tool for organizing service activities into business processes is Web Services Business Process Execution Language (WS-BPEL), a language defining an execution format for business processes operating on Web Services. While it is not a trivial task to define a business process definition with WS-BPEL from scratch, using a graphical WS-BPEL tool can significantly simplify this process.

Examples and practice are much more valuable than theory when it comes to building applications using specific development tools. Unlike many other books on SOA in the market, this book is not focused on architecture. Instead, through numerous examples, it discusses practical aspects of SOA and WS-BPEL development, showing you how to apply architecture in practice with the help of PHP, ActiveBPEL open-source engine, and ActiveBPEL Designer – powerful development tools available for free.

What you will learn from this book?

• Install and configure the software components required to build PHP Web Services and then combine them into WS-BPEL solutions
• Use PHP as the underlying technology for creating building blocks for SOAs
• Build data-centric services based on MySQL or Oracle Database XE
• Secure services built with PHP SOAP extension
• Combine fine-grained services built with PHP into coarse-grained ones with WS-BPEL
• Deploy WS-BPEL process services to ActiveBPEL open-source engine
• Simplify WS-BPEL development with ActiveBPEL Designer
• Implement asynchronous interactions between WS-BPEL processes

Approach

With the help of many examples, the book explains how to build Web Services with PHP, combine them into SOAs with WS-BPEL, and then deploy composite WS-BPEL-based solutions to the ActiveBPEL engine. The examples in this book are presented in a way that anyone can understand and apply.

Who this book is written for?

This book is suitable for anyone who wants to start building SOA applications using powerful tools available free of charge. It also will be useful for PHP developers willing to move towards Service-Oriented Architecture (SOA).

Readers need only a basic knowledge of SOA, BPEL, and Web Services; even a total beginner will be able to follow the examples, provided the required software components are installed on his or her computer. More experienced readers might use this book as a reference, focusing only on the chapters of interest.

SOA and WS-BPEL: Composing Service-Oriented Architecture Solutions with PHP and Open-Source ActiveBPEL

SOA for the Business Developer: Concepts, BPEL, and SCA

• ISBN13: 9781583470657
• Condition: NEW
• Notes: Brand New from Publisher. No Remainder Mark.

Product Description

SOA for the Business Developer: Concepts, BPEL, and SCA

Next Page »