Livin' the life...

I just found an Excellent presentation on The Business Value of SOA by Anne Thomas Manes, a Vice President and Research Director at Burton Group.

And yes, SOA (Service-Oriented Architecture) is a part of my research..

"Wikipedia founder Jimmy Wales has said teachers who refuse younger students access to the site are "bad educators".

Speaking at the Online Information conference at London's Olympia, he played down the long-running controversy over the site's authority.

He said young students should be able to reference the online encyclopaedia in their work.

Mr Wales said the site, which is edited by users, should be seen as a "stepping stone" to other sources.

As long as an article included accurate citations, he said he had "no problem" with it being used as a reference for younger students, although academics would "probably be better off doing their own research". " [Check out the full story where they talk a bit about the new procedures which aim to make Wikipedia more trustworthy.]

Re. article: *darn.. *grumble* :-\

The key to getting a PhD is maybe 10% inspiration and 90% perspiration, combined with a liberal sprinkling of reflection...

Yes, to get a PhD you need to be bright, you need ideas and you need to do good research. But more than anything else you need persistence. You need to commit yourself to getting up and doing it again today.   ...

This gift of reflection, noting our actions and learning from them is one of the real characteristics of true intelligence, birds do it, bees do it and yet so often we fail to do it. It's so much easier to avoid reflection, to avoid action - and yet these are the keys to true success, in life, in business, in a PhD. (Source)

Really inspirational stuff.. I suppose one could apply this to other courses and even to life. For me though, I doubt that 10%-90% would do it, God is crucial to my, and one could even say, all of our success.

On the side: Hey Matt and Kat! I figure you're the only two other phd students reading this! So I hope you find it useful!!

But alas, it's not the PhD, I've got some type of bug! Could be flu, cold or just a horrid sore throat! Whatever it is, it has me under strict manners. No worries though, hopefully it's nothing some paracetamol and cherry-flavoured lozenges can't tackle.

On the PhD side of things so far I've (1) outlined (with the help of my supervisor) the general areas on which I need to focus; and (2) started doing some background reading on one of these general areas. When I have more time, I'll post more information here about my studies for any of you that have the faintest interest in what I've dedicated 3 years of my life to do.

For now.. it's dark and I'm going home! ta!

"Elements of a research proposal and report

2005 © David S. Walonick, Ph.D.

All research reports use roughly the same format. It doesn't matter whether you've done a customer satisfaction survey, an employee opinion survey, a health care survey, or a marketing research survey. All have the same basic structure and format. The rationale is that readers of research reports (i.e., decision makers, funders, etc.) will know exactly where to find the information they are looking for, regardless of the individual report.

Once you've learned the basic rules for research proposal and report writing, you can apply them to any research discipline. The same rules apply to writing a proposal, a thesis, a dissertation, or any business research report.

The Research Proposal and Report

TITLE PAGE
TABLE OF CONTENTS
CHAPTER I - Introduction
     Introductory paragraphs
     Statement of the problem
     Purpose
     Significance of the study
     Research questions and/or hypotheses
CHAPTER II - Background
     Literature review
     Definition of terms
CHAPTER III - Methodology
     Restate purpose and research questions or null hypotheses
     Population and sampling
     Instrumentation (include copy in appendix)
     Procedure and time frame
     Analysis plan (state critical alpha level and type of statistical tests)
     Validity and reliability
     Assumptions
     Scope and limitations
CHAPTER IV - Results
CHAPTER V - Conclusions and recommendations
     Summary (of what you did and found)
     Discussion (explanation of findings - why do you think you found what you did?)
     Recommendations (based on your findings)
REFERENCES
APPENDIX"

Nice article. See full version here.

Numeric style bibliographies and references

Numeric system

Harvard system

"Let me try to clear up any confusion that may exist about WS-CDL and WS-BPEL.

Firstly WS-CDL can be used to describe the observable behavior ,as interactions (message exchanges or WSDL function invocations), across a number of services (more than one). It's purpose is to clearly define the interoperablity needed to realise a system composed of many services.

Secondly, WS-BPEL is primarily focussed on composing new services from existing services. It provides a common way of describing the internal behavior of how these services need to work together in order to realise another service. So it has a single service perspective. It cannot be used to describe a system of services as peers because it yields a new service.

An orchestra typically has a conductor. Orchestration also has the equivalent - the orchestration engine.

Choreography has a choreographer who writes down the rules of engagement for the dancers, gets them to learn it and then leaves the stage to allow the dance to occur based on the rules. Choreography of services is similar. You write down the rules and use it to ensure that the "touch" points are preserved. This is akin to the externally observable behavior. The way in which a dancer performs the steps may be said to be orchestrated - they have a brain that controls their motor functions.

