FPDays2013 24 & 25 October 2013 on Cambridge


ImageFP Days is back for 2013! A developer event for people interested in or already using Functional Programming languages, the conference will be held at Murray Edwards College on 24th and 25th October 2013.

The event launched in 2011 to provide professionals in the Functional Programming community with a conference that is both collaborative and practically focussed.

The conference aims to ensure participants can connect, network and learn from their industry peers in a positive and practical environment. Past participant feedback shows delegates find the environment collaborative despite the number of different languages and passionate functional programming individuals representing them – something we are proud to encourage. You can see more here: http://www.youtube.com/watch?v=mtrTtu9-5Bg

We will be running a 2 day programme of keynotes, hands-on sessions, case studies and discussions primarily covering languages such as Haskell, F#, Scala, Erlang and Clojure.

Confirmed speakers for 2013 include Pierluigi Riti, Matthew Moloney, Ross Lawley and Keynote Speakers Philip Wadler, Bodil Stokke, Sam Aaron and Robert Virding.

For more information follow @fpdays on Twitter, track the event or buy your tickets now on Lanyrd (http://lanyrd.com/2013/fpdays/) or contact the event organisers, Software Acumen (fpdays2013@software-acumen.com).

Advertisements

CODEMOTION THE EVENT OPEN TO ALL LANGUAGES AND TECHNOLOGIES


Codemotion is the event open to all languages and technologies. It is the evolution of Javaday Roma, which after four editions has become the event of the art of programming.

The first edition of Codemotion has been in March 2011 and over 2000 people, 25 communities and 22 sponsor firms have become members.

During Codemotion 2011 there have been 65 talks on: gaming, mobile, hacking, os, tools, what’s hot, language and innovation.

The second edition of Codemotion will be held on 23rd and 24th March and there will be two main innovations: the lengthening of activities from one to two days and the fact that two events will be held simultaneously in Rome and Madrid.

Codemotion’s program will be defined through Call for Paper which is open to everyone. The proposals’ selection will be done by representatives of the official communities which are connected to both the analysis of language and software development.

During Codemotion, all participants will have the chance to have new professional opportunities by leaving their CV to the sponsor firms.

We are working on a project to promote the relationship between developers and startups and their synergic work for innovation.

Codemotion will be hosted by the Engineering department of the Third University of Rome.
Entry is free, as always.
For any further information contact us on: http://www.codemotion.it

Steve Jobs 1955-2011


steve-jobs

Steve Jobs CEO Apple

Hello Steve ,

the man who changed the world

SOA Governance the key to the success of an SOA


One of the aspects that I consider fundamental to the success of a SOA architecture and governance. Before explaining why I feel it so important to the success of an SOA, let’s explain what is meant by governance.

What is the Governance

For governance, the suits mean number of actions to be implemented for proper management of an IT service. These correspond to a set of procedures that must be implemented and managed to control the progress of the project and therefore can act in a timely manner for all the adjustments needed to realign with the current development plan. Governance therefore is responsible for managing the “people”, the “policies” and “processes” that must be verified and checked for proper operation of the SOA. One of the aspects essential for the effective management of governance is therefore to create the proper leadership structure that has as its primary goal the control and the establishment of rules and education of all actors involved in the management of services. Before going any further we should define the difference between “processes” and “services”, by reading a manual of ITIL V3, we find these definitions:

process: a coordinated set of activities that combine resources and capabilities to produce a result that produces a value for the customer and stakeholders. A process must have some specific characteristics:

  • Must be measurable
  • May provide specific results
  • May provide value to the customer and stakeholders
  • May respond to specific events (triggers)

service: a way to provide value to the customer without that bring increased risks and costs.

Processes and services are so closely related, both should provide a return value to the customer and both therefore are a vital part of the production process of an SOA. To provide a return value that is measurable and therefore provides a precise, specific figures are important two are the owner and the service process owners. Both these figures are needed for service management and process and consequently are one of the primary figures and necessary for the success of an SOA.Let’s explain what these two figures are concerned, always read the definitions in the documentation ITIL V3 we find these two definitions for both roles:

Process owners:  it is the responsibility of improving the product and ensures that the process meets the requirements of the service. He is responsible for the success of the process.

Service owner:  is responsible for the development and deployment of IT service is also responsible for its continued improvement and for management services under its control.

The “product owner” and the “service owner” can also converge to the same people, but both are necessary for the proper management of governance.Let us now define what is an SOA Governance.

What is SOA Governance

Once it is clear what is generally a “governance” to define what we see now is a SOA governance. SOA Governance is the combination of “people” and “policies” and “processes” with which your organization has the security of having desired the return of the SOA. This includes the normal governance procedures of a traditional IT architecture, IT project that identifies the purpose for each of the technology you plan to use and sets out guidelines to help in the development of SOA. Let us now define the different roles that are involved in SOA Governance.

People

The people involved in the management of SOA Governance are the same involved in the management of a normal IT Governance.New artifacts should be introduced only if they are necessary for the proper management of SOA Governance. If there is a governance and the effort is not what you wanted, maybe you should take action by putting new figures for the management of Governance, such as Senior Business Analyst or Lead Architect.In a word “people” are all those figures, technical and otherwise, that are necessary for the proper effort to return from governance.

Policies

For all policies are guidelines that must be followed by the people involved in the management of Governance.The questions must be answered to set policies for the governance must first understand what you want to get the Governance. If you simply want to create services to publish and make available to other SOA will never succeed because it is not clear what you want to get the SOA.

Processes

SOA governance must necessarily involve all the processes that serve to make the SOA measurable, improve communication and deal with all processes concerning the management of SOA. To do this you need to speak with the entire staff and clarify who will manage the processes and then clarify and establish all the processes that come into play in the management of SOA.

Conclusion

In this article we must introduced the concept of SOA Governance, in the next article we speak about SOA Journey and will introduce the pratice of SOA Governance

Web Service Contract


The success of an SOA is the sharing of services at several levels within the entire company. To do this we must of course that the “consumer” of the service know exactly  how the service should use. This exchange of information requires that the “consumer” and who “exposes” the service speak to each other through a “contract” setting out the functions and procedures to use the service.

Anatomy of a Web Service Contract

A Web Service Contract is essentially a collection of metadata that describe a series of basic aspects of the service that should be used including:

  • The purpose and functionality of each operation
  • The message he needs to do
  • The data model used in the message
  • The set of conditions necessary to carry out the operation
  • Information on how to access the service

A Web Service Contract is organized in a structure that exactly meets “Questions” that must be answered and that is:

  • “what” offers that particular service
  • “how” can I use that particular service
  • “where” I find that particular service

When a potential consumer wants to know our service will analyze what the service is capable of doing and under what conditions, where and how they can access the service. This information is basic to the orchestration of services and consequently vital for the success of SOA. There are formal terms to describe the structure of a Web Service Contract, these are:

  • Abstract Description
  • Concrete Description

The “abstract description” describes the interface of the service regardless of its implementation, while the “concrete description” contains specific details implementation of how and where to access the service. Parts of a Web Service Contract let us now describe some of the parts that make up the Web Service Contract, as we have already said is made up of two distinct sections to the “Abstract description” and “Concrete Description” the first thing we see, therefore, identify the parts that are description contained in the Abstract.

Constitution of the “abstract description”

In this section we find the Port Type (Interface) This is the interface for connect to the service, the Port Type Operations This section contains the points operation that the service can perform. Within the Operations section we find the Message that contains three different types of messages:

  • Input the message sent to the service from the service consumer
  • Output the message sent by the service consumer of the service
  • Fault message sent by the service to the consumer in the event of bankruptcy or error

In this way, the consumer of the service is able to establish all the features offered by the service and then decide if this is the service to use or not.

Constitution of the “Description of Concrete”

The “concrete description” complete the “Description Abstract” by providing the implementation features presented in the “Description Abstract”, this provides details specific on how to call from the Service Consumer. Inside of course find the same subdivision that was present in the “Division Abstract “the difference between the two is that in this section provides service implementations. We find then the Port Type (Interface) Binding, in this section we find the details to reach and use the service, are in the section Operation Binding inside that contains three sections:

• Input Message Binding

• Binding Outpu Message

• Binding Fault Message

The three sections correspond to the physical operations that are described in section “Description Abstract”, these sections are then used to indicate “how” and “where” run operations described in the service. The section where it is represented by the Service that contains within it the Port section, Port section contains the “where” to find the service, this may be a local server or remote, is not important, what matters in this section is to indicate precisely the address where to find the service.

Conclusion

We talked about what the service contract, that is how they serve a consumer to use a service, we will return in the following articles on the subject deepened and presented in more detail the language for the definition of services the WSDL.

Agile Methodologies the “Nirvana” of an SOA


How many of you know the development of an SOA requires lead times ranging from 2 to 5 years, this is because systems need to convert everyone here who maybe are already in use uniformali at the company and under a single structure which is precisely the SOA.

This brings the company to support many high costs that have been be repaid by the same SOA in terms of ROI or the project would fail. To do this you need so that applications that make Our SOA are immediately available in order to have the first economic returns immediately. One of the methodologies that I consider more valuable to achieve this
Agile methodologies are the goal, the choice of using a methodology Agile falls mainly in ways of working that accompany these methodologies.
Two things in particular I find very interesting:

  • The Continuous Integration
  • Test Driven Definition

Only these points are certainly very limiting for the choice of a management methodology over another, but if we go to agile methodologies to analyze lunge find many points that
make, in my opinion, better than a classical technique project management.
In particular, the management of a project “Agile” expects meetings day of no more than 15 minutes in front of the dashboard activities, now that many more may be an unnecessary waste of time reality is revealed in all its importance as soon as a member of the group encounters an unexpected obstacle. Now project managers can say that pure must be the resource raise the issue, which is true even in agile methods, the
difference is that they speak together, this means that the problem can be solved directly by another colleague who has encountered the same problem or similar in other areas
allowing to solve the problem quickly without necessarily need to move a resource from a task to solve the problem.
How many of you have already experienced one of the worst that can happen to a programmer is going to change careers an activity that even if connected to another is still different from what you are doing which necessarily implies a time “Adaptation” to new activities, this is normal in the methodologies Project Management is not allowed in classical Agile methodologies.
So let’s see what it takes to manage an Agile project and what is useful in an SOA.

Characteristics of an Agile project
Let us now describe what and how a project is composed Agilewith particular reference to Scrum.
The roles that characterize the Scrum methodology are 3:

  • Product Owner
  • Scrum Master
  • Teams

There are also 3 artefacts:

  • Product Backlog
  • Sprint Backlog
  • Burn down chart

And finally 4 ceremonies:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Retrospective

I do not want to disclose too much about how an Agile methodology, but I want to step on some points that I consider important for management of an SOA.
One of the highlights is the Daily Scrum, this is a time when the whole team meets to coordinate work and manage the risks pointing out any obstacles during the Daily Scrum, which lasts maximum of 15 minutes are usually 3 questions addressed to each member of the Group:

  • What did you do yesterday?
  • What will you do today?
  • What obstacles you encountered?

This is used to update the Burn Down Chart, ie the graph shows the evolution of the group in terms of Sprint, ie deliveries.
One of the focal points that makes me choose it are the Scrum Sprint In fact, each sprint is releasing a new feature and consequently a brick that goes to build our SOA.
These “bricks” and then allow to begin to use immediately SOA enabling you to have in terms of economic returns short.
These returns are used to increase the ROI of SOA, enabling then the same as “self-financing” thus making it less consideration of the development itself.
Conclusions

The development of an SOA is always a very complex operation, next are flanked by technical problems and project management problems management.
For the success of the project and the success of a SOA is in fact there must be an immediate payback that to increase ROI and justify the choice of Architectural.
One of my favorite methods for this are those Agile and Scrum particular, because this allows me to have returns immediate on what done and what has yet to be done, allowing
then decide what to develop and when to achieve the goals set by the SOA.

Web Service the “block” of a SOA


As we have already said that SOA is not just architecture but also an approach
methodological development.
SOA is a fundamental characteristic of the low cohesion between the services and the strong  expandability of the system, one of the key components for the realization of  this is the Web Service.
A Web Service is a set of communications standards that enable different applications to exchange data and application services.
The ideal scenario is that of large-scale deployment of a service, such example of a registry, making it available to all players that fit in system, thus avoiding any time to re-create the same application part.
Web Services have not been the first distributed architecture, CORBA and just think COM+, unlike the Web services are based on the precise standards that allows the use and portability to any platform hardware / software. The basic architecture of web services, provides the service to be “exposed” on a network, recorded in a registry, UDDI, where you can find all the information communication, exchanges, and finally a “contract” that governs use. A client must use a Web service so it will first observe the “Contract” of communication of the Web Service, this contract is within the WSDL Web Service Definition Language, which describes all the operations supported by Web Service and what parameters it needs to function properly. The exchange of information between the Web Service and the Client is using the SOAP, Simple Object Application Procotoll, this standard means that the client uploads an XML file that contains all the data requested by the client and processed from the server. The XML format is described in the WSDL, here we find another element that is the XML Schema, XML Schema allows the definition of the XML format that will be exchanged between client and server. You can create Web services across different platforms, such as Apache Axis, Apache CXF, or Microsoft WCF, but all will be fully integrated with each them, the characteristics of Web services makes them so fundamental to good success of an SOA. One of the basic steps for the realization and the good is the output of an SOA “Building Blocks” that is the basic set of services that provide the entire heart SOA. Create Web Services to expose the common core services, such as, the business registry, or the billing system, allows you to create the heart of  services that can be accessed and consumed by all applications that part of the SOA thus allowing the success of SOA.

Conclusion

In this article we spoke briefly of the Web Service over the next few articles we focus on management techniques for the management of applications that are part of the SOA, especially it will introduce the methods “Agile”, which I personally think you are best suited to meet the changes that the adoption of  SOA brings in the company.