So you can see that a system described in WS-CDL may be realised as a set of peered islands of orchestration, which, based on the rules of engagement, work together to yield a system.

WS-CDL can be used to generate the observable behavior through role projection of services into WS-BPEL or any orchestration language (i.e. Java or CSharp, or ....). The non-observable business logic that is inside a service may be implemented in any end point language as long as the state machines behavior is preserved.

WS-CDL can also be used in a monitoring context to determine if services are well behaved - are they performing the dance steps correctly relative to each other?

WS-CDL is certainly related to WSDL but it is optional (check out the role defns in the spec). WSDL is certainly not capable of expressing what WS-CDL does. Oddly enough Abstract BPEL, if it were properly supported (and there is debate about that and what constiututes support), would be a good way of describing the state machine behavior of a single service. Then generating the service descriptions would be even easier by going from WS-CDL to Asbtract BPEL.

I agree very much that the two can be used in conjunction. WS-CDL for the system description (the sort of language architects dream of) and WS-BPEL for composite service construction.

Cheers

Steve Ross-Talbot

co-Chair W3C Choreography Working Group

Chair W3C Web Services Activities

www.pi4tech.com

www.pi4soa.org " (Ref)

Other interesting links:

http://pi4tech.blogspot.com/2008/02/orchestration-and-choreography-ws-bpel.html

http://blog.whatfettle.com/2005/02/16/choreography-vs-orchestration/

"Security has the inherent nature of spanning many different layers of a Web Services system. Web Services vulnerabilities can be present in the operating system, the network, the database, the Web server, the application server, the XML parser, the Web Services implementation stack, the application code, the XML firewall, the Web Service monitoring or management appliance, or just about any other component in your Web Services system.

Therefore security testing, which is important for any software application, is even more crucial for Web Services. This article explores security issues specific to Web Services and illustrates the engineering and testing best practices required to ensure Web Service security throughout the Web Services development life cycle.

Step 1: Determine a Suitable Web Services Security Architecture

Transport Layer Security

Message Layer Security

Step 2: Adhere to Technology Standards

Step 3: Establish an Effective Web Services Testing Process

Step 4: Create & Maintain Reusable, Re-runnable Tests

Conclusion
Securing your Web Services is a vital aspect of ensuring a successful deployment. When deployed externally for consumption by partners or customers, only secure Web Services can provide a justifiable integration solution, because the benefits they expose should far outweigh the risks. The key to effective Web Services security is to know and be aware of the various types of security threats, understand the technical solutions for mitigating these threats then establish and follow a defined engineering process that takes security into consideration from the beginning and throughout the Web Service lifecycle. By following the four steps outlined in this article, you can ensure complete Web Service security."

By: Dr. Adam Kolawa
Apr. 17, 2007 04:30 PM

[Full Article]

"Introduction to the SANS Security Policy Project

Welcome to the SANS Security Policy Resource page, a consensus research project of the SANS community. The ultimate goal of the project is to offer everything you need for rapid development and implementation of information security policies. You'll find a great set of resources posted here already including policy templates for twenty-four important security requirements."

Contents of site:

* Introduction To The SANS Security Policy Project
* About the Project Director
* The SANS Policy Email Hotline
* Is it a Policy, a Standard or a Guideline?
* SANS Technology Institute White Paper Projects
* What is all the hype on HIPAA?
* Need a Primer on Security Policies?
* Need an Example Policy or Template?
* Incident Handling Forms

http://www.sans.org/resources/policies/

Interesting article: Secure Web services

"Security is important for any distributed computing environment. But, security is becoming even more important for Web services due to the following reasons:

1. The boundary of interaction between communicating partners is expected to expand from intranets to the Internet. For example, businesses increasingly expect to perform some transactions over the Internet with their trading partners using Web services. Obviously, from a security perspective, Internet communication is much less protected than intranet communication.
2. Communicating partners are more likely to interact with each other without establishing a business or human relationship first. This means that all security requirements such as authentication, access control, nonrepudiation, data integrity, and privacy must be addressed by the underlying security technology.
3. More and more interactions are expected to occur from programs to programs rather than from humans to programs. Therefore, the interaction between communicating partners using Web services is anticipated to be more dynamic and instantaneous.
4. Finally, as more and more business functions are exposed as Web services, the sheer number of participants in a Web services environment will be larger than what we have seen in other environments.

Currently, the most common security scheme available for today's Web services is SSL (Secure Socket Layer), which is typically used with HTTP. Despite its popularity, SSL has some limitations when it comes to Web services. Thus, various XML-based security initiatives are in the works to address Web services' unique needs. This article examines those schemes. " By Sang Shin, JavaWorld.com, 03/18/03 [Full article]